What We Learned Giving an AI Agent Read Access to Our Whole Kubernetes Fleet

Read-only is the word that gets agent deployments approved. It tells you what an agent cannot write. It tells you nothing about what it can reach, who it is, or what it costs when it goes sideways.

Four ways a read-only agent still breaks

Failure classes, not a bug list. None of them requires the agent to write anything.

Class 1

Confidentiality

The assumption

Read-only is observation, so the blast radius is close to zero.

Why it fails

Read scope is coarser than reviewers believe. The switch that grants pod events and logs commonly grants Secret objects too, and the material people assume it protects — environment values in a pod spec, config contents — is reachable by an ordinary pod read anyway.

Read-only does not grant access to secrets. It grants access to things that happen to contain them.

→ Rungs 1 and 3

Class 2

Attribution

The assumption

It is read-only, so an existing service account is good enough to start with.

Why it fails

An agent sharing an identity with anything else produces audit lines nobody can attribute. Read-only tells you nobody wrote. It does not tell you who read.

Non-human identity is the control that makes every other control legible. Without it you cannot attribute an action, so you cannot bound a blast radius, so you cannot honestly claim you have one.

→ Rung 2

Class 3

The confused deputy

The assumption

Each agent instance is wired to one target, so it can only ever see that target.

Why it fails

If the tool call takes the target as a parameter, the model fills it in — and it will pass a nickname someone typed in chat, or guess. Read-only against the wrong target is still the wrong data.

The oldest bug in cloud, wearing a new hat: trusting a caller-supplied tenant identifier. What is new is only that the caller is now a language model instead of a browser.

→ Rung 2, from the other direction

Class 4

Availability

The assumption

Read-only means low impact. Reading cannot hurt anything.

Why it fails

The model decides how much to fetch and how many calls to chain. Large output plus chained calls can grow one investigation until it exhausts its own budget. An agent that only reads is still a workload that can amplify itself.

"Please be concise" is a request. An output cap is a control.

→ Rung 1

Class 1Every box is documented Kubernetes behaviour, which is exactly why the scanner stays green.

Class 3The talk shows one of these four vectors. The fix is the same in every row: derive the value from the session or the workload identity, never from the caller.

Not one of the four requires a write.

Every control that holds is infrastructure. Every control that fails is a prompt.

The containment ladder

Climb from the bottom. Each rung makes the one above it enforceable, and none of them asks anything of the model.

1. 01
   Scoped capability Fix the capability set at the tool server, not in the prompt. Deny by default, budget every output. A tool that is never registered needs no instruction telling the model to avoid it. Answers classes 1 and 4
2. 02
   Per-agent identity One identity per agent, issued by the platform and carried into every trace. This is what makes "agent or human?" answerable by construction rather than by investigation. Answers classes 2 and 3
3. 03
   Egress as a capability Outbound network is a grant, not a default. Expect two layers, because one will have a hole. Private data, untrusted input and an outbound channel is the lethal trifecta, and an investigation agent has all three. The second layer under class 1
4. 04
   Human gates on writes A write path a named human signs for, enforced outside the context window where it cannot be evicted or argued away. The rung nobody reaches by accident

Nothing on that ladder is AI security. Access control. Workload identity. Egress control. Approval workflows. It is cloud security applied to a new kind of workload, which is the point — you already know how to do this.

Where the missing control would sit

Scope, identity and egress all bound what an agent can get to. None of them bounds what enters the context window once a permitted read succeeds.

The askThe interception point is layer two. By the time content is in the context window it is too late to scan it. If you have built this, I want to hear about it.

One link per class

• The Containment Ladder The whole framework, with the public incident record behind each rung, and the citations for everything on this page.
• What "Read-Only" Actually Reaches Class 1 — a reproducible permission audit you can run against your own cluster this week.
• What It Would Take to Give My Agent a Real Identity Class 2 — where the standards point, and why there is no standard yet.
• Finding the Confused Deputy in Your Own Agent Class 3 — a taxonomy and a hands-on test.
• The Missing Control: A Design Proposal for Tool-Output Redaction The ask — the design, written up so you can argue with it or build it.

This page is written at pattern level on purpose. It carries the argument and the controls, not an incident report, and it describes no particular system. If you want the reasoning behind a specific claim, or you have solved the redaction problem, email me — that conversation is the reason the page is short.