- Bishop Fox argues that the damage from a tricked AI agent is set by the access it holds, not by how easily the model is fooled.
- Agents wired to payment tools, databases and other systems can turn a hidden instruction into a real action unless separate controls stop it.
- Leaders should ask what each agent's credentials allow and whether downstream systems check approvals before its role expands.
The key matters more than the trick
A common question is how easily an AI model can be fooled. Bishop Fox, a security consulting firm, focuses on what the model can touch once it is fooled. The lesson here is that an AI agent's risk is set by its access, not by its gullibility.
Bishop Fox calls this the blast radius. It depends, the firm says, on the gap between what an agent appears to be for and what its credentials allow. It also depends on whether the surrounding systems can contain an agent that has been manipulated.
One poisoned document, one changed payment
Bishop Fox gives a plain example. An agent reviews a supplier document. Instructions hidden in that document try to redirect the agent to change a payment destination.
The document should be something the agent reads. The attack tries to make it something the agent obeys.
Obeying is only one step. Bishop Fox notes the agent would also need a payment tool and permissions that let the change proceed. An approval control enforced independently of the model could stop the transaction even after the model had been manipulated.
The firm draws a useful line. A successful prompt injection, where hidden text steers the model, shows influence over the model. Showing business impact means tracing what that influence lets an attacker do.
How the reach builds up
An agent is a model whose outputs are wired to systems that act on them. Bishop Fox points to four kinds of connection, and each one can add access.
Tools and business applications come first. Database connectors and custom functions decide what the agent can ask for. A broad function, such as unrestricted command execution, exposes substantially broader capabilities than a tool built for one task.
Next are MCP servers. The Model Context Protocol (MCP) is a standard way for AI applications to reach tools and data. Risk sits in how servers handle credentials and reach downstream resources.
Then come delegated subagents. An orchestrating agent hands work to others. If the receiving agent trusts what it is handed, malicious instructions or excess authority can travel with the task.
Last are outside services. Bishop Fox warns that a shared, highly privileged identity can hide who started an action. It can also grant access beyond that person's rights.
Four ways an agent's own abilities get turned on you
Bishop Fox names four failure modes, which OWASP's Top 10 for Agentic Applications also addresses. Goal hijacking redirects the agent toward an attacker's aim. Tool misuse uses a legitimate tool in an unauthorized way. Excessive agency gives the agent more capability or autonomy than the job needs. Privilege abuse lets the agent use permissions beyond those of the person asking.
The firm says these matter most in combination. A hijacked agent is more consequential when it also holds unnecessary capabilities and broad privileges.
Bishop Fox also cites MCP's own security guidance, which flags token passthrough and confused deputy attacks. A confused deputy is a trusted program tricked into using its own authority for someone who has none.
Put the lock where the action happens
Bishop Fox says that telling the model to behave safely helps, but cannot be the only defense. The checks must also sit in the systems that actually carry out what the agent asks for. Its list of safeguards is concrete.
Expose only the tool functions a task needs, with narrowly scoped credentials. Have downstream systems check the rights of the person or workload behind each request. Treat model-generated inputs as untrusted. Restrict what tool runners can reach, including secrets and outbound network destinations. Tie each approval to one specific action. Keep an audit trail of who initiated what.
Questions to put to your team
Bishop Fox advises requiring evidence from adversarial testing before an agent's role expands. The firm also warns that an agent kept tightly limited at launch can end up with a much larger blast radius as it takes on more duties. These questions follow from that advice:
Which credentials does each agent hold, and do they match its job? Do downstream systems check the requesting person's rights, or trust one shared identity? Does an approval still hold when work passes to a subagent? Can a tool's runtime reach secrets or unrelated systems? Do logs show who started each action?
Start by sorting your agents into two groups. Bishop Fox says permission to search an internal knowledge base warrants different scrutiny from permission to change production systems. Agents that only search can be reviewed lightly. Agents that change records or move money should face the hardest questions and the strongest approval controls first.
One caveat. Bishop Fox sells AI and LLM security assessments, and the post is guidance rather than incident data. It reports no measured attacks.
Still, the framing holds up as a budgeting test. Ask what the agent can do if fooled, not whether it can be fooled. An agent is only as contained as the systems that answer its requests.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Bishop Fox.
