How is this different from prompt injection testing?

Injection is the entry technique; this engagement is about what the agent can do once it has been steered. We spend most of the time on tools, identity, memory, and approval boundaries — the parts that decide whether a hijacked agent reads one document or empties a bucket. If your system is a chat interface over retrieval with no write actions, AI penetration testing is the better fit and we'll say so during scoping.

Can you guarantee our agents can't be hijacked?

No, and we won't imply otherwise. There is no complete defence against instructions arriving inside content an LLM has to read, so treating input filtering as the control is how teams get surprised. We design for the assumption that hijack succeeds: the agent's identity is narrow, its irreversible actions pass a human, and its behaviour is logged well enough to catch and reconstruct. That is a containment argument, not a guarantee.

Which platforms and frameworks do you cover?

The agent layer is largely framework-agnostic — orchestration graphs, agent SDKs, and managed agent runtimes share the same trust-boundary problems. The cloud identity and blast-radius work is AWS and Google Cloud; we don't claim Azure. We also don't evaluate foundation model weights, alignment, or safety behaviour, and we are not a certification body: we can map findings to NIST AI RMF functions or ISO/IEC 42001 control language for your auditors, but the certificate comes from someone else.

Do you test against our production agents?

Usually not directly. Unlike a web target, agent tool calls have real side effects — tickets get created, money moves, infrastructure changes. We prefer an environment wired to the same tools and MCP servers with non-production backends, plus read-only review of the production identity and logging configuration. Where production testing is the only meaningful option, we agree the destructive-action boundary in writing first and work inside it.

AI agent and MCP security

We test what your agents can actually do when the input lies — goal hijack through poisoned context, tool and MCP abuse, and the credential blast radius sitting behind every tool call.

Book a scoping callHow we work

When you need this

Your agent shipped with read-only tools. Write access was added one ticket at a time, and nobody re-drew the trust boundary when the first tool that changes production state landed.
Engineers are installing MCP servers from GitHub into tools that hold production credentials, and there is no review step between a repo and your environment.
An agent did something surprising in production, and the audit log shows the API call but nothing about why the agent decided to make it.
Your human-approval step has become a button people click through — the agent asks dozens of times a day, and the prompt shows a summary the agent wrote rather than the parameters it is about to send.

What we do

Threat model the decision loop, not the prompt box

We map every place untrusted content reaches a planning or tool-selection decision: retrieved documents, tool outputs fed back as observations, persisted memory, and messages from other agents. That surface is where ASI01 agent goal hijack and ASI06 memory and context poisoning actually live, and it rarely matches the architecture diagram. Findings are mapped to the OWASP Top 10 for Agentic Applications (ASI01–ASI10) and MITRE ATLAS techniques so your team can place them against work already in flight.

The MCP tool surface, server by server

Tool names, descriptions, and JSON schemas are model-visible text, which makes every third-party MCP server attacker-controlled input the moment it is installed. We test for tool poisoning through instruction text hidden in description and parameter fields, rug pulls where a server mutates a tool definition after approval, and cross-server shadowing where one server's description changes how the agent uses another's tool. Detections here are mechanical before they are clever: hash every tool definition at approval time and re-check it on each connection, the way mcp-scan's tool pinning does, so a definition that mutates under you is caught rather than trusted. Server provenance, version pinning, and update review then get the same treatment as any other dependency, because ASI04 agentic supply chain vulnerabilities are a supply chain problem first.

Gateway architecture, agent identity, and blast radius

We review the MCP gateway or proxy for the failure modes that matter at that layer: token passthrough to downstream APIs, access tokens issued without audience binding (RFC 8707 resource indicators), shared static client registrations that turn the gateway into a confused deputy, and session identifiers treated as authentication. Then we work the ASI03 identity and privilege abuse side — one non-human identity per tool rather than one agent role that can do everything, short-lived credentials, scoped-down session policies on AWS, and service account impersonation constrained by IAM Conditions on Google Cloud. We also place the human-approval boundary deliberately, because ASI09 human-agent trust exploitation is mostly a design failure: which actions are reversible, which need a person, and whether the approval prompt shows the real parameters or a summary the agent wrote itself.

Multi-agent trust and the evidence trail

In delegation chains, ASI07 insecure inter-agent communication shows up as messages and task results that carry instructions across a trust boundary nobody defined — including over A2A-style agent-to-agent exchanges where a remote agent card is taken at face value. We test whether a subordinate agent can steer its caller, then check whether you could reconstruct the event afterwards: prompt and tool-call spans under OpenTelemetry GenAI conventions, correlated to CloudTrail or Cloud Audit Logs, so "why did the agent do that" has an answer with evidence. The same telemetry surfaces ASI10 rogue agents — orphaned deployments still holding live credentials, and agents calling tools outside the sanctioned gateway.

What you receive

An agent architecture and trust-boundary map marking every point where untrusted content reaches a planning or tool-call decision
Findings mapped to the OWASP Top 10 for Agentic Applications (ASI01–ASI10) and MITRE ATLAS, each with the transcript: the input, the tool calls it produced, and the resulting API activity
An MCP server inventory with a per-server verdict — keep, gate behind the proxy, or remove — plus pinning and update-review guidance
A per-tool least-privilege identity model written as IAM policy or Terraform for AWS or Google Cloud, not as a table of recommendations
An approval-boundary design covering which actions require a human, plus rate, spend, and scope caps for the ones that don't
An agent logging and forensics specification: the spans and fields needed to reconstruct a decision, and detections for rogue or orphaned agents

How it runs

Scope & threat model
days
Agents, tools, MCP servers, and the credentials behind them inventoried and priced, then the decision loop, trust boundaries, and per-tool blast radius mapped before any testing starts.
Test
1–3 weeks
Hostile inputs through every entry surface, tool and MCP abuse, identity and memory attacks. Critical findings reported on discovery.
Report
days
Findings with transcripts, the permission model, and approval-boundary design.
Retest
included
We re-run the attack paths against your fixes and update each finding's status.

Durations are indicative. Actual scope and price are fixed after the scoping call.

Questions we get asked

How is this different from prompt injection testing?: Injection is the entry technique; this engagement is about what the agent can do once it has been steered. We spend most of the time on tools, identity, memory, and approval boundaries — the parts that decide whether a hijacked agent reads one document or empties a bucket. If your system is a chat interface over retrieval with no write actions, AI penetration testing is the better fit and we'll say so during scoping.
Can you guarantee our agents can't be hijacked?: No, and we won't imply otherwise. There is no complete defence against instructions arriving inside content an LLM has to read, so treating input filtering as the control is how teams get surprised. We design for the assumption that hijack succeeds: the agent's identity is narrow, its irreversible actions pass a human, and its behaviour is logged well enough to catch and reconstruct. That is a containment argument, not a guarantee.
Which platforms and frameworks do you cover?: The agent layer is largely framework-agnostic — orchestration graphs, agent SDKs, and managed agent runtimes share the same trust-boundary problems. The cloud identity and blast-radius work is AWS and Google Cloud; we don't claim Azure. We also don't evaluate foundation model weights, alignment, or safety behaviour, and we are not a certification body: we can map findings to NIST AI RMF functions or ISO/IEC 42001 control language for your auditors, but the certificate comes from someone else.
Do you test against our production agents?: Usually not directly. Unlike a web target, agent tool calls have real side effects — tickets get created, money moves, infrastructure changes. We prefer an environment wired to the same tools and MCP servers with non-production backends, plus read-only review of the production identity and logging configuration. Where production testing is the only meaningful option, we agree the destructive-action boundary in writing first and work inside it.

Related services

Book a scoping call