Securing AI Agents in Production: Why Kubernetes Isn't Enough

Teams deploying LLM-powered agents on Kubernetes usually feel confident. They have namespaces, RBAC, network policies, PodSecurityAdmission. What they've secured is the infrastructure. The threat model for AI agents is different.

A container serves a request and returns a response. An agent plans, decides, and acts — calling APIs, reading files, writing to databases, sometimes spawning other agents. The attack surface isn't the container boundary. It's every decision the agent makes and every credential it holds to execute those decisions. Kubernetes has no visibility into any of that.

TL;DR — eight controls Kubernetes doesn't cover

1. Agents differ from containers — they take actions, hold credentials, and can be manipulated through their inputs
2. Namespace isolation is necessary but insufficient — it doesn't stop an agent from misusing the access it already has
3. Prompt injection is the new code injection — no network policy blocks it
4. OWASP Top 10 for LLM Applications is the clearest practical lens on agent-specific risks
5. Each agent role needs its own scoped identity — not a shared service account
6. Short-lived credentials only — static API keys in environment variables have no place in agent workloads
7. Every tool your agent can call is an implicit permission — audit it like a user account, not a library import
8. Runtime monitoring and policy-as-code are the layer most teams skip entirely

This post focuses on the gaps between standard Kubernetes security and what autonomous AI agents actually require. If you haven't already locked down the Kubernetes layer itself, our Kubernetes configuration guide covers the baseline.

Agents aren't just containers

The mental model most teams bring to AI workloads is container security: harden the image, configure RBAC, enable pod security standards. That baseline matters — but it covers a small fraction of what makes an AI agent dangerous when compromised or manipulated.

A conventional service does what its code specifies. An AI agent does what its instructions say — and those instructions can be influenced by content the agent processes. A crafted document, a poisoned database record, a malicious string in a web page the agent fetches — any of these can redirect an agent's behavior at runtime. That's prompt injection, and it's a fundamentally different threat class than what Kubernetes controls were designed to stop.

The CNCF security community has been explicit about this: Kubernetes provides workload isolation — it doesn't provide isolation of a workload from its own behavior. For AI agents, the threats live inside the container: in the prompt pipeline, in the tool calls, and in the context window that connects instructions to actions.

Why namespace isolation isn't enough

Namespace isolation prevents Pod A from reading Pod B's secrets. That's important and worth configuring correctly. It does not prevent Pod A from being instructed — via a user's malicious input or a poisoned data source — to call an external API with the credentials it already legitimately holds.

Consider what standard Kubernetes controls actually see:

• NetworkPolicy restricts east-west traffic between pods, but doesn't inspect the content of outbound HTTPS requests your agent makes to external APIs
• RBAC limits which Kubernetes objects the agent's service account can touch — it has no visibility into what the agent does with the cloud credentials it already has
• PodSecurityAdmission catches privilege escalation in the container spec — it has no concept of an LLM-generated action taken at runtime

The perimeter is secured. The actor inside the perimeter — the agent and its runtime decisions — is not. You need a separate threat model for what happens after the pod starts.

The OWASP Top 10 for LLM Applications as a practical lens

The OWASP Top 10 for LLM Applications was published specifically because the web application threat model doesn't transfer cleanly to LLM workloads. For SMBs running agents in production, three entries deserve immediate attention.

LLM01 – Prompt injection: An attacker embeds instructions in data your agent processes — a support ticket, a document, a search result — that hijack the agent's behavior. There is no kernel-level defense against this. Mitigate with input validation at ingestion, output parsing before any action is taken, and strict separation of untrusted data from the system prompt context.

LLM06 – Excessive agency: The agent has more permissions than its task requires. An agent answering customer support questions shouldn't be able to write to your production database or invoke billing APIs. The scope of what an agent can do should be tightly bounded to what it needs to do for its defined task.

LLM08 – Excessive permissions: Closely related but at the credential layer — the underlying service account or API key grants more access than the task needs. An agent that only needs to read one S3 bucket should have an IAM policy that can only read that bucket, not s3:*.

The full OWASP list is worth reading before you go to production. For most SMB teams, LLM01, LLM06, and LLM08 are where the real exposure concentrates. For how the least-privilege principle extends beyond the Kubernetes layer into your network and identity architecture, see our zero-trust security guide for SMBs.

Agent identity and least privilege

Most teams give all their AI workloads the same Kubernetes service account, or one broadly scoped account per cluster. That's the equivalent of giving every employee in the building the same master key and assuming physical locks cover the risk.

Treat each agent role as a distinct identity with its own access boundary:

• Create a dedicated Kubernetes service account per agent function — one for the customer support agent, a separate one for the code review agent, none shared
• Bind pod identity to cloud IAM using IRSA (AWS IAM Roles for Service Accounts) or GCP Workload Identity — no static credentials stored in environment variables or Kubernetes secrets
• Issue short-lived tokens: configure token expiration shorter than your typical session length so a leaked credential has a narrow exploitation window
• Scope IAM policies to the specific resource each agent role needs — one bucket, one table, one queue — not a wildcard on the service

Short-lived, scoped credentials also reduce the blast radius when prompt injection succeeds. The agent may be coerced into exfiltrating a token; if that token expires in 15 minutes and only reads one S3 prefix, the damage is bounded. Our PKI fundamentals guide covers the certificate lifecycle principles that apply equally to automated workloads and short-lived credentials.

Unsure where your agent workloads are overexposed? PlatOps can map the permissions your agent roles actually use versus what they're granted — and identify where your posture has real gaps. Run a free assessment to see where you stand.

Tool and API access control

Every tool your agent can call — a function, a database query, an API endpoint — is an implicit permission grant. LLM frameworks make it trivially easy to wire up a broad toolkit. The ease is the risk.

Audit your agent's tool list the way you'd audit a user account's permissions:

• Document every registered tool and what it can do at the data layer — reads, writes, deletes, external calls
• Remove any tool the agent doesn't need for its defined task scope; don't leave tools in because they might be useful later
• Wrap external API calls through a proxy or API gateway that logs requests, enforces rate limits, and can block specific endpoints without redeploying the agent
• Never give an agent direct write access to production infrastructure via a tool that's callable through the prompt — writes to infrastructure should require an out-of-band confirmation step

The same RBAC discipline Kubernetes applies to cluster resources should apply to your agent's action space. The tool list is the agent's permission list. Treat it that way.

Secrets in context windows

Credentials that appear in an agent's context window are one of the most underappreciated attack surfaces. An agent that has been handed a connection string, an API key, or a session token — even as a convenience — can be instructed to output that value. Prompt injection makes this straightforward to exploit.

Practical controls:

• Never pass raw credentials into a prompt or system message. Use a secrets manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault) and resolve credentials at the service layer — the agent receives a capability object or a pre-authenticated client, not the underlying secret
• Audit your LLM framework's tracing and logging configuration before production. Most frameworks log full context windows by default; this means credentials that enter the context end up in your observability platform's storage
• Redact known secret patterns from logs aggressively — access key formats, connection string patterns, bearer token formats
• Treat any credential that has appeared in a context window as potentially compromised. Rotate it

Runtime monitoring and guardrails

Static controls — RBAC, tool lists, credential scoping — are your posture. They're not real-time detection. You need observability at the agent behavior layer, not just the infrastructure layer.

• Log every tool call with its full inputs and outputs, not just the top-level prompt and response pair. A compromised agent will look normal at the conversation layer but anomalous at the tool-call layer
• Set rate limits and circuit breakers on individual tool calls — an agent that invokes an external API 200 times in a minute is exhibiting behavior that warrants an alert, not silent execution
• Implement output validation before any agent response triggers a write operation. If the expected output is a JSON object with a defined schema, reject anything that doesn't conform — don't let unexpected output flow into a database write
• Define a behavioral baseline for each agent role and alert on deviations. Anomaly detection doesn't need to be sophisticated; unusual call volume, unusual target endpoints, or unusual output size are often sufficient signals

Policy-as-code

The same GitOps discipline you apply to infrastructure should extend to agent configuration. Define agent roles, tool grants, allowed model behaviors, and permission boundaries in version-controlled policy files. Review changes in pull requests. Enforce them with admission controllers or your agent framework's policy layer.

OPA (Open Policy Agent) or Kyverno can enforce cluster-level rules — for example, "no agent pod may use a service account with cluster-admin bindings" or "agent pods must declare CPU and memory limits." That prevents configuration drift from reaching production silently. Your agent framework's own policy configuration should be treated with the same rigor: changes to which tools an agent can call are security-relevant changes, not just configuration updates.

How to audit your agent security posture in 30 minutes

1. List every service account your agent pods use — identify any shared accounts or accounts with wildcard IAM policies
2. Enumerate every tool and external API your agent can call — remove anything not strictly required for its defined task
3. Search your agent framework's logging config for full-context or prompt logging — disable or redact before production
4. Verify that credentials are resolved from a secrets manager at runtime, not embedded in environment variables, Kubernetes secrets, or prompt strings
5. Check that output validation exists before any agent response triggers a database write, API call, or infrastructure change
6. Confirm each agent pod uses a dedicated, scoped service account — not a shared one

Frequently asked questions

Why doesn't Kubernetes RBAC protect against prompt injection? RBAC controls which API calls a service account can make to the Kubernetes API server. Prompt injection exploits the LLM itself — it makes the model generate outputs that misuse the permissions the agent already has. The attack is inside the trust boundary that RBAC creates, not against the boundary from outside. The two controls operate at completely different layers.

Which OWASP LLM risk should we fix first? Excessive agency (LLM06) first, because limiting what an agent can do reduces the blast radius of every other risk — including prompt injection. A narrowly scoped agent that gets successfully injected causes less damage than a broadly scoped one. Once you've tightened the permission boundary, work on input validation and output handling to reduce injection exposure.

Do these controls apply to managed AI APIs, not just self-hosted models? Yes. Whether you're running a self-hosted model on a GPU node or calling a managed API, the tool-call permissions, secrets handling, output validation, and runtime monitoring requirements are the same. The container security baseline differs; the agent logic security layer is identical regardless of where the model runs.

---

Kubernetes is the right foundation for deploying AI workloads. It's not a complete security strategy for them. The gaps — agent identity, tool access, secrets handling, runtime behavior — require an explicit second layer that most teams haven't built yet.

If you'd rather not build that layer from scratch, PlatOps handles security architecture and DevSecOps for SMBs running cloud-native workloads — including LLM agent deployments. Book a free assessment to see where your current posture stands.