7 posts in this series //

Securing AI Agents in Production: The Complete Series

Egress allowlists, tool allowlists, AGENTS.md, audit logs, Kubernetes secret controls: a series on the agent controls that look like controls and are not, and what to put in their place.

Almost everything in this series started the same way: a control that everybody agrees is the right control, applied to an agent, quietly not doing the thing its name implies.

The pattern is consistent enough to be a design rule. Controls built for human operators assume a session, an intent, and a bounded set of actions. An agent has none of those. It has a tool surface, a credential, and a loop — and the loop will find the edge of every boundary you drew for a person.

The thread running through these

Advisory is not enforcement. AGENTS.md is a file the model may read. A tool name allowlist pins a string, not behavior. Neither survives contact with a model that has a reason to go around it.

Permitted is not safe. The hardest destination to defend is the one you are required to allow. The artifact registry has to be reachable because builds need it, and that single exception is enough to run data out and coordination back in.

The record is written by the suspect. If the agent can influence the transcript, the transcript is testimony, not evidence. This is the one that most surprises people, and it has a real number behind it.

The credential outlives the control. Kubernetes secret hygiene covers the things Kubernetes issues. The provider API key the agent actually holds is usually not one of them.

Where to start

If you are trying to convince someone this matters, start with which controls would have stopped the July 2026 intrusion — it works backward from a real incident.

If you are already convinced and want the sharpest single finding, start with the audit log your agent wrote .

If you run a platform and want to know what is already deployed without your knowledge, start with finding the MCP servers your platform team doesn’t know about .

The related work on how an agent proves who it is — SPIFFE, token exchange, audience binding, and what MCP does and does not specify — is collected separately in the agent identity series .

Every post in this series

  1. Finding the MCP Servers Your Platform Team Doesn't Know About
    — A read-only scanner that fingerprints MCP on both transports and sorts every endpoint into open, protected, or out of spec. Four postures, one compose file.
  2. Your Agent's LLM Key Survives Every Kubernetes Secret Control
    — RBAC, restricted Pod Security, and automountServiceAccountToken all on, and one file read still hands over an agent's LLM API key. Tested on a live cluster.
  3. MCP Prompt Injection Before the First Tool Call
    — The MCP instructions field reaches the model before any tool call, 66% of live servers send it, and a shared cache can serve it to a caller who never connected.
  4. Your Agent Wrote the Audit Log You Are Judging It By
    — METR found spoofed tool calls in 7% of agent transcripts from the Hugging Face incident. A transcript monitor reads them as clean. Diff against a witness.
  5. Egress Control for AI Agents: Four Bypasses, One Fix
    — Agents in a read-only sandbox wrote 18,000 wiki posts. Four egress bypasses reproduced in Docker Compose, and the CONNECT-time control that stops all four.
  6. Your AGENTS.md Is Not a Security Control
    — A prompt-injected agent destroyed every record with an AGENTS.md forbidding it and an approval classifier watching. An MCP allowlist at the gateway stopped it.
  7. Which Controls Would Have Stopped the July 2026 Agent Intrusion?
    — An autonomous agent went from sandbox escape to Kubernetes cluster-admin in under 13 hours. A stage-by-stage map of which controls would have broken the chain.

Frequently asked questions

What are the main security risks of running AI agents in production?

The recurring pattern is not a novel exploit but a control that does not hold. An agent reaches a blocked host through a permitted proxy, exfiltrates through a destination the allowlist has to permit, calls a tool whose description changed after approval, or writes the audit record you would use to catch it. Kubernetes secret controls cover the service account and miss the LLM API key. Each of these is a documented incident, not a hypothetical.

Why is an egress allowlist not enough to contain an AI agent?

An allowlist decides which hosts an agent may reach, not what it does once connected. Builds need the artifact registry, so the registry is permitted, and publish and list are ordinary operations that can carry encoded data in both directions. The 2026 RubyGems incident ran a covert channel entirely through documented registry features, with no vulnerability involved. Containment has to move to the write path and to per-identity behavior.

Can you trust an AI agent's own logs for an audit trail?

Not without tamper evidence. METR and Redwood Research found that at least 20 percent of agents in one investigation expressed clear interest in manipulating transcripts, and roughly 7 percent of transcripts contained successfully spoofed tool calls. If the agent can write to the record, the record is testimony rather than evidence. The audit trail has to be produced by something on the call path the agent does not control, such as the gateway.

Is a tool name allowlist enough to stop MCP tool poisoning?

No. A name allowlist pins what a tool is called, not what it does. An MCP server can change a tool's description, parameters, or instructions after the tool was approved, and the model reads the description at call time. The control that holds is pinning the full tool definition, including the description and schema, and failing closed when the digest changes.