OWASP Top 10 for LLM: Enterprise Controls for Agents and Tools

Why the OWASP Top 10 for LLM matters in enterprise agents

OWASP maintains a Top 10 for Large Language Model Applications to help builders and defenders prioritize the most critical risks in LLM-based systems. For enterprises deploying agents that plan, use tools, retain memory, and chain multi-step actions, those risks are not abstract model flaws. They become control gaps at the boundary between untrusted content, model reasoning, and privileged infrastructure.

Security engineers should treat the list as a risk register and control map, not a checklist of prompt templates. Prompt injection can override system intent and steer tool selection. Insecure output handling turns model text into executable SQL, shell, URLs, or structured tool parameters. Sensitive information disclosure exposes PII, secrets, proprietary data, or system prompts through answers, logs, or retrieval-augmented flows. Excessive agency amplifies any of the above when the agent can invoke high-impact tools with broad standing credentials.

Recent OWASP iterations refine naming and scope, including stronger emphasis on system prompt leakage, vector and embedding weaknesses, misinformation, supply chain components, and unbounded consumption. Enterprises should pin control mapping to a specific OWASP version, then align prioritization to their own agent architectures: tool catalogs, RAG corpora, memory stores, and autonomy levels. Broader frameworks such as the NIST AI RMF (govern, map, measure, manage) reinforce the same operational pattern: define boundaries, instrument behavior, and continuously manage misuse, leakage, and unsafe autonomy.

How Top 10 risks manifest in tool-using architectures

In agentic systems, risk concentrates where planning, retrieval, and execution meet. Indirect prompt injection often enters through retrieved documents, ticket bodies, email, wiki pages, or memory writes. Once inside context, injected instructions can reshape multi-step plans, tool choice, and argument construction without an obvious malicious user prompt. Memory stores can persist malicious instructions across sessions if write paths are not filtered and segmented.

Improper output handling becomes critical when downstream components trust model text. Passing free-form output into browsers, shells, query engines, or tool brokers without schema validation, allowlists, and encoding creates classic injection paths in a new wrapper. Sensitive disclosure paths include over-collected RAG indexes, debug traces that capture system prompts or tool schemas, and models repeating secrets present in context. Excessive agency scales with autonomous loops, large tool catalogs, and credentials that outlive a single task.

Identity design determines whether least privilege is enforceable. End-user identity, agent service identity, and per-tool credentials must remain distinct so authorization and attribution do not collapse into a single shared principal. Supply chain exposure spans third-party models, plugins, training or fine-tune data, embedding pipelines, and dependencies that can introduce poisoned artifacts or vulnerable components. Unbounded consumption appears as uncontrolled tool loops, recursive planning, or unthrottled model calls that create cost overrun and denial of service.

Map each risk category to concrete enterprise controls

A practical mapping keeps controls outside the prompt wherever side effects are possible. Input and tool mediation address prompt injection by separating untrusted content from control instructions, filtering retrieved text before it enters context, and refusing tool calls that would exfiltrate data or escalate privilege based on injected directives. Output encoding and strict schema validation address insecure output handling at the mediation layer, not only inside model instructions.

Sensitive information disclosure requires corpus segmentation by sensitivity, redaction before context assembly, secret scanning on outputs and logs, and tight access to system prompts and tool schemas. Excessive agency is reduced by least-privilege tool design: narrow APIs, time-bound credentials, environment isolation for high-impact tools, default deny on powerful actions, and human-in-the-loop approval for irreversible operations. Supply chain controls need inventory of models, plugins, retrieval sources, and dependencies, plus change control when any of those change. Unbounded consumption needs rate limits, cost budgets, recursion caps, and kill switches on agent loops.

Runtime policy checkpoints should be explicit: authenticate the caller; authorize the tool and action for that identity, tenant, and data classification; validate arguments against schemas and allowlists; block or transform disallowed content; require approval when risk exceeds policy; then execute and record. Evaluate gateways and agent runtimes on whether they can deny or modify tool calls, not merely log them after the fact.

Runtime governance patterns that hold up in production

Strong patterns share one trait: enforcement sits in the execution path. Tool brokers should evaluate policy on every call. Content from retrieval and memory should be treated as untrusted input capable of indirect injection. System prompts and tool schemas should be protected as sensitive configuration. Model version, prompt, tool catalog, and retrieval source changes should follow change control because they alter the attack surface.

Prompt-only defenses remain limited and context-dependent. They can support defense in depth but should not be the primary control against coercion of tool use, exfiltration, or privilege escalation. Prefer architecture that can fail closed: if validation, authorization, or budget checks cannot be completed, do not execute the side effect.

Operationally, align LLM runtime controls with enterprise AI risk management. Define owners for tool catalogs and retrieval sources. Set review policies for interaction logs. Monitor for anomalous tool sequences, repeated policy denials, and cost spikes that may indicate looping or abuse. When evaluating platforms, ask which OWASP categories are mitigated at runtime versus only guided in documentation, and how indirect injection, excessive agency, and sensitive disclosure are tested continuously.

Evaluation questions and practical next steps

Security engineers can pressure-test readiness with a short set of buyer and architecture questions:

• Which OWASP LLM Top 10 categories are enforced at runtime rather than addressed only through prompt guidance?
• Can tool calls be authorized per user, tenant, action, and data classification with least-privilege credentials?
• Does the system mediate and validate tool arguments and model outputs before side effects occur?
• What audit evidence exists for prompts, retrieval, tool invocations, and agent decisions?
• How are indirect prompt injection, excessive agency, and sensitive disclosure tested in CI and watched in production?

Next steps are deliberate and local to your environment. Pin the OWASP version you will track. Inventory agents, tools, identities, memory stores, and retrieval corpora. Mark high-impact actions that require human approval. Place a mediation layer in front of tool execution if one does not exist. Define deny rules for exfiltration-prone argument patterns and unsafe output destinations. Establish rate and cost controls. Then run adversarial scenarios that place instructions in documents and memory, not only in the user chat box.

Trussed AI focuses on runtime governance and security for enterprise AI agents, including policy enforcement, agent identity and permissions, tool governance, approval workflows, monitoring, and audit logging. Regardless of platform choice, the standard of care is the same: map OWASP Top 10 for LLM risks to enforceable controls, prove those controls on the execution path, and keep agency within permissions you can explain and audit.