CISA's joint guidance on deploying AI systems securely, co-authored with the NSA, the FBI and four international partners, is blunt about logging: you need pipelines capable of detecting anomalous AI behavior, and standard server logs are not it. That guidance predates the current wave of coding agents, and it reads like it was written for them.
Here is the test it implies. When an agent session goes wrong, the first question is always the same: what did it send, and where? Most teams cannot answer. The only record lives in a vendor's dashboard, in a model provider's logs, or nowhere at all. The session's container logs confirm it ran. They do not say what it did.
An agent audit log is only useful if it has three properties at once. It has to be complete, including the requests that were denied. It has to be attributable, back to a person or the trigger that started a headless run. And it has to be yours, in storage you control, on your retention, feeding your tools. Miss any one and the log fails exactly when you need it.
Agent egress is unlike service egress
A traditional service talks to a known, small set of destinations. You can enumerate them, allowlist them, and treat a new one as an alarm. An agent does not work that way. Its destinations change per task, because the task is different every time: this hour it needs a package registry and a docs site, next hour an internal API and a database.
That breaks destination-only thinking in a specific way. The same host can be a legitimate dependency or an exfiltration channel depending on the verb and the path. A GET from a code host to read a file is routine. A POST to the same host that creates a public gist is not. If your log records "talked to github.com" and stops there, it cannot tell those apart, and the difference is the whole point.
What every record should contain
The useful unit is one request, fully described. Kept generic, the fields are not exotic:
- the session, and the agent
- the actor: a human, or the trigger that started a headless run
- the destination, with the method and the path, not just the host
- the verdict: allowed, denied, or passed through
- the policy rule that produced the verdict
- a reference to which credential was used, never the credential itself
- timing
The list is deliberately boring. Boring is the point: these are the fields that let you reconstruct a session later, and none of them requires inventing anything about how a specific system stores them.
Attribution is the field teams skip
The field most logs lack is the actor. An outbound request with no answer to "who or what caused this?" is nearly useless in an incident. For interactive sessions that means the human who launched it. For headless runs it means the trigger: the ticket, the schedule, the webhook. Tie every request back to its origin and a review of "what did the 3am run do?" becomes a query instead of an archaeology project.
Verdicts matter as much as traffic
Log decisions, not just packets. A record that an unknown destination was denied, and the rule that denied it, is often more valuable than the allowed traffic, because repeated denials are how you notice an agent trying to reach somewhere it should not. A log of what happened without what was decided tells you the story without the plot.
Where the log should live
The second property, attributable, is about content. This one, yours, is about custody.
The log belongs in your bucket, on your retention schedule, feeding your SIEM. Vendor-held logs fail in two predictable moments. In an audit, "the records are in our vendor's console" is not an answer an auditor accepts, and you cannot set the retention an auditor requires on storage you do not own. In an incident, you need to correlate agent egress with everything else your SIEM sees, and you cannot do that from someone else's dashboard on their timeline. Marshal's public position is the same one this argues for: 100% of egress logged, to a sink in your own storage.
Five queries every security team should be able to run
A log earns its keep by answering questions on demand. Five worth being able to run on day one:
Which sessions reached a destination they had never reached before, this week? Which denied requests repeated, and from which sessions? Which sessions used a given credential, by reference? What did one specific session send, start to finish, in order? And which requests over a window went to destinations outside your known set? If your current setup cannot answer these, that is the specification for what to build or buy, stated as queries rather than features.
Privacy and redaction
Owning the log raises its own obligation: not everything belongs in it. Secrets never do, which is why the record holds a credential reference and not the value. Sensitive payloads need handling too, and this is the honest limit to state plainly. Do not treat full PII redaction as a solved feature or promise it as shipped. The right posture today is to keep secrets out by design, be deliberate about what request detail you retain, and be straight about what inspection is and is not in place.
An agent egress log is only worth keeping if it is complete, attributable and owned by you. That means recording every request with its verb and path and verdict, tying each to the actor behind it, and storing it where your auditors and your SIEM can reach it. Build it so that "what did it send, and where?" is a query you can run, not a question you dread.
This pairs with the other half of the exfiltration problem: how data leaves agent sessions, and how to catch it →
Marshal logs every egress decision to storage you own, with the actor, the verdict and the rule behind it. Book a demo →