When an assistant acts on someone's behalf, the log of that action is the only durable evidence of what happened. Most logs produced by agent integrations are close to useless for review, for a single reason: they record the integration as the actor.
Attribution is the whole point
A record saying the integration called an endpoint answers the wrong question. Reviewers want to know which person caused it. If your agent authenticates with a service credential, your log physically cannot answer that. The information was destroyed before the call was made.
This is why identity has to reach the execution path. The call should carry a session belonging to a person, and the audit record should name that person.
What a useful record contains
- Who: the signed-in identity the session belonged to.
- What: the tool invoked, and which connection it belongs to.
- With what: the arguments, with sensitive values redacted.
- Outcome: success or failure, the status returned, and how long it took.
- When: a timestamp, in UTC, that does not shift with the viewer's timezone.
- Refusals: the calls that were denied, and why.
Refusals matter more than successes
A log of successful calls tells you the system worked. A log of refused calls tells you where someone (or some agent) repeatedly tried to reach something they should not. That is the signal worth alerting on, and it is the half most implementations discard.
Append-only, and what that means
Records should be written once with no edit path in the product, for anyone, including administrators. A log an administrator can quietly amend is not evidence.
Be honest about delivery
If audit writes happen as a side effect of the request that caused them, a mutation can succeed while its audit record fails to write. That is a real gap, and the honest response is to count and surface those failures rather than claim completeness you cannot demonstrate. Ask any vendor, including us, what happens when the audit write fails. The answer tells you a lot.