Govern the data your systems throw off.

By Gil Salu, Cyaxios

Data platforms govern what you ingest, clean, classify, master, and distribute. But your applications also throw off logs, traces, stack traces, debug lines, and agent telemetry. That exhaust can contain customer identifiers, transaction context, access signals, and join keys that reconstruct sensitive behavior.

Your data platform does not see everything.

Most governance starts after data lands somewhere. TN starts earlier, at the moment an agent writes the code that creates the exhaust.

TN Skills helps coding agents find, classify, and govern that exhaust before it becomes unmanaged risk.

Two places to govern: the callsite and the pipeline.

A log field is sensitive or safe long before anyone reads it. The question is where in the data path you decide. There are two options, and they sit at opposite ends.

The callsite. This is the line of code that produces the field. The value is still a typed variable in memory, named, with full context: which event, which user, which group it belongs to. A field sealed here never exists as plaintext on disk. TN works here. Sealing happens in the same process that emits the entry, before the entry is persisted, and the write path involves no network call to an external service.

The pipeline. This is everything downstream: the file on disk, the agent that forwards lines to a SaaS aggregator, the index that retains them. A runtime scrubber sits here. It reads lines that already exist, matches them against patterns, and redacts what it recognizes. The plaintext was written first. The scrubber removes a copy after the fact.

The difference is not cosmetic. Callsite sealing is a property of the code. Pipeline scrubbing is a filter applied to output the code already produced. One shifts the decision left, into the moment of authorship. The other tries to catch up after the bytes have left.

Why do runtime log scrubbers miss agent output?

A regex or DLP scrubber works by recognition. It carries a list of patterns (email shapes, card numbers, token prefixes, known field names) and redacts what matches. That model holds when the schema is fixed and a human reviewed it. It breaks for code an agent writes.

• The field is new. An agent that adds portfolio_concentration or advisor_note to an event introduces a name the scrubber's pattern list has never seen. Unrecognized means unredacted. The scrubber passes it through clean.
• The value does not look sensitive. A join key, an internal account reference, or a behavioral score carries no email-shaped or card-shaped signature. It correlates rows into a profile, but pattern matching reads each value in isolation and finds nothing to flag.
• The leak happens before the scrubber runs. The plaintext is written to disk, to stdout, or shipped to a third-party aggregator at the moment of the log call. The scrubber runs later, in the pipeline. Anything that reads the stream in between (a sidecar, a tail, a crash dump, a backup) sees the unredacted value. CWE-532 catalogs exactly this: sensitive information written into log files where it should not be.
• Agents generate fields faster than pattern lists grow. Every new event an agent writes is a field a human did not enumerate. The scrubber's coverage is a snapshot; the schema is a moving target. The gap between them is where the next leak lives.

The OWASP Logging Cheat Sheet makes the same point as guidance: decide what must not be logged at the point the log statement is written, not by filtering output afterward. A scrubber is a backstop, not a control.

Worked example: a new field an agent introduced.

An agent extends an asset management reporting workflow. It adds a single field to an existing event so a downstream report can group accounts. The field is risk_segment, a behavioral classification the team has never logged before.

The contrast is the whole argument. The scrubber can only act on what it recognizes, and it recognizes nothing new. The callsite has the field by name, in context, at the moment it is created, and can default it to sealed. The gate makes the omission loud instead of silent.

Why shift-left matters for an audit.

Data-protection regulation treats where you make the decision as a substantive question, not an implementation detail.

Data protection by design and by default. GDPR Article 25 requires controllers to build data-protection measures into processing from the outset and to ensure that, by default, only data necessary for a purpose is processed. A field sealed at the callsite is private as its resting state. A field that depends on a downstream scrubber to catch it is exposed by default and protected only if the filter happens to recognize it. The first is design; the second is mitigation.

Minimization. GDPR Article 5 sets data minimization as a core principle: process only what is adequate, relevant, and limited to what is necessary. Deciding at the callsite lets the author keep a field out of the clear, or out of the log entirely, at the moment they know what it is for. A pipeline filter cannot minimize what was already written; it can only attempt to remove a copy.

What an auditor can verify. A scrubber's coverage is a claim about a pattern list and the output it has seen. It is hard to prove a negative across every field an agent might generate. Callsite sealing is a property an auditor can read in the code and confirm in the artifact: the entry on disk is ciphertext, signed at the source. The control is the same fact the auditor checks, not a separate process you have to trust kept up.

Install it where the agent works.

In Claude Code, install TN Skills with two commands:

/plugin marketplace add cyaxios/tn-skills
/plugin install tn-logging@tn-skills

For Codex, Cursor, Copilot, and other coding agents, use the same skill instructions as plain project guidance with AGENTS.md. The point is the same: the agent gets a better default before it writes or edits logging code.

What the agent learns.

• Replaces raw logs with governed TN events.
• Removes throwaway debug output when it should not ship.
• Names fields consistently so sensitive data routes correctly.
• Recognizes payment, identity, financial, health, education, audit, and cloud data patterns.
• Flags fields that look harmless alone but become sensitive when joined across events.
• Drafts plain-English rules for how future agents may use each event stream.
• Leaves a signed, encrypted trail your team can inspect later.

Built for review, not blind trust.

TN Skills does not ask a team to trust an agent's first guess. It gives the agent a repeatable process: inventory the exhaust, classify fields, check correlation risk, choose the right domain vocabulary, then offer code changes and policy text for human review.

If the file should not log anything, the agent can leave it alone. If a debug statement has no operational value, it can remove it. If an event matters, it can write it as a governed event with field names a reviewer can understand.

The seven skills.

The install gives the agent a working TN vocabulary, not a white paper.

It sits around the data platform.

TN does not replace your data management platform. It governs the exhaust around it: the operational record created while code runs, agents act, and teams troubleshoot.

To wire TN Skills into your coding workflow, start with the Agent integration guide, review DRM for logs, or read the Reference documentation.