Your agent finds the leaks.

By Gil Salu, Cyaxios

Before deploy, an agent you control reads the code. It scans every log callsite for credentials, keys, and PII. It surfaces the fields that could leak and proposes the policy. Use whatever coding agent you are already running.

The leak nobody reviews

Most data leaks are not breaches. They are log lines. A developer writes logger.info(user) to debug a flow, the object stringifies its full state, and an email address, a session token, and an IP address land in plaintext. The line runs. It ships. Nobody flags it, because logging code is rarely reviewed with the same care as application code.

From there the value spreads. The log entry is shipped to a cloud aggregator, indexed for search, mirrored into a SIEM, and held for months under a retention policy nobody tied to the sensitivity of its contents. A secret that should have rotated in minutes now sits in a third-party system you do not control. This is the failure pattern described in CWE-532, Insertion of Sensitive Information into Log File, and it is why the OWASP Logging Cheat Sheet lists categories of data that must never reach a log in cleartext.

The threat is quiet by design. Nothing crashes. The leak is invisible until an audit, an incident, or a subject-access request pulls the records back into view. By then the data has been copied into systems whose deletion guarantees you cannot prove.

How does the agent know what is a leak?

The agent runs locally over your code. It reviews the log-emission callsites rather than the contents of any running stream, and it does not guess from a single regex. It combines several signals to decide whether a field carries sensitive data:

• Field names. Arguments named password, secret, ssn, email, or authorization are treated as sensitive by their declared intent, before any value is ever written.
• Correlation risk. Keys that thread one user's actions across many rows, such as a session ID or a device fingerprint, are escalated. On their own they look harmless. Joined across a log, they re-identify a person.
• Callsite shape. A raw print, a standard-library logger, or a framework hook that writes an object's full state is flagged as an emission point outside the sealed path.

Each finding carries a proposed classification: the field, the encryption group it should belong to, and the recipients who would hold the key. Fields that match nothing still get surfaced, because a field with no classification falls under the project's default policy. A project that defaults to private treats every unclassified field as a leak until you assign it.

What the agent surfaces

It also flags new endpoints and functions whose return shape contains unclassified fields, so they are classified before the next deploy rather than after the next incident.

A field slips in: the agent opens a PR

Say a teammate adds a referral feature. The new handler logs the event so the growth team can measure it:

# referrals/service.py  (newly committed)
tn.info("referral.created",
        referrer=user.email,
        promo_code=code,
        card_last4=payment.pan[-4:])

The agent reads the diff. Two of those three fields are not in the project configuration. It reports the gap and proposes a classification grounded in what each field is, expressed as the commands that map each field to a group:

# proposed group assignments
$ tn group add pii --fields referrer        # email address
$ tn group add payments --fields card_last4  # cardholder data
# promo_code: public, left in plaintext

The change arrives as a pull request, reviewed beside the code that introduced the fields. You accept, edit, or reject it. Nothing is reclassified behind your back. The same check runs as a pre-commit and CI gate, so a build that introduces an unmapped field can be stopped before it ships rather than discovered after.

What it produces

The agent produces two outputs. The first is the configuration change above: the new fields, their proposed groups, and the recipients to be granted, delivered as a pull request.

The second is a data contract. It describes the field set in human-readable form, each field's name, the group it belongs to, and the recipients with access. The contract can be shared with partner teams or downstream systems so they can request the grants they need instead of reverse-engineering your log schema. Once a field is classified, the library seals it in-process before the entry touches disk, so the policy the agent proposes is the policy the runtime enforces.

Why the audit cares

Classifying log fields is not housekeeping. It maps directly to obligations you already carry.

Secrets management. A key in a log is a key in the clear. The OWASP Secrets Management Cheat Sheet is explicit that secrets must not be written to logs, and that any secret which lands in one is considered compromised and must be rotated. Catching the leak at the callsite lets you seal or remove the field before it ships, so the secret stays out of the stream and there is no aggregator copy to chase.

Personal data. Under GDPR Article 32, encryption of personal data is named as an appropriate technical measure for securing processing. Sealing PII fields to a defined set of recipients is that measure applied at the point the data is written, not bolted on at the storage layer where the cleartext has already been observed. A breach involving personal data carries a 72-hour notification window under Article 33. GDPR's higher fine tier reaches up to 20 million euro or 4 percent of global annual turnover (Article 83(5)), with a lower tier of 10 million euro or 2 percent (Article 83(4)) for breach-notification failures. A log line you never classified is the kind of exposure that starts that clock.

Audit obligations. Retention magnifies the problem. Logs are commonly held for 90 days to a year or longer, so a single unclassified field is not one exposure but every copy made across that window, in every system the stream fans out to. The data contract gives an auditor a precise answer to which fields are sensitive, who can read them, and where the keys live, instead of a grep through raw logs.