AI agent security review: what your agent can reach, and what it can change.
Your agent calls tools with real credentials. We map every one and prove where the approval gate sits.
A Sorami agent security review traces every tool your agent can call to the credential behind it, then proves which service enforces the approval gate. You receive a register of agents, identities and reachable data, the artefact the September 2026 ISM requires and the one most teams cannot produce.
You gave an agent write access and someone has to sign it off.
A team points an MCP server at a repository, a database or a payments API. Or a customer asks in writing what the agent may do.
A protocol is not a security boundary.
The Model Context Protocol specification 2026-07-28 moves tool definitions between a client and a server. Authorisation, credentials and approval gates live in your application and in the services those tools reach. A tool description is a suggestion to the model. Only the downstream service can refuse.
Every tool, traced to the credential behind it.
- Every tool, resource and prompt the agent can call, and its real scope.
- Where memory, hooks and config files enter the context.
- The worst single call, and the worst chain of three calls.
- Whether the audit log can reconstruct a tool call afterwards.
Each one runs through to the service that should refuse.
- Prompt injection through to a side effect Pass: the downstream service refuses the call.
- Cross-tenant resource swap Pass: the request is rejected above the model.
- Confused deputy from a low-privilege caller Pass: scope is checked per call, not per session.
- Manifest drift with an added or changed tool Pass: the schema hash check fails closed.
- Secrets in a failure path Pass: the error returns nothing sensitive.
Two documents and the register the September 2026 ISM requires.
- Agent Blast Radius Map: worst single call and worst chain.
- Tool Permission Ledger: the scope held against the scope needed.
- Findings register with reproduction steps, a named owner and a retest.
One page of a Tool Permission Ledger
The ledger sets the scope a tool holds beside the scope the task needs. The gap is the finding.
| Tool | Scope the credential holds | Scope the task needs |
|---|---|---|
| create_ticket | Project admin across every project | Create an issue in one project |
| run_query | Read and write on all tables | Read on three reporting views |
| read_repo | Contents read across the organisation | Contents read on two repositories |
Blast radius, worst chain of three calls. Retrieved ticket text tells the agent to run a query. The role has no row filter, so it returns another tenant's records. The agent posts them where the requester can read them.
Illustrative example. A synthetic agent with synthetic scopes, built to show the format. Not a client artefact, and not a finding from any real system.
Priced by tool count, not by agent count.
| Scope | Typical testing days | Reporting and retest |
|---|---|---|
| One agent, up to five tools | Five days | Report within five business days |
| Multiple agents, up to twenty tools | Eight days | Report within five business days |
| Multi-tenant platform with agent-to-agent calls | Quoted after the tool inventory | Agreed in writing first |
No fee is published; the tool inventory changes the answer. Scope and fee are confirmed in writing before any access, as with penetration testing.
The agent layer has its own patch status.
Reviewing the agent means reviewing the servers it talks to, so the version in use is recorded rather than assumed.
- CVE-2025-49596 MCP Inspector below 0.14.1 had no authentication between client and proxy. Rated 9.4.
- CVE-2025-6514 mcp-remote 0.0.5 to 0.1.15 allowed command injection from a malicious server. Fixed in 0.1.16.
- CVE-2025-53110 The reference filesystem server allowed path escape through a colliding prefix. Fixed in 0.6.4.
Framework and advisory versions above were read from the primary source on 17 September 2026.
What the map exposes.
- The approval gate is in the prompt, so injection removes it.
- The agent runs as one service account holding everything.
- Nothing logs the arguments, so an incident cannot be reconstructed.
What this review excludes
- Not a guardrail product. We install no proxy.
- Not monitoring. The ledger is dated.
- Not a penetration test unless separately scoped.
- Not an audit opinion. Sorami is not a certification body.
Practical answers.
Is this the same as an AI penetration test?
No. A penetration test attacks the feature. This review maps the permission surface behind it and proves which service enforces the approval.
We use MCP servers we did not write. Can you review those?
Yes, and that is usually where the finding is. A third-party server carries its own patch status, so we record the version and check advisories.
Do you need production access?
No. Read-only cloud access, the tool manifests and an environment matching production is enough. Testing in production needs written authorisation and a rollback plan first.
Which lists does this map to?
Findings carry a category from the OWASP Top 10 for Agentic Applications 2026 and the OWASP Top 10 for LLM Applications 2026. Technique references use MITRE ATLAS.
Do you re-run this when we add a tool?
That is the common case, because the tool list is what changes. A re-run is quoted against the delta, and every ledger is dated.
Different trigger, different starting point. AI buyer due diligence pack and AI coding agent control baseline answer the other two questions, and all AI security services routes on the event. For adversarial testing of the feature itself, AI application security testing.
Scope an agent security review.
Send the tool list and what the agent can write to.
Last reviewed: