Kubernetes Audit Logging Is Not Enough

What Kubernetes Audit Logs Give You

Kubernetes has built-in audit logging. When enabled, it records every request that hits the API server: who made the request, what they requested, and what the response was. The audit policy controls what gets logged and at what level (Metadata, Request, RequestResponse).

This is useful. It gives you a complete record of API server activity. But it has blind spots when AI agents are in the picture.

The Blind Spots

Same Principal, Different Actor

Kubernetes audit logs identify the principal — the service account or user that authenticated the request. An AI agent running on a developer's workstation uses the developer's own credentials, so the API server logs user: alice@example.com whether Alice typed the command or her coding agent did. The cluster cannot tell them apart.

Iddio sits on the workstation, in front of the credentials. Its audit log records every request that left the machine through the proxy — including the CLI tool, command, and classification — giving you the workstation-side record the cluster can't produce.

No Risk Classification

Kubernetes doesn't classify requests by risk. A kubectl get pods and a kubectl delete namespace production are logged with the same structure — the only difference is the verb and resource fields. There's no tier assignment, no blast-radius assessment.

Iddio classifies every request into one of four tiers (observe, modify, sensitive, break-glass) and includes the classification in the audit event. You can immediately see "this agent made 500 observe reads and 3 sensitive deletes" without parsing API paths.

No Approval Context

Kubernetes doesn't know about approval workflows. If a request was escalated, approved by a human, and then forwarded — the Kubernetes audit log just shows the final request. There's no record of the escalation or its outcome.

Iddio writes an op=escalate audit row at resolution carrying the approval verdict, so you can see that a delete was escalated and whether the human allowed or denied it before it ever reached the cluster.

How They Complement Each Other

Dimension	Kubernetes Audit	Iddio Audit
What was requested	Yes	Yes
Who requested it (k8s principal)	Yes	No
Workstation-side record per tool	No	Yes
Risk classification	No	Yes (4 tiers)
Approval workflow	No	Yes

The ideal setup is running both. Kubernetes audit logs give you the full API server picture (including non-iddio traffic). Iddio's audit log gives you the workstation-side, risk-classified picture with approval context. Correlating the two is a matter of matching timestamps and request paths.

Recommendation

Run both. Kubernetes audit logging captures everything hitting the API server — including kubectl access from humans, CI/CD pipelines, and controllers that don't go through iddio. Iddio's audit log captures the agent-specific dimension with classification and approval context. Together, they give complete coverage.