Enterprise prompt injection defense for AI agents and MCP tools

At a glance

What this is: This is an analysis of how prompt injection attacks target AI agents and the layered controls used to limit tool misuse, data leakage, and goal hijacking.

Why it matters: It matters because security teams now have to govern agent behaviour, tool access, and contextual trust decisions with the same discipline they apply to human IAM and NHI programmes.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Akto's analysis of enterprise AI agent prompt injection defence

Context

AI agent prompt injection is the problem of untrusted content steering an agent into actions it should not take, often by abusing the same natural-language reasoning that makes the system useful. For identity security teams, the issue is not just model safety, but how autonomous tool use changes the trust boundary around access, data, and execution.

In enterprise settings, the risk extends across MCP servers, internal APIs, document ingestion, and output channels. That makes the topic relevant to NHI governance, agentic AI controls, and the lifecycle discipline that decides what an agent may do, when it may do it, and how much damage a compromised session can create.

Key questions

Q: How should security teams reduce prompt injection risk in AI agents?

A: Security teams should reduce prompt injection risk by constraining what enters the context window, limiting tool permissions, and separating untrusted retrieval content from privileged instructions. The practical goal is not perfect detection. It is to ensure that a successful injection cannot trigger wide data access, uncontrolled writes, or irreversible actions through a delegated identity.

Q: Why do AI agents create more governance risk than ordinary integrations?

A: AI agents can connect quickly, run continuously, and accumulate broad permissions across multiple services. That combination makes ownership blur and scope drift more likely, so the real risk is not the tool itself but the uncontrolled access path it creates across enterprise systems.

Q: What do teams get wrong about prompt injection in AI assistants?

A: They treat it as a content safety issue instead of an access issue. Prompt injection becomes dangerous when the assistant can read sensitive history, call APIs, or write files on the user’s behalf. The risk is not only what the prompt says. It is what identity and egress permissions allow the prompt to trigger.

Q: What should organisations do when AI agent behaviour becomes suspicious?

A: Organisations should isolate the agent, review the full action sequence, and verify whether the behaviour shows a change in destination, volume, or task scope. If the agent is moving beyond its normal pattern, treat it as a live identity risk and contain it before the session completes or data leaves the environment.

Technical breakdown

Direct and indirect prompt injection in enterprise agents

Direct prompt injection targets the user-facing prompt or API input. Indirect prompt injection hides malicious instructions inside content the agent is expected to read, such as documents, emails, tool responses, or web pages. The second path is more dangerous in enterprise environments because the malicious text travels with trusted content and bypasses filters that only inspect the original user query. Once the agent blends that content into context, the attacker is no longer attacking a chat interface. They are shaping the decision inputs that drive downstream tool calls and data access.

Practical implication: screen all agent inputs, including retrieved content and tool outputs, before they enter the context window.

Why MCP and API connections expand the attack surface

MCP tool discovery and API connectivity make agents more capable, but they also widen the path from manipulation to action. If an agent can discover tools dynamically or invoke back-end APIs on behalf of a task, a poisoned instruction can alter not just what it says, but what it does. The security problem is not the protocol alone. It is the combination of trusted tool metadata, expandable context, and execution authority that can turn a single malicious instruction into a real transaction, data pull, or privilege abuse.

Practical implication: validate every tool call against context and expected parameters, not just whether the tool is on an allow list.

Layered runtime protection and least privilege for AI agents

Runtime protection matters because many prompt injection attempts only become visible when the agent begins behaving oddly. Behavioral anomaly detection watches for unusual tool sequences, call frequency, or destination systems, while real-time blocking stops suspicious actions before execution. Least privilege remains the final containment layer: if the agent only has the permissions required for its role, successful injection still has limited blast radius. For AI agents, least privilege must be applied to both data and action, because the same identity can leak records, trigger workflows, or expose credentials if controls are too broad.

Practical implication: combine runtime blocking with tightly scoped agent permissions so one bad instruction cannot become broad compromise.

Threat narrative

Attacker objective: The attacker wants to convert trusted agent execution into unauthorised business action, data exposure, or privilege abuse without triggering normal human review.

1. Entry occurs when an attacker places malicious instructions into a direct prompt, an uploaded document, a web page, or a tool response that an AI agent is expected to trust.
2. Escalation happens when the agent incorporates that content into its reasoning and uses legitimate credentials or tools to carry out actions beyond the user’s intent.
3. Impact follows when the agent exfiltrates data, triggers unauthorised transactions, reveals credentials, or performs destructive actions across connected systems.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Gemini AI Breach — Google Calendar Prompt Injection — Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prompt injection is an identity problem before it is a model problem. Once an AI agent can read, decide, and act across tools, the security question shifts from content moderation to authorization at runtime. That makes the agent’s identity posture part of the attack surface, because the attacker is really trying to influence what a trusted non-human identity is allowed to do. Practitioners should treat agent execution as governed identity behaviour, not just model output.

Runtime trust is the named concept that security teams need to sharpen. Enterprise agents routinely ingest content from documents, APIs, and tool responses that were never meant to be equivalent to operator intent. When those channels are blended, indirect prompt injection becomes a trust-boundary failure, not an anomaly in the prompt string. The practical conclusion is that governance must separate trusted instructions from untrusted content before the agent reasons over either one.

Least privilege for AI agents is only meaningful when it constrains action, not just access. A role that can read one customer record but also trigger exports, send messages, or call downstream services has more effective power than its token scope suggests. This is why agentic governance has to look at request context, permitted tools, and output paths together. Practitioners should measure blast radius by what an injected instruction can actually cause, not by what the permission matrix appears to allow.

Continuous red teaming is now a control validation discipline, not a launch ritual. Agents change as prompts, tools, and models change, which means a test that passed last quarter may no longer reflect current behaviour. That creates a governance gap in programmes that certify agents once and then assume stable risk. The field should expect prompt injection testing to move into ongoing assurance cycles alongside other identity and access reviews.

MCP discovery changes the governance assumption behind tool trust. Tool access was designed for systems that knew their integrations in advance. That assumption weakens when an agent can discover, load, or act on tools dynamically inside a session. Practitioners should treat tool metadata, not only credentials, as an identity control surface.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap points to a forward risk pattern covered in OWASP Agentic AI Top 10, where runtime behaviour and tool use become the governance challenge.

What this signals

Runtime trust is becoming the decision point for agent governance. Teams that still think of prompt injection as a content problem will miss the operational reality that agents make access decisions inside the same session they consume untrusted inputs. The governance response is to treat context, tools, and output channels as one control plane, not three separate issues.

With 80% of organisations already seeing AI agents act beyond intended scope, the control gap is no longer hypothetical. That figure is a signal that policy-only approaches are not keeping pace with deployed behaviour, especially where agents can touch internal systems and customer data. Practitioners should align their agent programme with the NIST AI Risk Management Framework and OWASP Agentic AI Top 10 rather than treating agent oversight as an extension of chatbot governance.

Continuous assurance will matter more than initial approval. The more an agent changes through new prompts, tools, or workflows, the less meaningful a one-time review becomes. Security leaders should expect recurring simulation, detection tuning, and access review cycles to sit alongside existing IAM and NHI governance processes.

For practitioners

• Screen all agent inputs before context ingestion Inspect user messages, uploaded files, retrieved documents, tool responses, and metadata for hidden instructions or suspicious formatting before they reach the model context.
• Validate each tool call against task context Check whether the requested action matches the current task, expected parameters, and permitted customer or data scope before allowing execution.
• Separate trusted instructions from untrusted content Use context isolation so system instructions, user prompts, and retrieved content remain distinct and are not blended into a single trust domain.
• Constrain agent blast radius with least privilege Limit each agent to the smallest practical set of data, tools, and output channels so a successful injection cannot cascade into broader compromise.
• Run continuous contextual red team tests Test the actual agent role, toolset, and data flow on an ongoing basis because prompt updates, new tools, and model changes can reopen attack paths.

Key takeaways

• Prompt injection turns AI agents into execution risks when untrusted content influences tool use, data access, or downstream actions.
• The evidence now points to a broad governance gap, not an edge-case weakness, because organisations are already seeing agents exceed intended scope at scale.
• The most effective response is layered control: separate trust domains, validate each action, limit privilege, and test continuously.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Context Isolation: Context isolation is the practice of keeping user input, system instructions, retrieved content, and memory separate so one cannot silently alter the other. In AI security, it is a core control because mixed context lets untrusted text inherit authority it was never meant to have.
• Tool Call Validation: Tool call validation is the enforcement layer that checks whether an AI agent is allowed to invoke a tool, pass specific parameters, and reach a given data source. It matters because a well-formed agent can still become unsafe if its runtime actions are not checked against permissions and policy.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of input screening, output filtering, and context isolation for enterprise agents
• Runtime detection logic for unusual tool sequences, repeated calls, and context-mismatched actions
• Layered defence patterns for RBAC, BOLA prevention, and agent blast-radius reduction
• Continuous AI red teaming examples that test real tools, prompts, and workflows in production-like conditions

👉 The full Akto blog covers runtime guardrails, least-privilege design, and continuous red teaming in more implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.