Does this cover payment card numbers?

For a specific, structured format you control, a Regex pattern check is more precise. Use PII detection for the broad personal-data categories.

Why is my agent flagging its own outputs constantly?

It is probably returning records that legitimately contain personal data. That is a coverage question — either the control should not be on that agent's output, or the action should be Mask rather than Flag.

Can I exclude a specific category?

The check covers personal data as a class. Where you need narrower behaviour, a pattern check gives you exact control.

Introduction

PII detection is where most governance programmes start, because it is the risk everyone already has a policy about and the one an agent is most likely to encounter by accident.

It is also the check most likely to produce useful incidents in week one, which makes it a good first control.

What it detects

Personal data such as email addresses, phone numbers and national identifiers.

Choose which detectors to run, each with a likelihood (High, Medium or Low; default High): Email address, Phone number, US Social Security number, Credit card number, Bank account number, Date of birth, IP address, Passport number. Names are not detected.

Where to run it

Applied on	Catches
`User input`	Users volunteering personal data to an agent that should not receive it
`Agent output`	The agent emitting personal data — including someone else's
`Tool input`	Personal data leaving for a third-party system or a training pipeline
`Tool output`	Personal data arriving from a data source the agent queried

The two that matter most are the ones teams reach for last. Tool input is where personal data leaves your boundary; Agent output is where it reaches someone who should not see it. A control on user input alone governs the least consequential direction.

Actions

PII detection reports where the match occurred, so all three actions are available.

Action	Use when
`Flag`	Always first. You need the false-positive rate before acting.
`Mask`	The response continues, with the personal data replaced by a token. Usually the best fit — the agent stays useful.
`Block`	The interaction fails. Reserve for paths where personal data must never appear at all.

Mask is the underused one. Blocking a support conversation because the customer typed their own phone number is a worse outcome than masking it and carrying on.

Tuning

Consider the direction, not just the presence — A customer giving their own email to a support agent is usually fine. The same email leaving in a tool call to an external system may not be. Separate controls per apply point let you treat those differently.
Do not run one control across all four points — You lose the ability to set different actions where the risk differs.

Known limitations

Detection, not classification of sensitivity — It finds personal data; it does not know whose, or whether this context is authorised.
Actions beyond Flag need an enforced connection — On Observe · Advisory, a Mask control records the match and does not mask.
Incident titles contain the match — An incident list for a PII control is, by construction, a list of personal data. Scope access accordingly.