Audit logging for AI agents on AWS tends to fail in the same few places, and all of them surface at the worst time: during an incident, when you reach for the log and find it cannot answer the question. Start with the mistakes, because the correct design is mostly the result of refusing to make them.
The mistakes that bite first
- The log lives where the agent can reach it. If audit logging writes to a destination the agent can edit or delete, a compromised agent can erase its own tracks. The log shares the agent's trust boundary, so it fails exactly when you need it.
- It logs the role, not the task. CloudTrail shows that a role made a call. It does not show which task or which agent drove it when many share a role. The "who" and "why" go missing.
- It captures successes, not denials. A log that only records actions that happened, and not the ones that were attempted and blocked, hides the most interesting behavior in an investigation.
- It records the action, not the access. Knowing an object was read is half the story. Whether the access was granted, scoped, and expired is the other half, and most logs never capture it.
Each mistake has the same root: the log is generated too close to the agent and too far from the access decision.
What correct audit logging looks like
Turn each mistake around and the design appears. The log records the access decision, not only the resulting API call. It attributes every action to a distinct agent identity and the task that requested it. It captures denials alongside successes. And it is written by the layer that brokers access, not by the agent that uses it.
That last point is the architectural one. Audit logging is only as trustworthy as the distance between the logger and the logged. If the agent records itself, the log is a claim. If access runs through a boundary the agent cannot reconfigure, and that boundary writes the log, the log is evidence. hoop.dev is built to sit at that boundary: the agent reaches AWS-hosted infrastructure through a Layer 7 access gateway that connects with its own scoped IAM role, access is granted per task, and each session is recorded outside the agent. The learn pages describe how access and recording fit together, and the getting-started docs cover fronting an AWS-hosted resource.
Where the log has to live
Put the audit log on the far side of the access boundary, in a store the agent has no write path to. Pair it with the access record so a single query returns who was granted what, for how long, what they did, and what they were denied. CloudTrail still has a role as an account-level source, but it sits underneath this, not in place of it.