Your company shipped an AI agent last quarter. Do you know what Kubernetes permissions it has?

If you work in tech, someone on your team deployed an AI agent this year. Maybe it’s an internal copilot that queries databases. Maybe it’s an MCP server that orchestrates tools across services. Maybe it’s an “agentic workflow” that someone built in a hackathon and quietly moved to production.

These agents are running on Kubernetes. They have ServiceAccounts. They have network access. They have blast radii. And almost nobody is thinking about what happens when one gets compromised.

I’m a Senior Engineer at Cisco, and I’ve spent the last year working on Kubernetes security – specifically, the gap between what security tools measure and what actually matters in production. This newsletter is where I’ll write about what I’m learning, what I’m building, and what I think the industry is getting wrong.

This first post is about the thing that keeps me up at night: we are deploying AI agents onto infrastructure that was designed for stateless microservices, and we haven’t updated our security model to match.

The Mental Model Is Wrong

Here’s how most teams think about Kubernetes security:

  1. Scan container images for CVEs
  2. Apply NetworkPolicies
  3. Set up RBAC
  4. Run a CIS benchmark
  5. Check the box

This works – sort of – when every pod is an independent unit. A web server serves HTTP. A database stores data. A cache caches things. Each pod has a clear purpose, a limited blast radius, and no reason to invoke other pods programmatically.

AI agents break this model. An agent pod doesn’t just serve requests – it makes decisions and takes actions. It calls other services. It delegates tasks. It chains together tools across pods, namespaces, and sometimes clusters. It has agency, and agency requires authority.

The problem isn’t that agents exist. It’s that agents inherit whatever Kubernetes permissions their pod has, and those permissions were configured by someone who was thinking about a microservice, not a decision-making system that can be manipulated through its input.

What Does “Agent Security” Even Mean?

The security research community has been productive. In the last six months alone:

  • Bounded Agents (June 2026) formally proved that safe delegation requires “blast radius monotonicity” – the scope of what an agent can reach should narrow, never widen, at each delegation step.
  • “Delegation Without Trust” (September 2026) tested four popular agent frameworks and found that three provide zero built-in confinement. A compromised agent can invoke any tool with any authority.
  • CAPMAS (September 2026) demonstrated that 99.5% of propagated privileges in standard agent frameworks are unnecessary.
  • MCPTox (AAAI 2026) showed a 72.8% success rate for tool poisoning attacks on MCP servers.

These are real results from serious researchers. The problem is diagnosed. The treatments are proposed. But here’s the question: how many of these solutions are running in production right now?

From what I’ve seen: approximately zero.

Ship & Sleep

There’s a pattern I keep seeing. A research paper proposes a defense mechanism – capability-based delegation, eBPF-enforced scope tokens, zero-trust agent processes. The paper evaluates it on a testbed. The results are strong. The paper gets published.

Then nothing happens in production.

Why? Because production infrastructure has constraints that don’t appear in evaluation sections:

  • Air-gapped networks – the cluster has no internet. Your cloud-hosted security agent can’t phone home.
  • FIPS-hardened kernels – eBPF program attachment is treated as a compliance violation.
  • No DaemonSets allowed – the appliance is certified. Adding a DaemonSet requires a recertification cycle.
  • CRI-O instead of containerd – your tool assumes containerd socket access? Too bad.
  • Change control boards – even if the technology works, deploying it requires six weeks of approvals.

The gap between “this defense works in our evaluation” and “this defense is running on the infrastructure that needs it” is where actual risk lives.

What I Think We Need

I don’t think the answer is more enforcement mechanisms (though we need those too). I think the answer starts with measurement.

Before you can fix agent security, you need to answer three questions:

  1. Where are the agents? Which pods in your cluster are AI agents, MCP servers, or ML workloads?
  2. What can they reach? If agent pod A is compromised, what’s the transitive blast radius through the delegation chain?
  3. Does authority narrow or widen? When agent A calls service B, which calls service C – does the RBAC scope decrease at each step (safe) or increase (dangerous)?

These questions are about assessment, not enforcement. You can answer them without deploying new kernel modules, without adding DaemonSets, without modifying your runtime.

That’s what I’ve been building, and what I’ll write about here.

What’s Coming

I’m planning to write about:

  • The confused deputy problem in Kubernetes agent infrastructure – what happens when an MCP server delegates with more privilege than the caller intended
  • Why CVSS is lying to you – and what to measure instead when you have 40,000 CVEs across a cluster
  • The OWASP Agentic Top 10, practically applied – what each risk actually looks like in a real Kubernetes deployment
  • Building open-source security tools – the engineering decisions, trade-offs, and things that don’t work
  • What I learn from production deployments – anonymized, but real

If you work in Kubernetes, cloud security, AI infrastructure, or you’re just curious about what happens when AI agents meet production infrastructure – subscribe to Ship & Sleep. I think this intersection is going to matter a lot more in the next year than most people expect.

Originally published on Ship & Sleep. Subscribe for weekly posts on Kubernetes security and AI agent infrastructure.