Prompt injection fails at the authority boundary in agentic AI

At a glance

What this is: This is an analysis of prompt injection as an authority-promotion failure in agentic AI, with the key finding that the risk appears when untrusted content is promoted into executable intent.

Why it matters: It matters because IAM, PAM, and agent-governance teams need to control the boundary where model output becomes tool use, state change, or policy-relevant action.

Context

Prompt injection is not just a bad prompt or a text-sanitization problem. In agentic AI, the security issue appears when untrusted content crosses an authority boundary and is treated as something that can change state, access secrets, or trigger tools.

That makes the problem an identity and authorization problem for autonomous or semi-autonomous runtimes, not a model-quality issue alone. The key governance question is where descriptive content stops and operative intent begins, and which runtime layer is allowed to make that promotion.

Key questions

Q: What breaks when untrusted text is promoted into agent intent?

A: When untrusted text is promoted into agent intent, the system turns descriptive content into operative authority. That means a malicious note, retrieved chunk, or memory entry can influence tool calls, policy exceptions, or state changes unless a runtime authorisation layer blocks the promotion. The break is the loss of a separate decision point between reading and acting.

Q: Why do agentic AI systems need runtime authorisation instead of prompt rules alone?

A: Prompt rules shape behaviour, but they do not enforce permission. Runtime authorisation is needed because agents can call tools, mutate data, or invoke workflows, and those actions require a deterministic decision outside the model. Without that layer, suggestion and permission collapse into the same path.

Q: How can teams tell whether authority boundaries are too loose in an AI runtime?

A: Authority boundaries are too loose when retrieved or injected content can influence privileged context without provenance checks, tenant scope validation, freshness review, or policy compatibility. Another sign is when the same path handles evidence, reasoning, and execution. That design makes it impossible to tell which artefact was allowed to inform a decision and which one was allowed to cause action.

Q: How should security teams secure MCP tool access when agents need to connect to multiple systems?

A: Security teams should treat MCP tool access as a governed control plane, not a loose integration layer. Scope permissions tightly, separate credentials from code, and apply least privilege to each tool and environment. Vaulted secrets, short-lived access, and clear ownership reduce the blast radius if an agent, server, or configuration file is compromised.

Technical breakdown

Authority boundaries in agentic AI runtimes

An authority boundary is the point where data changes role from content to command. Before the boundary, strings are user text, retrieved chunks, logs, memory, or tool documentation. After the boundary, the same material can influence tool calls, state mutation, external API requests, or policy exceptions. The security problem is not that the model can read untrusted text. The problem is that the runtime may treat that text as authorised intent without a separate decision layer. In practice, authority boundaries must be explicit, because every promotion step increases the power of the artefact being handled.

Practical implication: define where content becomes actionable and require a runtime decision before any promotion across that line.

Retrieval, context promotion, and tool execution are different controls

Teams often collapse retrieval, context promotion, and tool execution into one vague agent step, but they are different lifecycle stages. Retrieval is candidate selection. Context promotion is a trust and policy decision to place selected artefacts into privileged working context. Tool execution is a state-changing operation against a real system. Similarity scores can rank relevance, but they do not establish trust or authorisation. Prompt rules can shape behaviour, but they are not enforcement. Tool descriptions can explain capabilities, but they do not gate use. Separation creates room for distinct controls at each stage.

Practical implication: enforce different checks for retrieval relevance, context trust, and execution authorisation instead of treating them as one step.

RAG promotion gates and MCP action gates

RAG and MCP both expand the surfaces where authority can be promoted. In RAG, retrieved content should not enter privileged context just because it matches semantically. A promotion gate should evaluate provenance, tenant scope, freshness, classification, and policy compatibility before insertion. In MCP and other tool ecosystems, the same principle applies at dispatch: the runtime should check the tool identity, normalised arguments, actor identity, delegator identity, declared intent, and trust level before any call executes. That is why runtime policy matters more than better prompting or richer tool descriptions.

Practical implication: place policy enforcement at the promotion edge so retrieved text and tool calls cannot bypass runtime authorisation.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

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

Authority promotion is the real failure mode, not prompt reading. A model reading hostile text is not automatically a security incident. The breach condition appears when runtime design lets untrusted content cross an authority boundary and become executable intent. That distinction matters because the governance problem is about role transitions, not language quality. Practitioner conclusion: control the promotion step, not just the prompt.

Retrieval, context promotion, and execution each need different trust decisions. Retrieval answers what is available. Context promotion answers what may influence privileged reasoning. Execution answers what may change state. Collapsing those steps destroys the control points where authorisation, provenance, and tenant scope should be checked. Practitioner conclusion: separate policy for evidence, context, and action.

Permissioned execution must sit outside the model. Agent runtimes that let the model effectively self-authorise create an unsafe blend of suggestion and permission. The model should propose; an external policy layer should decide. That pattern preserves auditability and keeps probabilistic output from masquerading as authority. Practitioner conclusion: treat the model as a reasoning component, not as the authorisation boundary.

Authority-promotion failures create a governance gap that conventional prompt hygiene cannot close. Prompt filters, tool descriptions, and relevance scoring are useful, but they do not answer who may promote a string into an action. This is the missing control plane for agentic AI security, and it cuts across retrieval, memory, tool routing, and approval logic. Practitioner conclusion: build runtime governance around promotion, not around phrasing.

Agentic AI security now depends on the promotion edge as a named control concept. The practical boundary is the point where content becomes operative, and that edge must be treated like an authorisation checkpoint. Once an untrusted artefact can influence a tool call, the system has already crossed from information handling into delegated action. Practitioner conclusion: design for explicit promotion control, not implicit model discretion.

What this signals

Authority-promotion control is now a core programme design issue. Teams should stop treating prompt injection as a content problem and start treating it as a boundary problem. The practical shift is from filtering bad text to governing which artefacts can be promoted into action-bearing context.

Runtime policy has to sit between the model and the tool layer. Once agents can call tools, write files, or trigger workflows, authorisation must happen outside the model so that permission does not depend on the same probabilistic system generating the request.

Promoted context is the new blast radius variable. The question is no longer only what the model can read, but what it can be trusted to let influence downstream action. That makes provenance, tenant scope, and execution policy the controls that matter most.

For practitioners

• Define authority promotion boundaries Map every point where content can become action, including retrieval, memory injection, tool routing, and workflow triggers. Require an explicit policy decision before any artefact crosses from descriptive context into executable intent.
• Separate retrieval from execution Treat retrieval as evidence selection, context promotion as trust assignment, and tool execution as a separate authorisation event. Do not allow semantic similarity or prompt text to substitute for runtime policy.
• Put policy enforcement outside the model Use a runtime policy layer to approve, deny, or step up any proposed tool call or privileged context insertion. The model can suggest, but it must not be the component that authorises itself.
• Log every promotion and dispatch decision Capture retrieved artefact provenance, promotion rationale, tool identity, argument normalisation, actor and delegator context, and the final policy decision so blocked and allowed actions can be reconstructed later.

Key takeaways

• Prompt injection becomes a real security issue when untrusted content is promoted across an authority boundary into executable intent.
• Retrieval, context promotion, and tool execution are separate stages, and collapsing them removes the control points where authorisation should happen.
• Agentic AI governance should enforce runtime policy outside the model so that suggestion never becomes self-authorisation.

Key terms

• Authority Boundary: The point in a runtime where data stops being passive content and starts being treated as operative intent. In agentic systems, crossing this boundary can change what the system is allowed to do, so it must be governed explicitly rather than inferred from model behaviour.
• Authority Promotion: The act of elevating a piece of content, context, or memory into a role that can influence privileged reasoning or trigger a tool call. In agentic AI, the security risk is not the presence of text, but the runtime decision to let that text gain operational weight.
• Context Promotion: The decision to move retrieved or remembered content into a privileged working context where it can influence model output or actions. It is a security-relevant step because promotion grants effective authority, even when the original content was untrusted or only partially verified.
• 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.