AI Makes Privacy Testing Easy

Click Delete. The record disappears. Did the data?

Maybe it is still in browser storage. Maybe search can still find it. Maybe an analytics event already sent its contents somewhere else.

That is why I think AI-guided privacy testing is a much better approach than stopping at a cookie scan or checking that a privacy policy exists. The interesting work is following what the application does with information, across screens, requests, accounts, and time.

CARBON brings that investigation into the AI coding agent where you are building the product. Install it in Claude, Codex, or Cursor from testers.ai/carbon, then run:

/carbon-privacy

You can start with one feature. You do not need to wait for someone to organize a company-wide privacy exercise.

Follow one piece of information

Imagine a customer enters a name and a private note into your application.

The form saves correctly. The detail page looks right. Your functional test passes.

Now follow the note. Did it end up in a URL? Does search telemetry include it? Is it copied into an error report? Does it remain in a draft after logout? If another account signs in on that browser, what can it see?

No attacker has to break in for those to become privacy problems. The application may be doing exactly what its code says, while handling information in ways its users would never expect.

An AI-guided investigation can use the source to identify possible data paths, then exercise the reachable ones with synthetic information. A distinctive test value gives the agent something to look for in storage, requests, logs, and exports.

That turns a general concern into a specific question with evidence behind it.

What CARBON can help investigate

• Collection and purpose. Compare the information requested with the task the user is trying to complete and the product's stated purpose. Flag unnecessary fields and ask about business requirements the code cannot explain.
• Tracking and consent behavior. Inspect requests and storage before and after consent choices. Check what happens when someone rejects tracking, changes a preference, or returns later. The banner's appearance does not establish what the application does.
• Logout and account switching. Look for personal information left in drafts, caches, browser storage, and already-open tabs. Then examine what happens when another controlled test account signs in.
• Correction, export, and deletion. Change or delete synthetic records and follow the effects through the surfaces available to inspect. A record disappearing from one page does not establish that its other copies are gone.
• Unexpected recipients. Inspect whether personal data reaches analytics, crash reporting, notifications, support tools, or AI prompts beyond the intended scope. Check both the implementation and observed traffic where access permits.

AI can adapt this investigation to the product rather than treating every site as the same collection of forms. It can also compare the behavior it observes with the promises in the interface and documentation.

Read what the screen promises

Visual analysis matters here too.

Can someone find the rejection option? Is the deletion explanation clear about what happens next? Does the interface say “deleted” when the action only archives the record? Does a sharing dialog communicate who can see the information?

AI can examine the rendered experience and point out inconsistencies worth investigating. But a screenshot of a consent banner cannot prove that tracking stopped. That needs behavioral evidence.

The useful combination is the promise, the implementation, and the observed result.

A privacy report with a trail to follow

CARBON generates a privacy report that should explain what was tested, which data paths were observed, what went wrong, and what to verify after a fix. It can turn technical evidence into an explanation a developer or product owner can use.

The limits need to remain visible. If the agent cannot inspect backups or a third-party system, it cannot claim that deletion reached them. Seeing no external requests during one local journey is useful evidence about that journey, not proof that the deployed product never shares data.

Use synthetic records and minimize what the test captures. Sensitive evidence should be redacted. A privacy test should not create another copy of the very information it is trying to protect.

This is also not a legal compliance certificate. Whether a purpose, retention period, or consent mechanism meets an obligation can depend on facts outside the application. CARBON can surface the unanswered questions; the people accountable for those decisions still need to answer them.

Test it before the data is real

Here is a practical starting point:

/carbon-privacy follow synthetic profile data through save, edit, logout, account switching, and export; plan deletion checks and ask before executing them

Run it while the feature is still being built. Fix the problem, then follow the data again.

With a subscription coding agent, local testing can use your existing allowance rather than require a separate per-run model API bill. Limits and optional external service costs still apply, but the incremental cost can be very low.

You should not need a customer complaint to discover that their private note survives logout.

AI makes the investigation easier to start. The responsibility was already yours.

Install CARBON at testers.ai/carbon.

— Jason Arbon, CEO testers.ai