The EKS control plane already writes an audit log. So why is "who did what" still hard to answer when an AI agent is in the loop? Because the Kubernetes audit log records the service identity that hit the API server, and if your agent shares a kubeconfig or a service role, every action shows up as the same caller. Audit logging that is actually useful has to attribute commands to the real actor, the specific agent, not the shared credential it borrowed.
Audit logging for AI agents on EKS is the gap between "the cluster logged an API call" and "we know which agent ran it and why." Closing that gap is the job, and it is harder than enabling a log.
What the cluster log can and cannot tell you
The Kubernetes audit log is real and worth keeping. But it sees the identity on the connection, not the human or agent behind it. When the gateway agent reaches the cluster as a service role, the cluster sees that role. To attribute an action to agent-deploybot versus agent-reporting, you need a record that captures the caller's identity at the point they authenticated, before the command went to the cluster. The control plane log simply does not have that information; by the time the request reaches the API server, the original actor has been abstracted into a service identity.
Where that attribution happens in audit logging
hoop.dev is an open-source Layer 7 access gateway. Its kubernetes-eks connector proxies kubectl and exec through a network-resident agent that assumes a configured IAM role, the EKS_ROLE_ARN, mapped to Kubernetes RBAC. The agent authenticates to hoop.dev as its own non-human identity, so the gateway knows exactly which agent issued each command. Its audit logging records that command, the agent identity, and the result, independent of the cluster's own log.
The two logs complement each other. The cluster log proves the API server saw the call; the gateway audit log proves which agent caused it. You want both, in the same store, so a reviewer can line them up.
Setting it up
- Configure the EKS connection with cluster URL, region, cluster name, and the IAM role ARN mapped to a scoped RBAC role.
- Register each AI agent as a distinct identity so audit logging can tell them apart.
- Enable command-level audit logging on the connection.
- Ship the gateway audit log to the same store as your Kubernetes audit log so reviewers see both side by side.
- Verify by running a command as one agent and confirming the gateway log shows that agent's identity, not just the service role.
# gateway audit entry: actor is the agent, not the role
ts=2026-06-15T12:04:01Z actor=agent-deploybot
action="kubectl scale deployment/api --replicas=5 -n web"
connection=prod-eks result=allowed
Read that entry next to the cluster log line for the same moment and the picture is complete: the API server saw a scale request from the service role, and the gateway knows it was agent-deploybot that issued it, and that policy allowed it. Neither log alone gets you there.
Pitfalls
- Do not let agents share an identity. If two agents log in as one, audit logging cannot separate them, and the cluster log certainly cannot.
- Do not keep only the cluster log. It cannot name the agent behind a shared service role.
- Do not store the gateway log where an agent's service role can edit it. Audit evidence has to be independent of the actor.
The argument, and the evidence it generates
One log tells you the API server was called. The other tells you which agent called it and whether policy allowed it. audit logging needs the second, and hoop.dev produces it at the gateway. That per-actor record is also what teams use to generate evidence for frameworks like SOC 2. Start with the getting started guide and read more on per-actor audit trails.
FAQ
Does hoop.dev replace the Kubernetes audit log? No. It adds per-agent attribution at the gateway. Keep the cluster log too; they answer different questions.
How is each agent identified? Each agent authenticates to the gateway as a distinct non-human identity, so audit logging records that identity per command.
Can this support a compliance program? Yes. The per-actor record generates evidence teams use for frameworks like SOC 2. hoop.dev does not make the cluster itself certified.
hoop.dev is open source and MIT licensed. Get it at github.com/hoophq/hoop and give your EKS audit logging an actual actor on every line.
