This page describes how ValGuard policy packs help teams keep full payment card data out of LLM outputs and restrict displays to masked forms. It is not a PCI DSS certification, QSA report, or legal advice. Use it as an engineering control layer beside your existing cardholder-data program.
Regulation context
PCI DSS expects cardholder data to stay in scoped systems with strict handling. Agents that parse invoices, read support tickets, or draft billing replies can echo PANs into chat logs and CRMs. Deterministic validators catch many card-shaped strings and Luhn-valid numbers before the next hop.
Which packs apply
| Validator | Role |
|---|---|
pci_dss_patterns | Payment card sensitive patterns |
valid_credit_card_luhn | Luhn check on card fields |
masked_card_only | Allow masked displays; block full PAN sequences |
secrets_detection | Keys and secrets in output |
pii_detection | Broader personal data patterns |
Compliance pack availability depends on plan entitlements. See pricing and validator catalog.
Sample violation
A support summarizer copies a full 16-digit PAN from a ticket into the CRM note. pci_dss_patterns or masked_card_only can block with a rule ID. Prefer shadow mode on historical tickets first. Shadow mode.
Rollout
- Inventory every agent that can see billing text.
- Attach PCI-related rules in shadow; sample would-blocks.
- Enforce on agents that write to CRM, email, or logs outside the CDE.
- Fail closed on those paths. Fail-closed.
- Keep card capture in scoped payment forms; do not ask the model to store PANs.
Honest limits
- Validators are pattern and checksum gates, not a full PCI assessment.
- Truncation and tokenization upstream beat relying on the model to "be careful."
- Hosted processing has a data-boundary implication; Enterprise self-host for VPC. Trust.
- Network and access controls around the CDE remain mandatory.
Related
Next step
Attach masked_card_only and pci_dss_patterns in shadow on support summarizers.