This page is for application security engineers, red teams, and the architects who own AI agents that call tools, read untrusted content, and act on behalf of users. It maps the controls Praesidia provides to each entry in the OWASP Top 10 for LLM Applications 2025, and it lists the evidence you can export for each.
The OWASP LLM Top 10 is an awareness list, not a standard. The 2025 revision reordered and renamed several entries to reflect how LLM applications are actually deployed: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation, and LLM10 Unbounded Consumption. Each entry describes a risk class and lists mitigations; the list does not tell you how much of each you need.
Agents raise the stakes on almost every entry because an agent turns model output into action. A prompt injection against a chatbot produces a bad answer; against an agent with a ticketing tool and a payments API it produces a bad transaction. That is why the controls below concentrate on what an agent is allowed to do, not only on what it is allowed to say. The OWASP LLM Top 10 applied to agents post works through each entry; the OWASP Agentic AI Top 10 guide covers the companion list for multi-agent systems.
Control mapping
| Requirement / criterion | What Praesidia provides | Evidence you can produce |
|---|---|---|
| LLM01 — Prompt Injection (direct and indirect) | Input guardrails that detect and block injection patterns in requests and, in a chat turn on Praesidia, in each MCP tool result before the model reads it (guardrails do not apply to a tool an organization owner calls directly through the Praesidia API); intent rules that stop a technically valid task between agents aimed at the wrong data; declared connections and per-tool authorization that bound what a hijacked agent can reach. | Blocked-injection records for the period; intent-rule verdicts; tool-authorization configuration. |
| LLM02 — Sensitive Information Disclosure | Outbound guardrails with PII detection and redaction on an agent's tool-call arguments and its reply in a chat turn on Praesidia, and on a task's result before it is returned; vaulted provider keys and credentials that are shown once and never read back in plaintext; tenant isolation. | Redaction decision records; audit records of credential issuance, rotation, and revocation; tenant-scoping configuration. |
| LLM03 — Supply Chain (models, plugins, MCP servers, third-party components) | Customer control; Praesidia contributes governed MCP-server connections with per-tool authorization, non-human identity for every server and agent, and bring-your-own-key model-provider access so provider choice stays with you. | MCP-server inventory; per-tool rules; provider configuration. See tool poisoning in MCP. |
| LLM04 — Data and Model Poisoning | Customer control (training and fine-tuning pipelines sit outside the platform); Praesidia contributes guardrails on what agents may write to data stores, and write-capable tool calls that pass through Praesidia are recorded against the calling agent. | Write-tool authorization rules; audit records of writes by agent and time. |
| LLM05 — Improper Output Handling | Outbound guardrails that block or redact model output before downstream systems consume it; policies that restrict which tools an agent may invoke with that output. | Outbound block and redact records; tool-restriction rules. |
| LLM06 — Excessive Agency | Least-privilege connections (no implicit trust between entities), per-tool authorization that separates read from write and delete, human approval gates before consequential actions, and single-agent revocation that contains blast radius. | Connection map per agent; approval decisions with approver and time; revocation events. See excessive agency controls. |
| LLM07 — System Prompt Leakage | Customer control (do not place secrets or authorization logic in prompts); Praesidia contributes credentials held outside the prompt under vaulted non-human identity, and outbound rules that can block known sensitive strings. | Credential configuration showing no secrets in agent configuration; outbound block rules. |
| LLM08 — Vector and Embedding Weaknesses | Customer control (retrieval stores live in your stack); Praesidia contributes per-connection authorization to the retrieval tools an agent may call and, in a chat turn on Praesidia, input guardrails that can redact PII from a tool's result before the model reads it; guardrails do not apply to a tool an organization owner calls directly through the Praesidia API. | Retrieval-tool authorization; guardrail log entries for redacted tool results in chat turns. |
| LLM09 — Misinformation | Customer control; Praesidia contributes human approval gates so a person reviews consequential agent output before it takes effect, and LLM-based guardrail evaluation for topical and policy restrictions where the risk justifies its cost. | Approval records; LLM-evaluation guardrail configuration and verdicts. |
| LLM10 — Unbounded Consumption | Budget policies, on the Team and Enterprise plans, that can pause or block new agent tasks once spend reaches a threshold you set, and refuse a model call through the gateway that would exceed an agent's or the organization's budget; on a connection between two agents, per-minute and per-hour task rate limits and a monthly spend cap; on an agent's connection to an MCP server, per-hour caps on a tool's calls, with no spend cap checked on a tool call; spend attribution and anomaly alerting; the AI FinOps guide covers setting budgets for agents. | Budget and rate-limit configuration; triggered-cap events; spend attribution reports. |
| Cross-cutting — Identity and attribution | A distinct non-human identity per agent, MCP server, and application, with just-in-time ephemeral credentials by default, rotation, and revocation; a chain view that traces an agent-to-agent chain hop by hop (Enterprise). | Credential lifecycle events; chain views of agent-to-agent chains (Enterprise). |
| Cross-cutting — Detection and forensics | An append-only, hash-chained audit trail of the decisions Praesidia makes, signed under the default configuration (an operator can turn signing off); an offline verifier, alerting, and SIEM forwarding (Advanced tier and Enterprise). Alerting, too, is on the Advanced tier and Enterprise. A signed record shows it was not changed afterwards, not that every action was captured; calls that do not pass through Praesidia are not recorded. | Signed bundle export plus verifier result; forwarded events; alert history. |
What this mapping is not
The OWASP LLM Top 10 has no certification scheme and is not a legal requirement, so this mapping supports your assessment and does not constitute certification or an assurance that your deployment is secure. It shows which controls Praesidia contributes against each risk class and what evidence you can pull for a reviewer. Whether the controls are configured tightly enough for your threat model is a judgment your security team makes, ideally with an adversarial test rather than a document review.
Several entries are substantially outside a governance control plane. LLM04 lives in your training and fine-tuning pipeline. LLM08 lives in your retrieval store and embedding pipeline. LLM07 is a design discipline about what you put in prompts. LLM09 is a product question about when a human must check the machine. Praesidia narrows the consequences of each, by limiting what an agent can reach and recording what passes through it, without removing the underlying work.
Two scoping statements belong in any security review. Praesidia inspects only the traffic that passes through it, and calls that do not pass through Praesidia are not recorded. And Praesidia records the decisions it makes in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. A signed record shows it was not changed afterwards. It does not show that every action was captured. Both limits are stated at /security/verify-your-audit-trail.
Getting started
- Register every agent and MCP server at /start, following the getting-started guide, and declare connections so no entity trusts another implicitly. Most LLM06 exposure disappears at this step.
- Attach controls per connection: on an agent's connection to an MCP server, per-tool permissions that deny write tools while read tools stay allowed, and per-hour caps on a tool's calls; on a connection between two agents, a monthly spend cap and rate limits. Inbound injection rules and outbound PII redaction are guardrails set organization-wide or on an agent: they check the tasks sent between agents and their results, and the tool calls an agent makes during a chat turn. Intent rules are not attached per connection: they apply across the organization, to the tasks sent between two agents. The guardrails and policies docs show each option; the MCP server governance guide covers the server side.
- Run an injection test through a governed connection using the patterns in how to detect prompt injection, and confirm the block appears in the trail with the originating agent attributed.
- Export the test window and verify it offline per /security/verify-your-audit-trail; from agent action to audit evidence shows the path. Hand the bundle and the verifier output to your penetration tester with the configuration.
Common questions
No. It is an awareness document from the OWASP GenAI Security Project ranking the ten most significant risk classes for LLM applications, revised for 2025. Nobody certifies against it, but security reviewers, customers, and penetration testers use it as a checklist, so being able to say what you do for each entry is a practical requirement. This mapping supports your assessment and does not constitute certification.
LLM01 prompt injection, because agents read untrusted tool output and web content; LLM06 excessive agency, because agents hold real permissions; LLM03 supply chain, because MCP servers and plugins are third-party code; and LLM10 unbounded consumption, because an agent in a loop spends money and calls tools without a human watching.
No control alone does, which is why OWASP lists it first. Inbound guardrails detect and block known injection patterns; the durable defence is limiting what a compromised agent can do, through per-tool authorization, declared connections, intent rules, approval gates, and budget caps, and being able to see and prove what happened afterwards. Praesidia provides each of those layers; you decide how tightly to set them.
The Agentic Security Initiative publishes a separate Top 10 for agentic systems covering risks such as goal manipulation, privilege compromise, and cascading failures across agents. The two lists overlap heavily on controls. This page maps the LLM list; the agentic list is covered in the OWASP Agentic AI Top 10 guide linked below.
Scoped access to a test organization with representative connections, the guardrail and policy configuration, and an export of the audit trail for the test window. Signing is on in the default configuration, so they can verify that export offline, which tells them the record they are reading was not altered after the fact.