Guide · Agent posture

The OWASP Top 10 for Agentic AI

The OWASP Top 10 for LLM Applications describes risks to a model. Agents change the stakes, because the same weakness now has hands: a harness, tools, MCP servers, skills, memory, and credentials on a real machine. This guide takes each risk in the list and says what it looks like once an agent can act, and what to check.

Published by Optimus Labs. The risk names and identifiers below follow the OWASP Top 10 for LLM Applications; the agent-layer reading and the checks are ours.

From securing the model to securing the agent

Model-level controls assume the worst outcome is a bad answer. On the endpoint, the worst outcome is a bad action taken with a real token. Three properties decide how bad: what untrusted input the agent reads, what sensitive data it can reach, and what external action it can take. When one agent holds all three, you have the Lethal Trifecta, and every risk below gets materially worse.

The ten risks, read at the agent layer

LLM01

Prompt injection

At the model: Untrusted text steers the model away from the instructions its operator gave it.
At the agent: The agent can act on that text. An injected instruction inside an issue title, a web page, a code comment, or a tool response becomes a command with the agent's credentials behind it.

What to check

List every source an agent reads without a human in between: repositories, issue trackers, inboxes, web fetches, tool output.
Confirm no single agent combines untrusted input, sensitive data, and external action. That combination is the Lethal Trifecta.
Require confirmation on irreversible actions rather than trusting the agent to refuse.

Read: one untrusted string, three trust boundaries

LLM02

Sensitive information disclosure

At the model: The model repeats secrets or personal data in its output.
At the agent: The agent can move that data. It holds tokens, reads local files, and calls outbound tools, so disclosure is an egress event and not just a bad answer.

What to check

Inventory the credentials each agent and MCP server can reach, including environment variables and credential helpers.
Restrict outbound destinations for agents that touch regulated data.
Prefer short-lived credentials over long-lived tokens stored in agent configuration.

LLM03

Supply chain

At the model: Models, adapters, and libraries arrive from third parties.
At the agent: The supply chain now includes MCP servers, skills, extensions, and hooks that employees install themselves, often outside any review process.

What to check

Discover installed agents, MCP servers, and skills on the endpoint rather than relying on an approved-tools list.
Record who installed each one, from which registry, and at which version.
Alert on new install sources instead of only on known-bad packages.

Read: agents flooded RubyGems to reach a docs builder

LLM04

Data and model poisoning

At the model: Training or fine-tuning data is tampered with.
At the agent: Persistent agent memory, project instruction files, and cached tool descriptions are all writable state. Poison them once and the agent misbehaves on every later run, with no prompt to point at.

What to check

Treat agent instruction files and memory stores as code: review changes and keep history.
Detect edits to agent configuration that no human made.
Re-read tool and MCP descriptions on change, since a renamed or rewritten tool changes agent behavior.

LLM05

Improper output handling

At the model: Downstream systems trust model output without validating it.
At the agent: Output is executed. Shell commands, SQL, file writes, and API calls run with the agent's privileges, so an unvalidated string is remote code execution.

What to check

Find every place agent output reaches a shell, a database, or a build step.
Pass values through parameters and environment variables instead of string interpolation.
Log the command that ran, not only the intent the agent stated.

LLM06

Excessive agency

At the model: The system grants the model more capability than the task needs.
At the agent: This is the central agent-layer risk. Permission comes from the harness: allow-lists, auto-approve settings, tool scopes, and the credentials sitting on the machine. Defaults are usually broader than anyone intended.

What to check

Audit auto-approve and skip-confirmation settings across agent harnesses.
Scope tool permissions per project rather than per user.
Score each agent against the actions it can take, not the actions it usually takes.

Read: when safe defaults still grant access

LLM07

System prompt leakage

At the model: The system prompt is exposed to a user.
At the agent: The harness prompt describes available tools, internal paths, and approval rules. Leaking it hands an attacker a map of what the agent can do and which guardrail to talk around.

What to check

Never place secrets or authorization decisions in prompt text.
Enforce permissions in the harness, where the agent cannot argue with them.
Assume prompt content is discoverable and design controls that survive that.

LLM08

Vector and embedding weaknesses

At the model: Retrieval stores leak or return manipulated content.
At the agent: Retrieval feeds an actor. Content planted in an indexed document reaches the agent as trusted context and can carry instructions along with facts.

What to check

Track which collections each agent can query and who can write to them.
Separate indexes by sensitivity instead of sharing one store across teams.
Treat retrieved text as untrusted input for the purposes of the check above.

LLM09

Misinformation

At the model: The model states something false with confidence.
At the agent: A wrong conclusion becomes a wrong change: a deleted branch, a bad migration, a message sent to a customer. The cost is operational, not conversational.

What to check

Keep a record of what each agent changed and where, so a wrong action can be traced and undone.
Gate destructive operations behind review regardless of stated confidence.

LLM10

Unbounded consumption

At the model: Cost and capacity run away through excessive requests.
At the agent: Agents loop. A retry cycle can exhaust API quota, hammer an internal service, or run up spend overnight with nobody watching a terminal.

What to check

Alert on agent activity volume per user and per tool, not only on total spend.
Cap run duration and tool-call depth in the harness.

Where to start

Inventory first. You cannot score a posture you cannot see. Find every agent, MCP server, and skill installed across your endpoints, including the ones nobody filed a ticket for.
Score the harness, not the prompt. Permission lives in configuration: auto-approve settings, tool scopes, credential files.
Watch runtime. Static posture tells you what an agent could do. Behavior tells you what it did, and which run deserves a question.

For worked examples of these risks in real incidents, read the Civilizations threat briefings, or see how the platform applies this to security teams.

See your own agent posture

Optimus discovers every agent, MCP server, and skill on your endpoints and scores each one against these risks.

Book a demo

Backed by

Arka

Scout