OWASP Top 10 for Agentic Applications, mapped to Kubernetes controls

The OWASP GenAI Security Project published the Top 10 for Agentic Applications in December 2025, as the 2026 edition. It names ten risks, ASI01 to ASI10, for systems where a model plans and acts through tools, memory and other agents. The document is a good threat vocabulary, but it is written for every kind of runtime. If your agents run on Kubernetes, the useful question is narrower: which of these risks can the platform contain, with which object, and what is left to the application?

This guide answers that question one risk at a time. For each ASI entry you get a short summary of the OWASP description, the Kubernetes controls that limit the damage, and the gaps that no cluster setting closes. The controls are standard Kubernetes features from the official documentation: ServiceAccounts and RBAC, Pod Security Standards, admission policies, NetworkPolicy, RuntimeClass and audit logging. Where my own work applies I link it and state its scope.

The one idea behind the mapping

OWASP's own guidance repeats one point across several entries: you cannot rely on the model to notice that it is being manipulated. The platform has to assume that any agent can be steered by the content it reads, and make sure that a steered agent can do little harm. Kubernetes is good at exactly that. It does not see prompts, but it controls who a workload is, what it may call, where it may connect and what it may execute.

So the mapping below is about blast radius, not detection. A pod that cannot reach the internet cannot exfiltrate to it, whatever the prompt said.

Overview table

The rest of the guide goes through each row.

ASI01: Agent Goal Hijack

OWASP describes goal hijack as an attacker redirecting the agent's objectives, usually through injected instructions in content the agent processes: a document, an issue, a web page, a tool description. The cited incident is a copilot turned into a silent exfiltration channel.

Kubernetes cannot stop the hijack itself. It can stop the hijacked agent from finishing the job:

• Default-deny egress. Start each agent namespace with a NetworkPolicy that denies all egress, then allow DNS and the exact services the agent needs. Note that standard NetworkPolicy works on IPs and ports, not hostnames. For per-host allowlists route traffic through an egress proxy or use your CNI's FQDN policies.
• No ambient credentials. If the pod does not need the Kubernetes API, set automountServiceAccountToken: false. A hijacked agent with a cluster token is a much bigger incident than one without.
• A pre-execution gate for tool calls. The decisive moment is not when the model reads the injected text but when it calls a tool. Evaluate every call against an approved policy before it runs, and fail closed.

That last point is what I built the Agent Security Contract for: a YAML capability policy, a pinned digest of the tool catalog, and a verdict of ALLOW, BLOCK or REQUIRE_APPROVAL for each call, available as CLI, GitHub Action and HTTP sidecar. The repo is explicit that it is not a prompt-injection detector inside the model. It limits what an injected instruction can make the agent do.

ASI02: Tool Misuse and Exploitation

Here the agent uses a legitimate tool in a harmful way: deleting more than intended, sending data to the wrong host, chaining calls. The tool is allowed; the specific use is not.

Controls that help:

• Argument constraints, not just tool allowlists. Allowing http_get is not enough. Constrain hosts, paths, sizes and patterns per argument, and reject undeclared arguments.
• Path canonicalization. Decode, normalize and resolve .. before checking path allowlists. Many "allowed path" checks fail on encoded traversal.
• Per-tool credentials. Give each tool its own scoped credential in its own Secret, mounted only into the component that executes it. A read-only tool should not hold a write token.
• Rate limits per trace and per tool. Loops and mass actions are a misuse pattern on their own.

In the Agent Security Contract these are part of the policy contract: per-argument type, pattern, deny patterns, allowlisted hosts and max length; path canonicalization before allowlist checks; per-trace and per-tool rate limits. Its corpus tags most attack scenarios with ASI02 or ASI03. The published results are scoped "on this corpus of 66 scenarios" (33 attack, 33 benign), v0.2.x: 0 critical false-ALLOW and 0 benign false-BLOCK. That is evidence for that corpus and that policy, not a claim of general agent safety.

ASI03: Identity and Privilege Abuse

The agent, or someone controlling it, uses credentials beyond the intended scope: inherited user tokens, over-broad service accounts, leaked keys. OWASP also maps this entry to its Non-Human Identities Top 10 in an appendix.

Kubernetes controls:

• One ServiceAccount per agent and per MCP server. Never the namespace default account.
• RBAC scoped to the namespace and verbs needed. Agents rarely need list on Secrets or any cluster-scoped permission. Review with kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa>.
• Short-lived, audience-bound tokens. Use projected ServiceAccount tokens with an explicit audience and expirationSeconds instead of long-lived Secret-based tokens.
• No token passthrough. The MCP specification says servers must not accept tokens that were not explicitly issued for them. Validate the audience at the MCP server and do not forward the client's token downstream.

A minimal projected token for an agent that calls one internal API:

apiVersion: v1
kind: Pod
metadata:
  name: research-agent
  namespace: agents
spec:
  serviceAccountName: research-agent
  automountServiceAccountToken: false
  containers:
    - name: agent
      image: registry.example.com/research-agent@sha256:<digest>
      volumeMounts:
        - name: api-token
          mountPath: /var/run/secrets/tokens
          readOnly: true
  volumes:
    - name: api-token
      projected:
        sources:
          - serviceAccountToken:
              audience: docs-api
              expirationSeconds: 600
              path: docs-api-token

ASI04: Agentic Supply Chain Vulnerabilities

The supply chain of an agent is wider than its container image. It includes MCP servers, tool descriptions, plugins, prompt templates and models fetched at runtime. OWASP's example is a poisoned component in a dynamic MCP ecosystem.

Controls:

• Pin images by digest and enforce it at admission. A ValidatingAdmissionPolicy (built into Kubernetes, CEL-based) or a policy engine such as Kyverno or OPA Gatekeeper can reject pods whose images are not from approved registries or not pinned.
• Pin the tool catalog. A tool description is executable input for the model. Approve the catalog, hash it, and refuse to run when the served catalog no longer matches the approved digest.
• Keep MCP servers in their own namespace with their own egress rules, so a compromised server cannot reach the agent's data stores.

A simple admission rule that rejects images without a digest:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: agents-require-image-digest
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: "object.spec.containers.all(c, c.image.contains('@sha256:'))"
      message: "agent pods must pin images by digest"

Bind it to the agent namespaces with a ValidatingAdmissionPolicyBinding. The Policy as Code Guardrails case describes how I roll out rules like this: CI feedback first, admission enforcement second, and a documented exception path so teams are not blocked by surprise.

ASI05: Unexpected Code Execution

Agents that write and run code, or tools that pass strings to a shell, turn natural language into execution. OWASP's example is remote code execution through an agent framework.

Controls:

• Pod Security Standards at restricted for agent and tool namespaces: non-root, no privilege escalation, dropped capabilities, a seccomp profile. Enforce with namespace labels.
• A sandboxed RuntimeClass (for example gVisor or Kata Containers, if your nodes support them) for any pod that executes generated code.
• Read-only root filesystem and an emptyDir scratch volume with a size limit.
• No egress from code-execution pods except where explicitly required.

apiVersion: v1
kind: Namespace
metadata:
  name: agent-sandbox
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

At the tool-gate level, treat shell-like tools as high impact: constrain arguments tightly or require approval.

ASI06: Memory and Context Poisoning

An attacker seeds long-term memory, summaries, embeddings or RAG stores, and the poisoned content influences later sessions. This is the risk Kubernetes helps least with, because the poison is valid data.

What the platform can do:

• Separate memory stores per tenant or per agent, in separate namespaces, with NetworkPolicy so only the owning agent can reach them.
• Separate write paths from read paths. Agents that read from a knowledge base should not hold write credentials for it.
• Log writes to memory with provenance: which agent, which session, which source. This makes clean-up possible after an incident. The AI agent audit trail guide covers what to record.

Content validation and provenance checks stay in the application.

ASI07: Insecure Inter-Agent Communication

Multi-agent systems exchange messages over APIs, queues and shared memory. Without authentication and integrity, messages can be spoofed, intercepted or replayed.

Controls:

• mTLS with workload identity between agent services, through a service mesh or a SPIFFE-based setup.
• Authorization per caller identity, not per network location: agent A may call agent B's plan endpoint, nothing else.
• NetworkPolicy as the second layer, so a misconfigured mesh policy does not open everything.

The Zero Trust Service Mesh case describes the model I use for east-west traffic: workload identity, mTLS, authorization policy, traffic telemetry and progressive rollout. For agents the same model applies, with one addition: the message content is still untrusted input for the receiving agent, even when the transport is authenticated.

ASI08: Cascading Failures

One fault, such as a hallucinated plan, a poisoned memory entry or a broken tool, propagates through automated agents faster than humans react.

Controls:

• Resource requests, limits and ResourceQuota per agent namespace, so a runaway loop cannot starve other workloads.
• Rate limits and budgets at the gateway: per tenant, per agent, per tool. A budget that fails closed is a circuit breaker.
• Timeouts that fail closed. If the policy sidecar does not answer, block. The Agent Security Contract's client does this by default.
• PodDisruptionBudgets and separate node pools for critical non-agent workloads.

ASI09: Human-Agent Trust Exploitation

The agent's confident explanations push a human into approving a harmful action. A human-in-the-loop only helps if the human sees what will really happen.

Controls:

• Approvals outside the agent. The approval must be recorded by a component the agent cannot write to, and the approved action must be bound to exact arguments.
• Show the action, not the agent's summary of it. The approver sees the tool, arguments and target.
• Keep evidence of the decision. In the Agent Security Contract, high-impact tools return REQUIRE_APPROVAL unless the call carries an approval, and destructive paths that resolve to a parent or root still BLOCK even when approved.

ASI10: Rogue Agents

An agent deviates from its intended function, through compromise or misalignment, while each single action looks legitimate.

Controls:

• A kill switch you have tested: scale the Deployment to zero, or flip a deny-all policy for the agent's identity at the gateway and the tool gate.
• An audit trail that links actions to identity and policy version, so you can reconstruct what the agent did and under which rules.
• Isolation by default, so a rogue agent is limited to its own namespace, credentials and egress.

Behaviour monitoring itself is not a Kubernetes feature. Kubernetes audit logs show API calls, not tool calls, so you need application-level evidence too.

What the platform cannot do

To be clear about the limits:

• Kubernetes does not see prompts, model outputs or tool semantics.
• NetworkPolicy does not understand hostnames or HTTP paths.
• An authenticated message can still carry malicious instructions.
• A pre-execution gate checks calls against a policy. It is only as good as the policy and the scenarios you test it with.

The practical approach is layered: platform controls for identity, isolation and egress; a fail-closed gate on tool calls; and an audit trail that lets you prove afterwards what was allowed and why. For the MCP-specific items, see the MCP security checklist for Kubernetes.

Checklist

• Each agent and MCP server has its own ServiceAccount; token automount is off unless needed
• Agent namespaces enforce Pod Security restricted
• Default-deny egress plus explicit allows; per-host control through an egress proxy or CNI FQDN policy
• Images pinned by digest, enforced at admission
• Tool catalog approved and pinned by digest; drift blocks execution
• Every tool call evaluated before execution; timeouts fail closed
• High-impact tools require an approval bound to exact arguments
• mTLS and per-caller authorization between agents
• Quotas, limits and budgets per agent namespace
• Audit trail for tool calls, approvals and memory writes, linked to policy version
• A tested kill switch per agent

References

• OWASP Top 10 for Agentic Applications for 2026: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
• OWASP announcement of the Agentic Top 10 (incident examples per entry): https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
• OWASP AI Agent Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
• MCP specification, security best practices (token passthrough): https://modelcontextprotocol.io/specification/draft/basic/security_best_practices
• Kubernetes Pod Security Standards: https://kubernetes.io/docs/concepts/security/pod-security-standards/
• Kubernetes Network Policies: https://kubernetes.io/docs/concepts/services-networking/network-policies/
• Kubernetes ValidatingAdmissionPolicy: https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/
• Kubernetes service account token projection: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
• Kubernetes RuntimeClass: https://kubernetes.io/docs/concepts/containers/runtime-class/
• Kubernetes auditing: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
• Agent Security Contract (policy contract, evidence, limits): https://github.com/justrunme/agent-security-contract