What to log when an AI agent acts on someone's behalf
Most agent stacks already log plenty: prompts, completions, tool calls, latency, token counts. That's useful for debugging. After an incident, though, a security reviewer will ask something the traces can't answer: was this action allowed, for this agent, on behalf of this person, against this reco
Posted on Oct 14 • Originally published at permit.io
Most agent stacks already log plenty: prompts, completions, tool calls, latency, token counts. That's useful for debugging. After an incident, though, a security reviewer will ask something the traces can't answer: was this action allowed, for this agent, on behalf of this person, against this record, at this time?
If an agent can change things in systems that matter, each decision should record roughly this:
The simplest place to produce that record is where enforcement happens, at the point where the agent crosses into a real tool. A successful login shows the person authenticated. It doesn't show that the agent may export a file or call a privileged MCP tool ten minutes later. So check each action there, block or allow before the tool runs, and emit the audit event from that same decision. Working out afterwards from a transcript whether something was allowed is much harder to defend.
For a read-only assistant that can't change anything, you can skip most of this.
Disclosure: I work at Permit.io. This is a short version of a post by our CEO, Or Weis, which also covers where an MCP gateway fits as the enforcement point and what NIST's NCCoE concept paper says about access delegation:
https://www.permit.io/blog/human-agent-delegation-audit-trail?utm_source=devto&utm_medium=social&utm_campaign=human-agent-delegation-audit-trail&utm_content=authbyexample-article