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

No Agent Identity

Kubernetes audit logs identify the principal — the service account or user that authenticated the request. When iddio proxies a request, the principal is iddio’s service account, not the AI agent. The audit log shows “iddio-proxy accessed pods in payments” — not “claude-code accessed pods in payments through iddio.”

Iddio’s audit log includes the agent identity on every event. You can filter by agent, see what each agent did, and compare activity across agents.

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 tiers (T0-T4) and includes the classification in the audit event. You can immediately see “this agent made 500 T0 reads and 3 T3 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, the approver, or the time spent waiting for approval.

Iddio’s audit log includes decision, approved_by, and approval_latency_ms fields. You can see that a delete was escalated, Alice approved it 30 seconds later, and it was forwarded to the cluster.

No Tamper Evidence

Kubernetes audit logs are plain text. They can be edited, deleted, or reordered without detection. Iddio’s hash-chained audit log detects any tampering.

How They Complement Each Other

Dimension	Kubernetes Audit	Iddio Audit
What was requested	Yes	Yes
Who requested it (k8s principal)	Yes	No (it’s always iddio-proxy)
Which AI agent requested it	No	Yes
Risk classification	No	Yes (T0-T4)
Approval workflow	No	Yes
Session recording	No	Yes
Tamper detection	No	Yes (hash chain)
Compliance mapping	Manual	Automated (SOC 2)

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 agent-specific, risk-classified, tamper-evident picture.

Correlation

Iddio includes a request_id in the X-Request-ID header when forwarding to the cluster. If Kubernetes audit logging is configured to capture request headers, you can correlate an iddio audit event with the corresponding Kubernetes audit event:

// Iddio audit event
{
  "agent": "claude-code",
  "request_id": "idd_a1b2c3",
  "tier": 3,
  "decision": "allow"
}

// Kubernetes audit event
{
  "requestURI": "/api/v1/namespaces/payments/pods/api-7d4b8f6c9",
  "user": "system:serviceaccount:iddio:iddio-proxy",
  "requestHeader": {
    "X-Request-ID": ["idd_a1b2c3"]
  }
}

This gives you a complete audit chain: agent → iddio decision → cluster execution.

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.