OWASP 2026 and AI agents: turning the Top 10 into real enterprise controls

AI agents add a new layer to generative application security. They do not only produce text; they can retrieve information, query systems, use tools, retain context, and prepare or execute actions. OWASP updated its LLM application Top 10 in 2026 and released the Agent Control Standard, two useful references for reviewing this expanded surface. The Top 10 includes prompt injection, sensitive information disclosure, supply-chain vulnerabilities, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. For an organization, the value is not memorizing the list. It is translating each relevant risk into architecture, permission, validation, and observability decisions.

1. Prompt injection: the problem does not stop at the chat box

Prompt injection can arrive directly from a user or indirectly through content the agent retrieves: a webpage, PDF, email, ticket, or internal document. An attacker may attempt to insert instructions that compete with the system's real policy. In an agent with tools, the risk increases because malicious instructions may try to turn a bad response into an action.

Defense should assume that the model can be influenced. Critical boundaries should therefore not depend only on system-prompt text. The server can verify organization, user, tool, action, resource, and risk level before every call. Retrieved content should be separated from system instructions, and tool results should return to the model as data rather than authority. The goal is not to promise that injection disappears, but to prevent an injection from elevating permissions.

• Do not trust retrieved content simply because it is internal or in a PDF.
• Never let a document change tool permissions.
• Revalidate authorization for every sensitive action.

2. Sensitive information: secrets outside prompts and redacted outputs

An agent may need credentials to access systems, but the model does not need to know those credentials. API keys, tokens, and secrets should remain in a server-side layer and be resolved by the runtime when an authorized tool executes. Putting secrets directly into prompts or context increases the chance that they appear in logs, errors, or responses.

The same discipline applies to results. A tool may return more information than the task requires, including internal identifiers, personal data, or sensitive fields. Before passing the result to the model, teams should limit volume, select permitted fields, and apply redaction where appropriate. Data minimization reduces exposure and also improves the model's useful context.

3. Supply chain: models, connectors, plugins, and libraries are part of the risk

A modern agent depends on many components: model provider, SDK, libraries, embeddings, vector databases, SaaS connectors, queues, internal tools, and third-party packages. A weakness in any of these layers can affect the system even when the prompt is well designed. Dependency inventory should include versions, owners, provenance, and update status.

Agent tools are also part of the supply chain. A connector may change its API or expand its response; a library may introduce a vulnerable dependency; a provider may change behavior. Versioning contracts, restricting accepted fields, and testing integrations reduces the risk that an external change silently expands what the agent can do.

4. Data/model poisoning: protect the source before trusting the context

When an agent uses RAG or internal knowledge, response quality depends on the sources it ingests. A manipulated document, incorrect note, or compromised source can introduce persistent information that later appears legitimate because it came from a corporate repository. Ingestion should retain provenance, ownership, and state so a response can be traced back to its source.

Correction should also be possible. If a source is deleted or updated, the index should reflect the change. Teams need controls to reindex, remove content, and prevent one organization's documents from appearing in another. Knowledge traceability is a practical defense because it makes it possible to investigate why the agent believed something.

5. Improper output handling: model output is not a system instruction

A common mistake is taking model-generated text and passing it directly into an interpreter, query, template, or API. Even when the content looks structured, it should be treated as untrusted input. If a tool expects JSON, the system should validate types, lengths, enums, and allowed fields before using it. If output is rendered as HTML, controls appropriate to that surface still apply.

The same principle prevents the model from generating arbitrary queries, shell commands, or code that executes automatically. Instead of exposing an open-ended interface, the agent should call narrow versioned functions. A tool for changing one ticket status is easier to control than a generic tool that can send any request to the backend.

6. Excessive agency: the agent should only have the capability it needs

Excessive agency is particularly relevant to systems that can act. If an agent has write permission when it only needs read access, or if a credential can administer an entire system for a narrowly scoped task, the impact of failure increases unnecessarily. Least privilege means designing tools for the use case rather than reusing all-powerful credentials for convenience.

READ, DRAFT, and EXECUTE make that reduction explicit. A workflow can begin with reading and draft actions under approval. Later, when there is enough evidence, one narrowly defined action may move to EXECUTE. The decision should be per tool and action rather than per agent as a whole. This allows one stable part of a process to be automated without opening everything else.

7. System prompt leakage: do not use the prompt as a vault

A system prompt can contain operational instructions, but it should not store secrets or critical controls that only work while hidden. If a rule is important, it should also exist as server policy. If a key is sensitive, it belongs in a secret manager or credential reference. Designing as though parts of the prompt could become visible reduces dependence on obscurity.

This does not mean publishing internal instructions. It means assuming prompt confidentiality is not a sufficient security boundary. Authorization rules, resource limits, and assigned-tool lists should still protect the system even if the model reveals part of its instructions.

8. Vectors, embeddings, and RAG need organization isolation

Retrieval systems add another boundary: chunks, embeddings, indexes, and filters. A filtering mistake can allow a query to retrieve content from another tenant. Isolation should therefore be enforced before results enter the model context. Organization, user, and sources assigned to the agent are part of the authorized retrieval query.

The system should also bound the number and size of chunks and record which sources were used. When an important answer relies on internal knowledge, the user should be able to trace its provenance. Security and usefulness converge here: an answer with verifiable references is easier to review and easier to investigate when something goes wrong.

9. Misinformation and unbounded consumption: quality and cost are also controls

An agent can answer confidently even when its information is wrong. For consequential tasks, architecture should favor approved sources, references, confidence boundaries, and escalation when data is insufficient. A workflow that lets a person review a draft before sending it controls both operational risk and misinformation.

Unbounded consumption matters as well. Tool loops, huge contexts, infinite retries, or unpaginated queries can increase cost and load on systems. Each tool should define timeouts, result limits, pagination, and rate limits. Model runs need bounded retries and controlled failure states. A secure agent also needs to know when to stop.

10. Agent Control Standard: move governance into runtime

The Agent Control Standard published by OWASP in September 2026 proposes an open foundation for agent visibility and control. Its approach assumes organizations need to know which agents exist, what they can access, which actions they performed, and why. It also describes control points where policy can be enforced during execution.

For a product team, the practical translation is clear: registered tools, versions, schemas, risk classes, roles, credentials, and audit should be system data rather than informal knowledge spread across prompts and documents. When policy changes, the runtime should be able to enforce it without rewriting every prompt. This makes agent governance more maintainable and reduces dependence on probabilistic model behavior.