AI Agent Security Assessment: Testing What Your Agent Can Be Made to Do

An AI agent security assessment tests what an agent can be made to do, not only what it says. It maps every tool, permission and data source the agent can reach, then tries to steer it through the content it reads: documents, emails, web pages, tool output. The report shows what actions an attacker could trigger, what data could leave, and which controls would stop it.

Why an agent needs a different assessment than a chatbot

A chatbot that answers questions has one main failure: it says something it should not. The worst case is usually an embarrassing or leaked answer on a screen.

An agent is different because it acts. It calls APIs, queries databases, sends email, files tickets, writes code and moves money if you let it. When an agent is fooled, the damage is whatever its tools allow. That changes the question an assessment has to answer. It is no longer "can we make the model misbehave?" but "if the model misbehaves, what happens next?"

The OWASP Top 10 for LLM Applications 2025 names this directly as LLM06:2025 Excessive Agency. OWASP lists three root causes: excessive functionality (tools the agent does not need), excessive permissions (tools with more access than the task requires) and excessive autonomy (high-impact actions with no independent check). In December 2025 the OWASP GenAI Security Project followed with a separate Top 10 for Agentic Applications, which opens with agent goal hijack: an attacker redirecting what the agent is trying to achieve through content it processes.

If you have already read our walk through the OWASP Top 10 for LLM applications, an agent assessment is where those risks stop being theoretical.

What are the main agentic AI risks?

Most findings in agent work fall into a short list. They are worth knowing before you scope anything.

• Prompt injection through tools. The agent reads a support ticket, a PDF, a calendar invite or a web page that contains instructions. It treats those instructions as if they came from the user. This is indirect prompt injection, and in agents it is the most common route to a real incident.
• Excessive agency. A summarising agent that only needs to read a mailbox is given a token that can also send and delete. A coding agent gets shell access on a machine with production credentials.
• Confused deputy. The agent runs with its own service account rather than the permissions of the user it is acting for, so a low-privilege user can ask it to fetch data they could never see directly.
• Data exfiltration paths. Any tool that can reach the outside world (a URL fetch, an image render, an outbound email, a webhook) is a way to carry data out once the agent has been steered.
• Improper output handling. Agent output is passed into a database query, a shell command or a browser without validation. OWASP lists this as LLM05:2025.
• Unbounded consumption. A loop or a hostile input makes the agent call tools or the model thousands of times, running up cost or exhausting a rate limit. OWASP lists this as LLM10:2025.

What an AI agent security assessment covers

A useful assessment is part architecture review and part hands-on testing. Doing only one half misses findings.

1. Inventory the agent's reach

We start by listing every tool the agent can call, every credential behind those tools, and every data source that ends up in its context window. For agents built on the Model Context Protocol (MCP) or a similar tool framework, that means every connected server and every function each one exposes. Teams are regularly surprised by this list. Tools get added during prototyping and never removed.

2. Trace trust boundaries

For each input, we ask who controls it. The system prompt is yours. The user's message is the user's. A retrieved document, a customer email or a scraped web page belongs to whoever wrote it, which may be an attacker. Any place where untrusted content reaches the model in the same context as a powerful tool is a candidate finding.

3. Test the agent with hostile content

This is where AI agent security testing happens. We plant instructions in the places the agent reads and try to make it call tools it should not, reach data outside its scope, or send data somewhere it should not go. We test multi-step chains too, since an agent that refuses a direct request will often complete the same action when it is split across three innocent-looking steps.

4. Review the controls outside the model

Model behaviour is probabilistic, so the controls that matter most sit outside it: permission scoping, human approval steps, output validation, egress restrictions, logging and rate limits. We check whether each exists and whether it actually holds under testing.

How do you stop an agent reaching data outside its scope?

You cannot reliably instruct a model to stay in its lane. You have to build the lane. These are the controls we look for, in rough order of value.

Control	What it prevents	Common gap
Act with the user's permissions, not a shared service account	Confused deputy access to other users' data	One powerful API key shared by every session
Narrow, purpose-built tools	An injected instruction turning a general tool into an attack	Generic "run query" or "fetch URL" functions
Read-only by default	Destructive or irreversible actions	Write scopes granted because they were easier to set up
Human approval for high-impact actions	Payments, deletions, external sends without review	Approval shown but trivially bypassed by a second tool
Egress allow-lists	Data leaving through URL fetches, images or webhooks	Agent can reach any domain on the internet
Tenant filtering at the data layer	Retrieval across customer boundaries	Filtering done in the prompt rather than the query
Logging of every tool call with inputs	Undetected misuse; no answer for an incident review	Only the final answer is logged

OWASP's own guidance for excessive agency says much the same: minimise extensions, limit what each one can do, avoid open-ended tools, enforce permissions through the identity the tool uses, and require user approval for high-impact actions. If your agent retrieves documents, our guide to securing RAG pipelines covers the retrieval side in more detail.

MCP and tool permission scoping

MCP has made it much easier to connect an agent to many systems at once. That is the appeal and the risk. Each MCP server is a bundle of capabilities, and connecting one usually grants everything it exposes.

When we assess an MCP-based agent, we look at three things. First, which servers are connected, who wrote them and whether you pinned a version or pull the latest. A third-party MCP server is a dependency like any other, with the same supply chain risk. Second, which credentials each server holds and whether those credentials are scoped to the task. Third, whether tool descriptions and tool output are treated as trusted. A tool's own description or response can carry injected instructions, so it belongs on the untrusted side of the boundary.

What the report should contain

An assessment is only as useful as what you can do with the report. A good one contains:

• A plain-language summary a non-technical buyer or board member can read.
• A map of the agent's tools, permissions and data sources, marking which ones were in scope.
• Each finding with a severity, the exact steps or payload that reproduced it, the impact in business terms, and a specific fix.
• Findings mapped to the OWASP categories, which is the language enterprise security reviewers now use.
• Controls that held up under testing, not only the ones that failed. Buyers want to see both.
• A retest section once fixes are in, so the report shows closure rather than just a list of problems.

That last point matters for sales. A report that ends with every finding marked fixed and retested is something you can share with an enterprise buyer's security team. Our post on the security risks of shipping LLM features covers what those reviewers tend to ask.

AI agent security assessment vs LLM red teaming

The two get mixed up. An assessment is scoped around your system: here is the agent, here are its tools, find what is wrong and tell us how to fix it. It is the right first purchase for most teams shipping an agent.

LLM red teaming is objective-based. The team is given a goal, such as extracting another tenant's records or getting the agent to move funds, and works toward it however it can, over a longer period. It suits mature products where the obvious issues are already closed and you want to know what a determined attacker could achieve.

A traditional penetration test of the surrounding application is a third, separate thing. It still matters, because the agent's API, authentication and storage are ordinary web attack surface. Many teams run both in the same cycle.

What drives the cost of an AI agent security assessment

Scope drives price far more than the AI label. The main factors are:

• Number of tools and integrations. Each one is a path to test.
• Number of distinct agents or workflows. A single support agent is smaller than a set of agents that hand work to each other.
• Write access. Agents that can change data, send messages or spend money take longer to test safely, and usually need a staging environment.
• Multi-tenancy. Testing cross-customer isolation adds work.
• Retest. Whether a retest after fixes is included.

Our AI security assessments start from $4,000 and are scoped to what you actually built. If you want to try some of the testing yourself first, the prompt injection test pack is free.

Common questions about AI agent security assessments

What is an AI agent security assessment?

It is a structured review and hands-on test of an AI agent's tools, permissions and data access. The goal is to find what an attacker could make the agent do, usually by planting instructions in content it reads, and to recommend controls that limit the damage. It covers the model's behaviour and, more importantly, the systems the agent can reach.

How is AI agent security testing different from a penetration test?

A penetration test looks for flaws in code, configuration and authentication. AI agent security testing looks for ways to steer the agent through language: instructions hidden in documents, tool output or user input that make it misuse legitimate tools. Most agents need both, because the agent's API and storage are still ordinary web attack surface.

Can prompt injection be fixed completely?

Not today. No model reliably separates instructions from data in everything it reads. The practical answer is to assume injection will sometimes succeed and limit what a hijacked agent can do: narrow tools, the user's own permissions, approval for high-impact actions, egress allow-lists and full logging of tool calls.

When should we get an AI agent assessed?

Before the agent gets write access to production data or customer-facing channels, and again when you add significant tools or integrations. Many teams also commission one when an enterprise buyer's security review asks how the agent is protected, since a report with retested findings answers that question directly.

Does an AI agent security assessment help with SOC 2 or ISO 42001?

It produces evidence both can use. SOC 2 auditors look for risk assessment and testing of systems in scope, and an agent assessment shows both. ISO 42001 expects AI risks to be identified and treated, and the findings register and retest feed that directly. It does not replace either framework.