The threat
The order record is the input, not the leak.
Support is the highest-volume paste surface in most retailers, and every path below is an agent or a developer doing exactly what the job asks. The record they need is the record that carries the regulated data.
-
Drafting a reply to an angry customer
The complaint cannot be answered without the order it is about.
Trips PCI DSS
-
Working a chargeback
The dispute is the transaction, and the transaction is pasted whole.
Trips PCI DSS
-
Debugging a failed checkout
A developer pastes the failing order, and the failing order is a real customer's.
Trips PCI DSS
-
Segmenting a customer export
The list is attached whole, because summarising half of it answers nothing.
Trips GDPR / CCPA
A Luhn-valid card number needs no context keyword to fire, which is what makes it the one rule that can be enforced on day one. Customer PII is the opposite — context-weighted, and worth measuring before it is enforced.
Precision and recall, per detectorWhat’s specific here
One detector is certain. The rest need tuning.
Retail has an unusual advantage and an unusual trap, and they are the same fact: card data is arithmetic, and almost nothing else here is.
-
01
Checksums make the first rule easy
Luhn validation plus a BIN range puts card-number precision high enough that blocking does not need a pilot to justify it. PCI DSS also has some of the clearest contractual consequences of any framework here.
-
02
Test card numbers are everywhere
Every payments environment contains documented test PANs, and they are Luhn-valid. Exception-listing them is the standard configuration and removes most of the friction developers would otherwise feel.
-
03
Seasonal headcount changes the risk
Contract support agents arrive in volume and leave again. Coverage is reported per device, so a seasonal cohort that never enrolled is visible rather than assumed compliant.
-
04
Customer PII is context-dependent
A name and an email are not a finding on their own. They become one beside a purchase history, which is why this side of the policy is weighted by context terms you can edit.
What it does here
Someone pastes an order record. Itzal stops it.
Banning AI does not work in a support org — handle time is measured, and people route around anything that slows them down. Itzal sits on the laptop and checks the text in the instant before it is sent.
A card number is arithmetic, so it fires on the checksum rather than on a guess. Your team gets a record saying what kind of value it was; the message itself never goes anywhere.
Illustration. The data shown is invented.
Rollout
Block the card number first. Everything else earns its turn.
Luhn and BIN validation put card-number precision high enough to enforce without a pilot. Customer PII is context-dependent and does not get the same benefit of the doubt.
-
00
Exception-list the test card ranges
Every payments environment contains documented test PANs and they are all Luhn-valid. This list is the difference between developers accepting the control and routing around it.
-
01
Block card data
Luhn plus BIN puts precision at or above 0.99, and sensitive authentication data is never storable post-authorisation. This is the rule that does not need a pilot to justify itself.
-
02
Log-only pilot, customer PII
One support queue. Names, emails and addresses in combination with purchase history — measured against real ticket language rather than a test corpus.
-
03
Tune
Context terms, plus exception lists for the sample customers and seeded orders that live in every staging environment.
-
04
Warn on customer PII
Handle time is measured in a support org, so watch it alongside the dismissal rate. A warning that costs thirty seconds will be dismissed on reflex.
-
05
Block, high-confidence only
The context-dependent detectors join the checksummed one at enforcement, once their precision has been measured rather than assumed.
If every phase runs to its minimum How far it slides if they all run long
Straight answers
Can we block card numbers without disrupting support?
Yes, and this is the one sector where blocking on day one is defensible. Luhn plus BIN validation makes false positives rare; exception-list your documented test card ranges and the residual friction is very small.
What about the CSV exports our merchandisers work from?
A CSV is read on the device through the normal detection path, and a column headed with an identifier over hundreds of rows is reported as one finding with a count rather than hundreds of findings. Workbooks are read as rows for the same reason.
Does this cover our contact-centre platform?
It covers what is typed into a browser on a device you manage, including a web-based agent desktop on a supported site. A thick-client desktop application is reached through the optional local proxy, not the extension.