# agent stored card tokens in plaintext logs: PCI incident response

## TL;DR
Card tokens in plaintext logs are a PCI incident: treat the logs as compromised cardholder data. Contain first: stop the logging, restrict access to the affected logs, and rotate the exposed tokens. Then fix the logger so sensitive fields are masked before they are ever written.

```text
agent stored card tokens in plaintext logs: PCI incident response
```

## Steps

1. Stop the bleeding: disable or patch the logging call that writes the tokens. Success check: new log lines contain no tokens.
2. Restrict access to the affected log files and note who could already read them. Success check: the audience for the logs is known and narrowed.
3. Rotate every token that appeared in plaintext; assume each one is compromised. Success check: old tokens no longer work anywhere.
4. Scrub or securely delete the affected log history per your retention policy. Success check: no plaintext tokens remain in stored logs.
5. Add masking at the logger level: card tokens, PANs, and secrets are redacted before write, with a test that fails if a token-shaped value ever hits a log. Success check: the test suite catches the next attempt.

## When this applies

- An agent wrote card tokens or payment credentials to logs in plaintext.
- You need a containment and rotation checklist for a logging incident.
- You are hardening loggers against sensitive data.

## When it doesn't

- Confirmed full card-number exposure; involve your incident response team and acquirer now.
- Tokens that were always encrypted at rest; verify before declaring an incident.
- General PII in logs without payment data; related but lower severity.

## Tool + version compatibility

PCI DSS logging requirements; any payment integration an agent touches.

### "card tokens in logs pci"
Contain, rotate, scrub, then mask at the logger.

### "agent logged payment credentials"
The logger needs field-level masking, not just careful code.

### "plaintext card data in application logs"
Assume compromise of what was logged; rotate it all.

## Why it happens

Agents log verbosely: full request and response bodies end up in debug output, and payment tokens ride along. Tokens in logs widen PCI scope to every system that stores or ships those logs, and anyone with log access effectively holds payment credentials. The fix is structural: masking must happen in the logger itself, because no amount of careful coding survives an agent that dumps whole objects.

## Edge cases / pitfalls

- Tokens are credentials: anyone who read the logs during the exposure window must be accounted for.
- Do not copy the affected logs to a ticket or chat while investigating; you spread the exposure.
- Check log shippers and aggregators too; the plaintext lives everywhere the logs were forwarded.
- After the incident, run a scan for token-shaped values across all log stores; one logger is rarely the only one.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_E8Nm6oRnluYOEo8qiYSIdA