Support
An agent pastes a customer email containing a full card number into an AI tool to draft a reply.
How it happens
Rarely through the payment flow itself.
That path is usually well controlled. It happens around the edges — and in every case the intent is to do the job faster, with the card data incidental to the question being asked.
Not legal advice. Your QSA owns scope determinations for your environment. Reviewer to be named
Engineering
A developer pastes a log excerpt or a test fixture containing real card data while debugging.
Analysis
An analyst pastes a chargeback spreadsheet to summarise it.
Operations
Someone pastes a declined-transaction record to ask what an error code means.
Why PANs are the ideal first rule
Most detectors trade precision against recall. Card numbers largely don’t.
The Luhn checksum eliminates most random 16-digit strings. BIN ranges confirm the number belongs to a real issuer range. The format is stable across contexts and formatting variants.
That reliability has a practical consequence: card numbers are the right place to start blocking rather than warning. When you begin enforcement with detectors that are effectively never wrong, you build trust in the control instead of training people to dismiss it.
Sensitive authentication data is a higher severity. CVV, CVC, PIN blocks and full track data must never be stored after authorisation, so their appearance in a prompt is more serious than a PAN alone — and policy should block them unconditionally, including to sanctioned destinations, because there is no configuration in which storing them is acceptable.
Detection that isn’t its own scope problem
A monitoring tool can expand the assessed environment.
A tool that transmits prompt content to a vendor cloud for inspection would be sending cardholder data to another party — potentially expanding your assessed environment to include your security vendor.
Itzal’s detection runs on the endpoint. What leaves is a finding type, a count, a confidence, a masked snippet, a destination and a risk score. The PAN never reaches Itzal’s infrastructure, so Itzal’s infrastructure never enters the conversation with your QSA.
Practical policy
Four rows, then tune.
Exception-list your known test card numbers so developers are not blocked by fixtures. Review the block rate weekly for the first month, and treat a rising trend in one team as a process problem in that team rather than a detection problem.
| Finding | Sanctioned destination | Unsanctioned destination |
|---|---|---|
| PAN, Luhn-validated | Block | Block |
| Sensitive authentication data | Block | Block |
| Truncated PAN | Log | Warn |
| Expiry and name, no PAN | Log | Warn |
Straight answers
Does pasting a card number into ChatGPT bring it into PCI scope?
It places cardholder data in a system outside your assessed environment, which is a control failure rather than a scoping expansion you can simply accept. Your QSA is the right person to characterise it for your specific environment.
What about a truncated or masked PAN?
Properly truncated PANs are generally out of scope, which is precisely why detection should validate rather than pattern-match — flagging every 16-digit string produces noise that trains people to ignore warnings.
Can a DLP tool block card numbers reliably?
Card numbers are among the most reliable detections available, because the Luhn checksum plus BIN ranges make false positives rare. This makes them a good first candidate for blocking rather than warning.
Is sensitive authentication data different?
Yes, and more serious. CVV and full track data must never be stored after authorisation under any circumstances, so their appearance in a prompt is a higher-severity finding than a PAN alone.