Prompt injection attacks expose the execution layer in agentic AI

At a glance

What this is: This is an analysis of how prompt injection turns untrusted text into unintended agent actions, with the key finding that execution-capable AI changes the risk from content manipulation to system compromise.

Why it matters: It matters because IAM teams now have to govern AI agent authority, data access, and tool execution as identity problems, not just application security problems.

👉 Read Keyfactor's analysis of how prompt injection attacks work

Context

Prompt injection is a control problem in agentic AI, not just a model quality problem. It occurs when attacker-controlled text is treated as instruction content, causing an AI agent to take actions the organisation did not intend. The issue becomes an IAM concern the moment that agent can reach databases, APIs, or other enterprise systems.

For identity teams, the important boundary is not whether the prompt looks malicious, but whether the actor is allowed to execute anything that came through an untrusted input path. That makes prompt provenance, directive freshness, and execution approval part of the identity control plane rather than an optional application layer add-on.

Key questions

Q: How should security teams prevent prompt injection from triggering AI agent actions?

A: Security teams should separate untrusted text from executable instructions, then require a policy check before any agent can call tools or modify systems. The model should never be the trust decision maker. Pair that with least-privilege tool access so a successful injection cannot reach the full environment.

Q: Why is prompt injection a governance issue for IAM teams?

A: Prompt injection becomes an IAM issue when AI agents hold credentials, access APIs, or operate on enterprise data. The problem is not just bad output. It is unauthorized use of legitimate authority, which makes identity scope, approval, and provenance part of the control model.

Q: When do signed prompts still leave organisations exposed?

A: Signed prompts still leave organisations exposed when replay is possible or when the signing party is allowed to authorize actions outside the intended scope. Signature validity proves origin and integrity, but it does not prove the instruction is current, appropriate, or safe to repeat.

Q: What is the difference between prompt signing and prompt filtering?

A: Prompt signing proves a directive came from an approved source and was not changed. Prompt filtering tries to block suspicious text patterns after the fact. Signing is a provenance and authorization control. Filtering is a content control, and content controls do not reliably stop semantic attacks in agentic systems.

Technical breakdown

Instruction override in prompt injection

Instruction override happens when malicious directives are embedded inside otherwise legitimate user input, such as a form field or free-text prompt. Large language models do not natively distinguish content from instructions with perfect reliability, so an embedded command can be interpreted as part of the task. The technical problem is not syntax filtering. It is that the model evaluates all tokens in the same context unless the surrounding architecture preserves trust boundaries and marks untrusted content as non-executable.

Practical implication: isolate user-controlled text from executable instructions and reject any design that assumes the model will self-separate trust domains.

Context confusion across agent workflows

Context confusion occurs when an agent combines data from system prompts, user input, retrieved documents, and API responses without preserving origin metadata. In multi-agent chains, that confusion compounds as one agent passes untrusted material to another, and each hop can strip away trust context. The result is that malicious instructions can inherit authority from earlier processing stages, especially when one agent has broader permissions than the original entry point.

Practical implication: preserve source-of-truth metadata across every hop in the agent chain and prevent downstream agents from inheriting authority they were never meant to receive.

Signed prompts, freshness windows, and replay risk

Cryptographic signing helps prove that a directive is authentic and unmodified, but it does not automatically make the instruction safe to repeat. If a signed prompt can be replayed later, an attacker may re-trigger sensitive actions such as certificate enrollment or configuration change. The mechanism that matters is not signature alone, but signature plus timestamp freshness. Without a bounded recency check, a valid old directive can remain executable long after its intended moment of use.

Practical implication: pair directive signing with strict freshness validation for one-time or high-risk actions so replayed instructions fail at verification.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 execution-layer identity problem, not a content-moderation problem. The article makes clear that once an AI agent can call tools, the security boundary moves from text filtering to permissioned action. That means the governing question is no longer whether the model produced harmful output, but whether an untrusted instruction path was allowed to trigger enterprise action. Practitioners should treat agent execution rights as the control surface.

Natural language is a poor trust boundary for privileged systems. Prompt injection exploits the fact that language models can treat user data and system instructions as semantically similar inputs. That collapses a core governance assumption: that intent can be reliably separated at runtime by the model itself. In NHI terms, this is an identity-context problem where the actor consumes mixed-trust inputs and may act on the wrong one. Practitioners should stop assuming the model can adjudicate trust on its own.

Directive signing creates provenance, but provenance alone does not solve replay or scope abuse. The article’s signing model proves authenticity and integrity, yet it still depends on freshness windows and source authorization. That aligns with OWASP-NHI and zero-trust thinking: the control is not merely “was this prompt signed,” but “was it signed by the right party for this exact action at this exact moment.” Practitioners should view signing as a boundary condition, not a complete governance model.

Multi-agent chains widen the blast radius because trust inheritance is operationally sticky. When one agent hands work to another, the original trust context can degrade, and permissions often increase at handoff points. That creates a named concept we should call trust inheritance drift: authority accumulates faster than provenance, and the chain becomes less accountable with each transfer. Practitioners should design for explicit trust resets between agents, not assume downstream agents inherit only safe context.

Zero Trust Architecture breaks if the agent is allowed to act before the trust decision is complete. The architecture described in the article shows verification before execution, which is the correct direction for this problem. But the deeper implication is that many current AI workflows still let prompt content reach execution logic without a durable policy gate. Practitioners should rework agent controls so untrusted directives cannot cross the action boundary unverified.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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 blind spot is why OWASP Agentic AI Top 10 and related governance controls need to move from theory to operational policy.

What this signals

Prompt provenance will become a first-class control for AI operations. As AI agents move from chat to action, organisations will need to prove not just what a system said, but whether the directive that triggered action was authorized, fresh, and traceable. The operational question shifts from model safety to execution governance, which is where identity teams already have the right mental model.

With 48% of companies lacking a complete audit view of the data their AI agents access, per AI Agents: The New Attack Surface report, prompt-level governance is quickly becoming a compliance requirement rather than an architecture preference. The programme gap is usually not tooling breadth, but the absence of durable trust boundaries between human requests, retrieved content, and machine action.

Trust inheritance drift: each agent handoff weakens provenance unless the control plane resets trust explicitly. That means governance teams should prepare for policies that verify source, scope, and freshness at every execution boundary, not only at initial login or first authorization.

For practitioners

• Separate instruction channels from user content Keep system instructions, retrieved data, and user-provided text in distinct trust domains so the model never has to infer which text is executable. Preserve origin metadata through the full workflow and block any pathway where untrusted content can be interpreted as a command.
• Require directive signing for privileged agent actions Use cryptographic signatures for prompts that can trigger tool use, API calls, or configuration changes. Make signing policy-based so only approved sources can issue directives for sensitive operations, and ensure the signature chain is checked before execution begins.
• Add freshness checks to prevent replay Set a recency threshold for one-time or high-risk directives such as certificate enrollment, record deletion, or infrastructure changes. Reject signed instructions that fall outside the allowed window, even if the signature itself validates correctly.
• Reset trust at every agent handoff Treat each agent boundary as a new authorization point, not a continuation of the previous one. Strip inherited authority from downstream agents unless a policy explicitly re-issues it, and log the handoff so provenance is visible for investigation.
• Limit tool scope to the minimum execution set Constrain each agent to the smallest possible set of APIs, databases, and administrative actions needed for its job. If a prompt injection succeeds, narrow permissions reduce the blast radius and make misuse easier to detect.

Key takeaways

• Prompt injection succeeds because AI agents can turn untrusted natural language into real action, which makes this an execution-control problem rather than a content-filtering problem.
• The scale of exposure is already high, with most organisations planning broader AI agent deployment even as rogue behaviour and audit blind spots remain common.
• The decisive control is not just prompt signing, but signed, fresh, scope-limited directives that cannot be replayed or inherited across agent handoffs.

Key terms

• Prompt Injection: Prompt injection is an attack that places malicious instructions inside otherwise legitimate text so an AI system may follow attacker intent instead of user intent. In agentic systems, the risk is not limited to bad output. It can extend to tool use, data access, and system changes if the agent treats the injected text as executable authority.
• Directive Signing: Directive signing is the practice of cryptographically approving an AI prompt or instruction before execution. It establishes origin and integrity, and it can support authorization policy as well. In practice, signing only becomes effective when paired with freshness checks, scope limits, and a controlled verification step before the agent acts.
• Trust Boundary: A trust boundary is the point where data from one source must not be treated as having the same authority as data from another source. For AI agents, that boundary must separate system instructions, user input, retrieved content, and downstream agent outputs. If the boundary is weak, untrusted text can inherit execution authority.
• Replay Attack: A replay attack reuses a previously valid directive or credential after the original moment of authorization has passed. In AI prompt workflows, a replayed signed prompt can still verify correctly unless the system also checks recency. That makes freshness a security property, not just an operational convenience.

Deepen your knowledge

Prompt injection and agent execution governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agents that can act on enterprise systems, this is a relevant place to start.

This post draws on content published by Keyfactor: Prompt Signing, How Prompt Injection Attacks Work. Read the original.