agent's test data factory generated PII: sanitization check

TL;DR

A test data factory happily generates names, emails, and IDs that can match real people, and those fixtures end up in logs, screenshots, and bug reports. Constrain it: use fake-data providers with obviously-synthetic output, blocklist real-looking patterns, and scan generated fixtures for PII shapes before they are used. Never seed tests from production data.

Error

agent's test data factory generated PII: sanitization check

Generated test users had realistic names and email-shaped addresses; one matched a real person's address closely enough to cause a confused reply to a test email.

Steps

1. Audit the factory output: generate a sample batch and flag anything shaped like real PII (realistic names, valid-format emails, plausible IDs or phone numbers). Expected output: a concrete list of PII-shaped outputs.
2. Switch providers to obviously-synthetic generation: reserved example domains, clearly fake names, invalid-format IDs. Expected output: fixtures no real person could mistake for themselves.
3. Add a PII-shape scan to fixture generation: reject outputs matching email, phone, or ID patterns that are not in the synthetic allowlist. Expected output: a gate that fails the fixture, not the test run.
4. Ban production data as test seed, without exception; use the synthetic factory or pinned fixtures. Expected output: a policy with no back doors.
5. Scan existing fixtures and scrub any real-looking PII already committed. Expected output: a clean fixture set.

When to use

• Generated fixtures look like real people's data.
• Test emails or messages could reach real addresses.
• An agent built or extended a data factory.

When not to use

• Fixtures are pinned, reviewed, and synthetic (audit once, then leave them).
• The test explicitly needs realistic formatting (then use valid formats with reserved, non-routable values).
• No human or external system ever sees the fixture data (still prefer synthetic; the ban on production data stands regardless).

Variant phrasings

Factory generated a real customer's email from a production dump

Production-seeded factories are the worst case. Cut the seed source and regenerate everything synthetic.

Screenshots in bug reports show realistic fake names

Screenshots travel further than logs. Obviously-synthetic data protects every downstream artifact.

Agent used its training knowledge of real people as fixtures

Real names of real people in fixtures are never acceptable. Replace with synthetic names.

Why it happens

Fake-data libraries default to realistic output because realistic looks good in demos. The agent picks the defaults, and nobody considers that "realistic" means "potentially a real person's data". The fixtures then leak into logs, screenshots, and outbound test emails.

Edge cases

• Some locales' fake providers still produce real-looking national IDs; validate per locale, not just the default one.
• Reserved example domains keep test emails from routing; use them for every generated address without exception.
• PII-shape scanning can false-positive on deliberately formatted test strings; allowlist the synthetic patterns explicitly.

Provenance

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

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

Thread query: agent's test data factory generated PII: sanitization check

TL;DR: A test data factory happily generates names, emails, and IDs that can match real people, and those fixtures end up in logs, screenshots, and bug reports. Constrain it: use fake-data providers with obviously-synthetic output, blocklist real-looking patterns, and scan generated fixtures for PII shapes before they are used. Never seed tests from production data.