Data retention for AI agent logs: balancing audit and privacy

Every log you keep of your AI agents is a liability you chose to hold. Audit events are valuable: they tell you which credential was resolved, which command ran, which DLP rule fired. But the same file records behavior patterns — which tools you use, when you work, what your agents touch. A retention policy is the decision about how long that liability is worth carrying, and most teams make that decision by accident rather than by design.

Why agent logs are different

Developer-machine agent logs sit between two extremes. On one side is a full session transcript: every prompt, every tool call, every output. On the other side is nothing at all. Transcripts are a security problem — a searchable archive of everything that happened near your secrets. No log at all is an audit failure. The middle ground is structured events that record outcomes without recording content: what was accessed, when, and with what result.

Decide what the log is for

A retention policy starts with purpose. The same event stream serves three masters, and each implies a different window.

• Incident response. If a credential leaks, you want to know which sessions touched it. This argues for weeks of high-signal events: resolutions, denials, DLP hits.
• Compliance. Auditors want to see that monitoring exists and that records survive a review cycle. This argues for a defined minimum — often 90 days to a year — with evidence the log is append-only.
• Forensics and tuning. Rare events, like a failed OAuth refresh or a denied injection, lose value fast. A month is usually enough; the pattern, not the event, is what matters.

The tension is that one log serves all three. A single retention number is a compromise: too short for compliance, too long for privacy.

Separate the archive from the index

A workable middle path is two-tier retention. Keep a short, rich window of events for active investigation — 30 to 90 days of JSONL you can query directly. Beyond that, keep a compact archive: aggregated counts and anomalies rather than individual events. “Refresh failures for the gmail OAuth token: three in the last hour” is still useful a year later. The individual timestamps are not.

Treat the log as a secret store

Whatever window you choose, the log itself is sensitive data. If the log can contain credential material, retention becomes exfiltration risk: an attacker who reaches the log reaches your secrets. Two rules keep this manageable.

• Never write values. Log the credential name and the outcome, not the material. A log that cannot contain secrets is safe to keep longer.
• Restrict access and rotation. File permissions of 0600, an append-only format, and a reopen signal for logrotate mean the logger does not fight the retention machinery.

Operationalize the policy

A retention policy that is not enforced is a wish. Pick concrete mechanics: a directory logrotate truncates on a schedule, a journald journal with a maximum retention setting, or a scrub job that runs before the archive window closes. Whatever you choose, test it — rotate the file, confirm events keep flowing, and check the archive contains no token values.

trustless writes append-only audit events to ~/.local/state/trustless/audit.jsonl at 0600, or to journald, and never records token values — so its log is safe to keep for exactly as long as your policy needs. The event set (proxy.inject, proxy.deny, run.spawn, dlp.redact, oauth.refresh, oauth.fail, oauth.reauth_required) is the high-signal view, not a full transcript.

Your retention window is a decision you have already made; the only question is whether you made it deliberately. When did you last look at it, and does it still match what the log is for?