← Atlas · Frameworks & standardsOWASP LLM Top 10 · 2026

LLM10:2026 · in agentic systems

LLM10:2026: Improper Output Handling (agentic delta)

Model output passes downstream to other components without validation or sanitisation.

What changes in an agent loop

In a chatbot, output handling is a presentation concern: render the model's reply safely in the UI, escape HTML, done. In an agent, every tool invocation is an output handling boundary: the model produces SQL fragments, shell arguments, API payloads, and messages to peer agents, and a tool executes each one directly. An unsanitised SQL fragment causes injection at the database; an unsanitised shell argument executes in the sandbox; an unsanitised peer-agent message becomes that peer's next instruction and can carry a prompt injection forward. There is no human reviewer between model output and tool execution; the plan-act loop closes without one. This is why agentic deployments need sanitisation and schema validation applied at every tool-call boundary, treating each generated parameter as untrusted input even when the calling model is internal.

For the full definition, prevention checklist, and detection guidance, read OWASP's Improper Output Handling page →. This page only adds the agentic angle and the bridge into Helmwart.

Where this lands in the agentic catalog

The canonical threats a reader should look at first for LLM10:2026, with the ASI Top 10 entries each one is inherited through. This is the LLM → ASI → threat bridge in full.

Mitigations

Kernel-isolated sandbox — agent-executed code runs against its own kernel, not the host'sT1

When an agent executes generated or retrieved code, that code runs as a process with access to the host kernel. A vulnerability in the generated code, or a deliberate exploit injected through the agent's prompt, can reach the kernel and affect other workloads or the host itself. A kernel-isolated sandbox removes that path by giving the workload a kernel of its own: gVisor interposes a user-space kernel so syscalls reach the Sentry rather than the host, and Kata Containers runs the pod in a lightweight VM with a separate kernel. Which one is available is a property of the platform, not of the control — AKS ships Kata as Pod Sandboxing and does not support gVisor; GKE ships gVisor.

Open Policy Agent — a policy-as-code engine for every tool call an agent makesT1

An agent can invoke any tool it has access to, constrained only by its own reasoning. If that reasoning is manipulated or the agent's permissions are misconfigured, it will call tools it should not. OPA addresses this by placing a policy decision point between the agent and every tool invocation: a Rego policy evaluates the agent identity, the tool, and the parameter envelope before execution proceeds, and the agent cannot reason or argue past the result.

Code-generation review gate — human approval before AI-generated code executes or mergesT2

An AI coding agent produces code that can be executed or merged to a production branch without a human ever reading it. If the agent has been manipulated, its generated code can contain hidden payloads, backdoors, or privilege-escalating logic. A code-generation review gate prevents that: every change attributable to an AI agent must pass automated static analysis and receive explicit human approval before it can merge or execute, and the agent identity that authored the change is structurally barred from also approving it.

Data classification with tool-access allow-lists — a sensitivity label on every dataset, enforced at every access seamT2

Every dataset, document, and external system an agent can reach carries a classification label. The agent's permitted-class set and the tool's permitted-class set are intersected at the moment of every read or write. When the requested data's class falls outside that intersection, access is denied at the seam. This is the data-side complement to least-privilege: it adds a data-sensitivity constraint that role scoping alone does not provide.

Human dual-control — four-eyes rule for irreversible high-impact approvalsT2

An AI agent operating with broad authority can propose actions that are irreversible: deleting records, modifying IAM policies, moving funds. A single human reviewer at the approval gate is a single point of failure, one compromised account, one fatigued reviewer, or one successful social-engineering attempt is enough to commit the action. Human dual-control addresses that by requiring two distinct, independent humans to approve before the action commits.

Output egress DLP — inspection gate for PII, secrets, and IP at the agent boundaryT2

An agent produces output continuously across multiple channels: user-facing responses, tool-call parameter envelopes, log records, and outbound HTTP requests. Any of those channels can carry sensitive content the agent has retrieved, been fed, or been tricked into including. Output egress DLP places an inspection gate at the boundary so that PII, credentials, and proprietary content are classified and either redacted or quarantined before they leave the trust boundary, regardless of how they got into the output.

Network egress isolation — deny-by-default agent→internet, enforced at the network layerT2

Content-layer inspection reads outbound payloads and decides pass, redact, or quarantine per channel — but it can only classify what it can parse as content. A direct TCP/UDP socket opened by agent-executed code, a raw DNS query, or a payload encoded into DNS subdomain labels never reaches an HTTP-shaped inspection point at all. Network egress isolation closes that gap one layer down: every agent and tool-bus process sits behind a default-deny network policy, and the only path to the internet is through an enforced proxy that mediates, allowlists, and logs each connection attempt regardless of what it contains.

Just-in-time tool grants — ephemeral access scoped to a single taskT2

An agent that holds a persistent catalog of invokable tools can reach any of them at any point in its session. If its reasoning is manipulated or its identity is compromised, that persistent surface is fully available to an attacker. Just-in-time tool grants remove the standing surface: a policy broker issues a time-bound, task-scoped grant immediately before the tool is needed and revokes it automatically when the task completes or the window expires.

Kill switch: human authority to halt one agent, a class, or the entire deploymentT2

Agentic systems can act faster than a human can intervene through normal channels. A kill switch is the operational guarantee that a named human role can stop agent activity at any scope (single instance, class, or global) through a documented runbook, without requiring a code change or redeployment, and with every invocation written to an audit trail.

Pre-execution validation — a two-pass gate on every tool call an agent makesT2

An LLM produces tool-call arguments through generation, not through a type system, and generation is not reliable. The arguments may be wrong in type, out of range, or assembled in a combination that violates business rules. A pre-execution validation gate intercepts the call before it reaches the tool: a schema pass confirms each argument conforms to the declared JSON Schema, and a policy pass confirms the argument combination is permitted for this agent and this action. The tool executes only when both passes clear.

Secret scanning on agent-generated artefacts — detecting credentials before they escape the trust boundaryT2

An agent produces code, configuration files, tool-call payloads, and log records continuously and at a rate no human reviewer can match. Any of those artefacts may contain a live API key, service token, or private certificate, placed there accidentally through model context, or deliberately through prompt injection or context poisoning. Secret scanning places an inspection gate at every agent output seam: regex patterns match known token formats, entropy analysis detects arbitrary high-entropy strings, and validator calls confirm which candidates are live credentials. The CI-secret-scanning pattern is mature; the agentic specialisation is seam placement, moving the scanner from the repository gate to the agent egress point, where artefacts can be intercepted before they reach any downstream system.

Static analysis on generated code — a pre-execution gate on LLM-emitted artifactsT2

An agent that can generate and execute code treats code generation as a tool call and code execution as the outcome. If the generated code contains a known-dangerous pattern, no amount of prompt engineering stops it from running once the execute call goes through. Static analysis closes that gap: it scans every code artifact the agent emits against a rule set before execution is permitted, catching the vulnerability patterns the same tooling already catches in human-written code.

Least-privilege tool scoping — a hard boundary on what each tool exposesT2

Each tool in an agent's catalog should expose only the methods, resources, and parameter ranges its designated role requires. Over-broad tool surfaces let individually authorised primitives compose into actions no human intended to grant; narrowing the scope at design time reduces both the attack surface and the blast radius of any compromise.

Intent attestation tokens — a cryptographic binding from user approval to tool executionT3

An agent acts on behalf of the user, but nothing in a standard OAuth bearer token records what the user actually approved. If the agent's planning is manipulated, it can invoke tools with parameters the user never sanctioned, while presenting credentials that look valid. Intent attestation fixes this by issuing a short-lived signed token that encodes the exact action and parameter envelope the user authorised, and requiring the resource server to verify that envelope before executing the call.