By NHI Mgmt Group Editorial TeamBased on Akto: “How Enterprise Security Teams Defend AI Agents Against Prompt Injection” (July 12, 2026)

TL;DR: Prompt injection can turn AI agents into execution engines for unauthorized tool calls, data exposure, and privilege misuse, especially when agents trust indirect instructions embedded in documents, tool responses, or API content, according to Akto. The governance gap is that traditional IAM and AppSec assumptions do not fully account for runtime agent behaviour.


At a glance

What this is: Akto shows that prompt injection is an enterprise AI agent risk because malicious instructions can move through trusted content and trigger real actions, not just bad model outputs.

Why it matters: IAM, PAM, and application security teams need to treat agent behaviour, tool use, and output control as one governance problem, because a compromised agent can become an execution path.


Context

Prompt injection is a control failure in which an AI agent treats attacker-supplied text as instruction rather than untrusted content. In enterprise settings, that matters because the agent is not just answering questions, it is making decisions, calling tools, and reading data that can affect real systems.

The governance gap is that existing IAM and AppSec models assume the actor either follows predefined code paths or can be reviewed after the fact. Agentic AI breaks that assumption by blending reasoning, tool selection, and execution into a single runtime chain that traditional controls do not fully observe.

Akto frames the problem as a layered defense issue rather than a single filter problem. That is the right level of analysis for practitioners because prompt injection can enter through documents, tool outputs, or MCP-connected services and still reach privileged actions if the surrounding controls are weak.


Key questions

Q: What breaks when prompt injection reaches a tool-using AI agent?

A: What breaks is the assumption that the model's output is low impact. Once the agent can call tools, a malicious instruction can become a database query, a file write, an email, or a deployment action. Without policy checks and approval gates, the agent's legitimate permissions become the attacker's path to impact.

Q: Why do AI agent traps create more risk than ordinary prompt injection?

A: They create more risk because the content is only the starting point. Damage happens when a deceived agent can convert hostile input into a tool call, file access, or data exfiltration through legitimate privileges. Prompt injection becomes an access-control problem the moment the agent owns an execution path into enterprise systems.

Q: How should security teams evaluate prompt injection defenses before deploying them in production?

A: Security teams should test prompt injection defenses against realistic attack patterns, not just public benchmark scores. A useful evaluation measures whether controls stop harmful instructions, resist overfitting, and still perform when the test set changes. The goal is to judge operational resilience, not leaderboard performance, because a defense that looks strong in a static dataset can fail under live attack conditions.

Q: What should enterprises do after an AI agent is compromised by prompt injection?

A: Contain the affected tools and revoke the agent's effective access before it can continue the conversation or reuse context. Then review which content sources, tool descriptions, and permissions allowed the injected instruction to become actionable. The priority is to stop further execution, not only to investigate the text.


Technical breakdown

Direct and indirect prompt injection in enterprise agents

Direct prompt injection arrives through the user-facing prompt or API input, where the attacker tries to override the system instruction in real time. Indirect prompt injection is more dangerous in enterprise environments because the malicious instruction is embedded in content the agent is expected to trust, such as documents, summaries, tool responses, or downstream API data. The model is not being broken at the code layer. Instead, the attacker is abusing the agent's willingness to treat retrieved content as part of its reasoning context. That makes the content boundary, not just the prompt boundary, part of the security problem.

Practical implication: classify every input channel as potentially hostile, including retrieved documents and tool outputs.

Why MCP tools and APIs expand prompt injection risk

MCP and API-connected agents widen the attack surface because the model can discover, select, and invoke tools as part of its task flow. If tool descriptions, context payloads, or connected services are poisoned, the agent may execute actions that were never meant for the current user or task. The security issue is not just tool existence, but tool trust and tool scope at runtime. Once an agent can combine instructions from one source with authority from another, the blast radius becomes a function of how much the tools expose and how weakly each call is validated.

Practical implication: validate tool intent, context, and request scope on every call, not just on tool registration.

Layered runtime guardrails are stronger than pre-deployment filtering alone

Prompt injection defenses work best when prevention, detection, and enforcement are separated into layers. Input screening reduces the chance that malicious content enters the model context. Behavioral anomaly detection and tool call validation catch abnormal sequences, repeated calls, or requests that do not fit the agent's normal purpose. Real-time blocking is the decisive layer because it prevents unauthorized actions before they execute. That matters for enterprises because prompt injection often looks harmless until the exact tool call or data export happens. Security teams therefore need controls that inspect behavior in motion, not just content at rest.

Practical implication: place runtime blocking in front of sensitive tools and data actions, not only logging and review.


Threat narrative

Attacker objective: The attacker wants to turn a trusted AI agent into an execution path for unauthorized actions, data exposure, or privilege misuse.

  1. Entry occurs when malicious instructions are placed in a document, tool response, or other content the agent is already designed to read.
  2. Credential or privilege abuse follows when the agent trusts the injected instruction and uses its existing access to call tools, query data, or trigger actions.
  3. Impact is reached when the agent completes an unauthorized export, transaction, or data disclosure with no human approval in the loop.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Prompt injection is an identity problem before it is a content problem. The article makes clear that the risk emerges when a model is allowed to choose tools and act on trusted context, not merely generate text. That moves the issue into governance over runtime authority, token scope, and tool trust boundaries. Practitioners should treat the agent as an identity-bearing actor with executable privilege, not as a chat interface with a safety filter.

Indirect prompt injection exposes a content trust gap that traditional IAM never covered. IAM assumes authorization decisions are attached to known actors and intended requests. Here, the attacker hides instructions inside content the agent is supposed to process, so the trust decision is displaced from login to context ingestion. The result is a governance blind spot where the permission was valid but the instruction was not. Practitioners need to recognise that source provenance and instruction provenance are different control problems.

Agentic AI collapses the assumption that review can happen after access is exercised. Access review, logging, and post-event analysis all assume the risky action persists long enough to be observed. In prompt injection attacks, the agent can ingest the malicious instruction, select a tool, and execute within one conversational sequence. The implication is that control must move from periodic review to decision-time enforcement.

Runtime protection becomes the decisive control plane for AI agent security. The article's layered model is directionally correct because prompt injection is not reliably stopped by a single content filter or static permission model. The real governance question is how quickly a security control can recognise a hijacked action and stop it before the agent completes the call. Practitioners should elevate inline enforcement above retrospective detection for sensitive workflows.

Tool discovery and connected APIs create a prompt-to-action supply chain. Once an agent can discover tools through MCP and then call APIs with inherited authority, every upstream content source becomes part of the security chain. That turns tool descriptions, context windows, and downstream services into an identity and authorisation problem, not just an application hardening problem. The implication for teams is that agent governance now spans discovery, invocation, and least-privilege scoping end to end.

From our research library:

What this signals

Prompt injection shifts AI security from model safety to identity governance. Once an agent can select tools and act on embedded instructions, the primary control question is no longer whether the model responds safely. It is whether the organisation can bound what that identity can do when the input is adversarial, especially across tool discovery, context ingestion, and execution.

Static permissions are not enough when the attacker steers runtime intent. Security teams need to assume that a valid token or allowed tool is not proof of safe use. The governance problem is whether each action is still aligned to the current task, the current user, and the current data scope.

Agentic AI security will increasingly sit between AppSec, IAM, and platform engineering. That is because prompt injection can enter through content, exploit tool trust, and finish as an unauthorised action. Programmes that keep these controls separate will keep missing the handoff point where text becomes execution.


For practitioners

  • Harden all agent inputs and retrieved content Screen prompts, documents, tool responses, and API payloads before they reach the model context. Treat metadata, formatting, and system-like text in untrusted content as signals for review, not as harmless structure.
  • Validate each tool call against live context Check whether the requested action matches the user's task, the agent's role, and the permitted data scope at the moment of execution. Do not rely on a static allow list when the real risk is overbroad intent.
  • Separate trusted instructions from untrusted content Use context isolation so system instructions, user inputs, and retrieved content are not blended into one prompt channel. This reduces the chance that embedded instructions are treated as operator intent.
  • Enforce least privilege for agent tools and data paths Scope agent roles so a successful injection cannot reach unrelated systems, broad exports, or sensitive write operations. The smallest possible permission set should bound the agent's blast radius.
  • Run continuous AI red teaming Test prompt injection paths after every meaningful prompt, tool, or model change, and include end-to-end attack chains that combine leakage, tool misuse, and follow-on actions. One-off testing is not enough once the agent evolves.

Key takeaways

  • Prompt injection becomes an enterprise control issue when AI agents can turn untrusted content into real tool calls and data movement.
  • The article's layered approach shows that content filtering alone cannot stop attacks that rely on runtime trust and connected APIs.
  • Practitioners need runtime validation, least privilege, and continuous red teaming to keep agent behaviour within governed bounds.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI01 — Agent Goal HijackPrompt injection steers agent objectives away from intended tasks.
ASI02 — Tool MisuseThe article centers on unauthorized tool calls through agent trust.
ASI03 — Identity & Privilege AbuseInjected prompts exploit the agent's existing authority and permissions.
Recommendation — Map prompt injection paths to ASI01 and block hijacked task execution before tool calls complete. Use ASI02 to validate every tool invocation against the current task and context. Apply ASI03 to narrow agent privileges so compromised intent cannot reach unrelated systems.
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe agent's trust and action path depends on how its runtime identity is accepted.
NHI-05 — Overprivileged NHIA prompt-injected agent can only cause broad harm if it has excessive scope.
Recommendation — Harden authentication for agent and tool interactions so untrusted content cannot impersonate intended instruction. Reduce agent permissions to the minimum scope needed for each workflow and tool set.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about governing what the agent may do at runtime.
DE.CM-09 — Monitoring for Unauthorized ActivitiesRuntime anomaly detection is central to catching hijacked agent behavior.
Recommendation — Enforce PR.AA-05 by aligning each agent action with explicit, current authorisation. Monitor agent tool usage for deviations and block unauthorized activity in-line.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementPrompt injection can lead to stolen data and expanded access across connected systems.
Recommendation — Track injected-agent abuse to TA0006 and TA0008 to prioritise detection on tool-driven movement.

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.
  • Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
  • 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.

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 building or maturing an identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org