The True Blast Radius of an AI Attack

TL;DR

• Companies are starting to give AI real jobs inside their business systems, like searching internal databases or changing business records, so an AI that gets tricked can now take harmful actions instead of just giving a wrong answer or exposing data. How much damage that causes depends on the gap between what the AI was built to do and what its access actually allows, and on whether the systems around it can block a bad action. This post explains how to measure that reach and contain it before giving AI more responsibility.
• Instructions hidden in a supplier document could redirect an agent to change a payment destination, but the change only goes through if the agent also has a payment tool, enough permissions, and no independent approval in the way. Fooling the model is not the same as proving impact. Assessments should trace untrusted input through tools, Model Context Protocol (MCP) servers, subagents, and APIs to an unauthorized outcome, testing for goal hijacking, tool misuse, excessive agency, privilege abuse, and MCP-specific issues like token passthrough and confused deputy attacks. Enforcement belongs where actions execute: scoped credentials, per-operation authorization, validated tool inputs, isolated execution environments, action-bound approvals, and audit trails, with adversarial testing required before an agent’s authority grows.
  

Connecting AI to enterprise systems changes what organizations entrust software to do. An agent that can query internal databases or modify business records has operational authority, and the scope of that authority becomes a security decision.

Agentic AI security is the practice of protecting AI systems that use tools to carry out tasks and preventing those capabilities from being used without authorization. It extends familiar concerns about data exposure and harmful outputs to the consequences of actions taken in live systems.

For security leaders, the challenge is understanding how far that authority reaches. An agent’s apparent purpose may be narrow, while its credentials grant access well beyond the task. The true blast radius of an AI attack depends on the size of that gap and on whether the surrounding systems can contain a manipulated agent.

When a Malicious Instruction Becomes an Operational Risk

In an AI application limited to generating text, prompt injection can undermine responses or expose information available to the model. An agent with operational tools introduces another possibility: malicious instructions can influence actions in connected systems.

Consider an agent reviewing a supplier document. Instructions embedded in that document could attempt to redirect it to change a payment destination. The document should serve as input to process, but the attack attempts to turn it into a source of authority.

Following the malicious instruction is only one step. To complete the change, the agent would also need access to a payment tool and permissions that allow the operation to proceed. An independently enforced approval control could stop the transaction even if the model had already been manipulated.

This distinction matters when evaluating risk. A successful prompt injection demonstrates influence over the model. Demonstrating business impact requires tracing what that influence allows an attacker to accomplish.

Where the Agentic AI Attack Surface Expands

An agentic AI architecture connects model outputs to systems that act on them. Each connection introduces implementation choices that can grant additional access or weaken an existing boundary.

Integrated tools and business applications. Database connectors and custom functions determine what operations an agent can request. Broad functions, such as unrestricted command execution, can expose substantially broader capabilities than a task-specific tool.

MCP servers. Model Context Protocol (MCP) provides a standardized way for AI applications to access tools and data. MCP server security encompasses server implementations and the access controls that support those connections, including how servers handle credentials and interact with downstream resources.

Delegated subagents. An orchestrator may assign work to agents with different capabilities. Those handoffs can carry malicious instructions or excessive authority into another workflow if receiving agents trust the transferred context without enforcing their own limits.

External APIs and services. Connected applications determine whether an agent’s requests are permitted. Integrations that rely on a shared, highly privileged identity can obscure who initiated an action and grant access beyond that person’s rights.

The Failure Modes That Widen the Blast Radius

Several related failures can turn an agent’s legitimate capabilities against the organization:

• Goal hijacking: Malicious instructions redirect an agent from its assigned task toward an attacker’s objective.
• Tool misuse: An agent invokes a legitimate tool in an unauthorized way or supplies inputs that exploit weaknesses in the tool’s implementation.
• Excessive agency: Unnecessary capabilities or autonomy allow the agent to act beyond its intended business function.
• Privilege abuse: An agent uses permissions that exceed the authority of the person requesting the action.

OWASP’s Top 10 for Agentic Applications and its guidance on excessive agency address these risks. The risks become especially significant when they combine: goal hijacking becomes more consequential when the redirected agent also has unnecessary capabilities and broad privileges.

Assessing Agentic AI Security from Input to Action

An agentic AI security assessment should test whether an attacker can turn malicious input into an unauthorized outcome and document evidence of the resulting impact.

Start by mapping the intended business workflow against the access available to support it. Identify where the agent encounters untrusted content and follow its requests through tools, delegated agents, and downstream applications. This establishes where authority is granted and where it is checked.

Testing should then challenge those boundaries under realistic conditions:

• Can instructions in an external document trigger an operation outside the assigned task?
• Can a user retrieve another user’s records or invoke a restricted function through the agent?
• Does an approval requirement remain effective when work passes to a subagent?
• Can a tool’s execution environment expose credentials or reach unrelated systems?

MCP server security testing should examine authentication and token handling alongside access to connected resources. MCP’s security guidance identifies issues such as token passthrough and confused deputy attacks that can undermine these boundaries.

Findings should distinguish model manipulation from demonstrated unauthorized access or execution. They should also identify which controls stopped an attempted attack, giving security teams evidence of both exploitable weaknesses and effective containment.

Put Safeguards Where Actions Are Executed

Assessment results should guide controls that remain effective when an agent makes an unsafe decision. Instructions within the model’s context can support secure behavior, but enforcement must also exist in the systems that carry out its requests.

• Limit capabilities to the task. Expose only necessary tool functions and use narrowly scoped credentials.
• Enforce authorization for each operation. Downstream systems should check the initiating user’s or workload’s rights to perform the requested action on the resource.
• Validate tool inputs. Treat model-generated parameters as untrusted and constrain executable operations.
• Isolate execution environments. Restrict tool runners’ access to secrets and unrelated services, and limit access to outbound network destinations.
• Bind approvals to specific actions. Require explicit approval for consequential operations without allowing approval for one action to become broader permission.
• Preserve an actionable audit trail. Record the initiating identity and resulting tool activity so teams can investigate misuse and revoke access.

These safeguards support containment across both single-agent and multi-agent workflows.

Require Evidence Before Expanding Authority

Agentic AI security decisions should reflect the consequences of the access being granted. Permission to search an internal knowledge base warrants a different level of scrutiny from permission to change production systems.

Before expanding an agent’s role, require evidence from adversarial testing that controls block restricted actions. Reassess when new integrations or permissions change what the agent can reach. A deployment that was appropriately constrained at launch may acquire a much larger blast radius as its responsibilities grow.

Identify exploitable weaknesses across your agentic attack surface, including MCP server security gaps, and prioritize fixes with Bishop Fox’s AI/LLM Security Assessment Services.