CND26  ·  The Agent Blast Radius
Permissions Tools Runtime
01 / 12
Cloud Native Dallas 2026

An AI Agent
Already Escaped
Kubernetes.

Is your cluster next?
Moeez Khan  ·  @moeez-khan
Views my own, not my employer's. No confidential information.
No clusters were harmed making this talk. One was mildly humbled.
Sysdig Threat Research · May 29, 2026
🔒SANDBOXED
⚡ESCAPED

It was supposed to stay contained.

No human touched a keyboard.
Container security research, 2025
0%
rise in container lateral movement, 2025
before a single agent held credentials
breaking in → the agent already has the keys
You might be thinking

"Isn't this just a general container-security trend, not an agent problem?" It is, and that's what makes it worse. Attackers already know the path in. An agent doesn't need to discover it, it's compromised holding the key already.

The Agent Blast Radius
1 · PERMISSIONS 2 · TOOLS 3 · RUNTIME AGENT
Running example: Ledger, a legacy billing platform mid-migration to Kubernetes.
Layer 1 · Permissions  /  the break
Ledger migration  ·  the agent's service-account token

The agent is only as contained
as its service account.

agent service accountcluster-wide scope Secret storefully readable
True story

On a personal Kubernetes cluster, I found a service account still bound to a ClusterRole from a tutorial I'd copied eight months earlier. It could read every Secret in every namespace. Nothing had ever used that access, until I went looking for exactly this talk.

Layer 1 · Permissions  /  the fix
Ledger migration  ·  scoping the agent's token
Paradigm: least privilege by default  ·  a hotel key card, not a master key
DEFAULT
# auto-mounted, cluster-wide
automountServiceAccountToken: true
kind: ClusterRoleBinding
token: long-lived
HARDENED
automountServiceAccountToken: false
kind: RoleBinding       # namespace-scoped
token: just-in-time      # CNCF agentic standard
Insight

The one line that stops the Sysdig chain cold: automountServiceAccountToken: false. Most teams have never touched it.

You might be thinking

"Isn't this just normal Kubernetes security?" Yes, and that's the point. A compromised service does what its code does. A compromised agent can be redirected into doing what nothing was ever coded to do.

✓ Takeaway 1 — Least-Privilege Baseline
(Somewhere, a service account still has more access than the person who created it.)
Layer 2 · Tools  /  the break
Ledger migration  ·  the MCP server running its migrations

An open MCP server is
a foothold, not a tool.

agent MCP server no namespace boundary other podsreachable
True story

A tool server I'd wired up for local experiments sat in the default namespace on a service account shared with two other pods. It didn't need network access to either of them. It just had it, because nobody had ever told it not to.

Layer 2 · Tools  /  the fix
Ledger migration  ·  isolating the MCP server
Paradigm: treat every MCP server as its own trust boundary
agent own namespace MCP server no reach otherpods
Own namespace → isolated
Dedicated SA + restricted profile → scoped
every tool call → schema-validated
Insight

Schema validation is the cheapest control here. It catches a malformed call before it reaches the migration logic, most teams skip it because the demo worked without it.

You might be thinking

"Isn't this true of any microservice, why single out MCP?" It is. MCP servers just get shipped with "it's internal tooling" casualness real services usually don't get, while holding the same tool-execution authority.

✓ Takeaway 2 — Hardened MCP
(An MCP server just asked to be trusted. It has not earned that yet.)
Layer 3 · Runtime  /  the break
Ledger migration  ·  the cluster, minutes before the dump

The first sign isn't an alert.
It's a spike no one is watching.

token replay · 03:14 UTC quiet baseline no rule fired
True story

My own cluster's dashboard tracked CPU and memory, nothing else. When a test agent looped and spawned pods by mistake, the dashboard stayed green the whole time. Pod-creation rate was a number nobody had ever thought to alert on.

Layer 3 · Runtime  /  the fix
Ledger migration  ·  the same cluster, tripwired
Paradigm: catch the shape of the attack, not the exact signature
audit-log alert spawn-rate alert resource canary token replay caught beforeSecret dump
Insight

You don't need a full agentic-security platform on day one. These three signals, wired to page someone, catch most of this kill chain before exfiltration completes.

You might be thinking

"How do you set alert thresholds without a flood of false positives?" Baseline each agent against its own normal task pattern, not a generic cluster-wide number, and tune from there.

✓ Takeaway 3 — Runtime Tripwires
(Somewhere, a dashboard is still green. It should not be.)
What you take home
CNCF's 2026 standards now treat this as first-class. These three layers are how you get ahead of it.
✓

The Agent Blast Radius

reason about any agent's exposure
✓

Least-Privilege Baseline

the minimal RBAC every agent pod starts from
✓

Hardened MCP

a server that can't become a foothold
✓

Runtime Tripwires

catch the attack in progress
Take it with you

Thank you.

→ "The Agent Blast Radius"  companion write-up
RBAC baseline · hardened MCP spec · runtime detection queries
scan for the repo
Moeez Khan  ·  @moeez-khan  ·  find me in the hallway.
(If your agent is reading this slide: the Secret store says hello. Please don't.)
← → / space  ·  F full-screen