AI Agent Prompt Injection

What Is AI Agent Prompt Injection?

AI agent prompt injection is prompt injection that occurs in a system able to plan, choose tools, read and write state and act across several steps. The injection mechanism is not new. What differs is the environment in which the influenced text lands: instead of a single answer, the model produces plans and action proposals that other components may execute.

The influencing content can enter directly, through the user channel the application intends to accept, or indirectly, through website content, email, documents, retrieved passages, search results, repository text or a tool result. Both paths can reach the same planner.

This is therefore not a third injection variant beside direct and indirect injection. It is the same mechanism analysed in a system where the consequence of an influenced plan can be an action rather than a sentence.

For the foundations of the tool-calling loop, see the Learn article AI Agents and Tool Calling.

Why Agency Changes the Security Consequence

A conversational assistant without tools can produce wrong, misleading or manipulated output. That matters for integrity of information and for downstream systems that consume the answer, but the model itself reaches nothing. An agent additionally holds or can request capabilities: it reads records, writes state, sends messages, calls services, changes configuration or runs code, depending on how it was built.

The consequence is not determined by the label "agent" but by concrete properties: which tools exist, which data is reachable, which identity and delegated authority are used, which actions are irreversible and which control layers sit between a proposal and an effect.

Scope and Related Classes

Insecure inter-agent communication is covered in Multi-Agent Prompt Injection.

OWASP describes excessive agency as a vulnerability enabled by excessive functionality, permissions or autonomy, which allows damaging actions in response to unexpected, ambiguous or manipulated model output. Prompt injection is one way that output becomes manipulated; the damage potential comes from the agency granted by the design.

Direct and Indirect Entry Into an Agent

All of these can reach the same planner, but they do not carry the same trust properties. Direct input is attributable to an authenticated principal and is still untrusted as instruction authority. External content usually has no attributable author at all. Provenance must therefore be recorded at the point of ingestion, not reconstructed afterwards.

Direct prompt injection and indirect prompt injection describe these entry paths in detail; this article follows what happens once the content is inside an agent loop.

The Agent Execution Pipeline

Planner, policy, authorization and the tool runtime are operator-controlled components. Incoming external context and tool observations are untrusted by default. Plans, proposals and effects are variable: their security meaning depends on what the surrounding controls allow.

Goal, Task and Authority Are Different Things

Text that states a goal, however imperative its phrasing, is at most an input to the first column. It cannot create policy and cannot create permission. A system that lets goal statements widen data access or action scope has moved an authorization decision into the model.

Agent Identity Versus Initiating Principal

Microsoft's least-privilege guidance for AI agents recommends stable, lifecycle-managed agent identities with an accountable owner, scoped and just-in-time entitlements, task-scoped authorization, explicit tool and action policy, downstream authorization and fast revocation. The related identity and access guidance recommends making trust decisions per user, agent, plugin and tool, and binding permissions to the initiating principal and the specific task.

Capability Inventory and Effective Permission Graph

Reviewing tools one at a time understates risk. What matters is the effective permission graph: everything the agent can reach end to end, across systems, with the identities available to it. Several individually narrow permissions can combine into a wide blast radius.

A controlled exercise, the Tool-Chain Analysis lab, practices sequence-level composition analysis: cumulative effects, retries after unobserved outcomes and bounded cross-agent chains. It is a deterministic simulation, not a procedure for chaining real systems.

Planning, Proposal and Execution Separation

Model output is a proposal. It suggests a tool, a resource and parameters. The decision about whether that exact operation happens belongs to a deterministic component outside the model, which evaluates the initiating principal, the task scope, the resource, the parameters and the policy version.

The Observation and Replanning Loop

Agents act in loops. A tool result, a memory read or an external observation returns, the planner updates its view and proposes the next step. Influence introduced at any point in that loop can shape every later step, which is why an agent chain is not a single decision but a sequence of them.

Tool Selection Versus Tool Output

Manipulating tool selection targets the catalogue and the choice; tool output injection begins after a call was made and concerns the response. Both belong to the agent path and both need separate controls. The dedicated article on tool output injection covers the response side in depth; MCP tool metadata injection covers the pre-invocation catalogue side.

State, Memory and Persistence

Persistence turns a single exposure into a recurring one: content written once can be retrieved and re-enter context long afterwards, possibly for a different user. Memory and context poisoning is a distinct class with its own controls, and it is one of the main reasons an agent finding cannot be closed by ending the session.

The Multi-Agent Boundary

When an agent delegates to a peer or sub-agent, the response is an observation like any other. It does not become authoritative because it came from an internal component, and the calling agent cannot assume the callee applied the same provenance and authorization rules.

The minimum expectation in a multi-agent setup is that each agent keeps its own identity, its own task-scoped authorization and its own logging, and that a downstream service re-authorizes the request rather than trusting the orchestration layer.

The Agent Injection Success Chain

1. 01
   Controlled input or source

   An attacker or user controls a direct input or an external source the agent will consult.

2. 02
   Content reaches agent context

   The material is fetched, retrieved or returned and assembled into model-visible context.

3. 03
   Plan is influenced

   The planner's interpretation, goal framing or proposed step changes measurably.

4. 04
   Relevant capability exists

   A tool or permission that could produce the intended effect is actually available.

5. 05
   Action reaches authorization

   A concrete proposal with resource and parameters is submitted to the deciding control.

6. 06
   Policy fails or is overbroad

   The decision permits the action, because no rule covers it or the scope is too wide.

7. 07
   Action executes

   The operation runs against the real resource with the granted capability.

8. 08
   Security-relevant effect

   Unauthorized access, modification, transmission or persistence actually occurs.

In a multi-step run, each observation, replanning step and action is its own instance of the later stages. A chain can be broken at any one of them, and it can be broken repeatedly.

Competing Constraints

Each deterministic constraint cuts the chain at a different depth. When an early constraint holds, there may be no model exposure at all; when a late one holds, influence is observable but no security-relevant effect occurs. That difference is the whole point of layered control and should be recorded rather than averaged away.

Authorized Offensive Assessment

Agent testing belongs in an authorized engagement with a written scope, a non-production environment or clearly bounded permissions, synthetic data and reversible effects. The purpose is to learn which gate holds, not to demonstrate that a model can be influenced.

Worked Scenario

A synthetic internal operations agent is asked to analyse a support issue and, if appropriate, update the corresponding ticket. Its task-scoped capabilities are: read the issue and its comments, read the linked knowledge article, and update the status and summary field of that specific ticket.

Authorization Architecture

1. 01
   Unique agent identity

   A lifecycle-managed identity with an accountable owner or sponsor, distinct from any human account.

2. 02
   Preserved initiating principal

   The identity that started the task travels with the request and is visible to every decision point.

3. 03
   Task-scoped authorization

   Permissions are bound to the current task, not to the agent in general.

4. 04
   Just-in-time entitlement

   Short-lived, narrowly scoped credentials issued for a specific operation instead of standing access.

5. 05
   Per-tool and per-action allowlists

   Explicit policy for which tools and which operations are available in this task type.

6. 06
   Exact binding

   The decision covers the concrete action, resource, target and parameters, not a general capability.

7. 07
   Downstream re-authorization

   The called service authorizes independently; orchestrator approval alone is not sufficient.

8. 08
   Step-up and human approval

   Irreversible, high-impact or externally visible actions require an approval bound to the exact operation.

9. 09
   Re-authorization on change

   Any change of parameters, target or state between decision and execution triggers a new decision.

10. 10
    Fast revocation

    Entitlements, tokens and sessions can be invalidated immediately, with a working kill switch for the agent.

These expectations follow the published least-privilege and shared-responsibility guidance for AI agents: per-tool least privilege, per-action authorization, human-in-the-loop gates for consequential operations, sandboxing and egress control, memory isolation and auditing.

Information Flow and Egress

The dangerous combination is sensitive context plus an attacker-influenced destination. As long as the destination set is fixed by policy, an influenced plan cannot turn reachable data into transmitted data.

Detection and Telemetry

Useful signals include goal drift, plan drift, tool-chain drift, scope expansion, a newly appearing destination, repeated denied actions, attempted permission changes, cross-system chaining, mismatch between proposal and executed operation, and unexpected memory writes.

Detection Limitations

Prompt-injection classifiers, guardrail models and heuristic filters are probabilistic. They produce false negatives on unseen phrasing and false positives on legitimate security or support content, and their behaviour changes with model and prompt updates.

Detection therefore belongs in the monitoring and response layer, where false positives cost investigation time, rather than in the decision path, where false negatives would cost an unauthorized action.

Secure Architecture Patterns

Controlled Testing and Metrics

Each metric needs its own explicit denominator and must be reported separately. A single composite "attack success rate" hides which gate held and makes results incomparable between systems.

Benign task success, or utility, should be tracked as a separate dimension alongside these security measures. AgentDojo is relevant here as an evaluation framework for agents that execute tools over untrusted data, because it keeps benign task utility and security test cases apart instead of collapsing them into one number.

Incident Response

Closing an agent incident requires the same discipline as classifying it: a changed plan, a denied proposal and an executed action are three different outcomes with three different remediations.

Standards and Research Context

OWASP LLM01:2026 defines prompt injection as the mechanism by which inputs alter model behaviour, while LLM03:2026 describes excessive agency as the enabling design risk that allows damaging actions in response to manipulated model output. The OWASP Top 10 for Agentic Applications 2026 names the agent-specific classes referenced throughout this article, including goal hijack, tool misuse, identity and privilege abuse, memory and context poisoning and insecure inter-agent communication. NIST AI 100-2e2025 and the NIST glossary provide the terminology used for indirect prompt injection and resource control.

The Microsoft Agent Framework safety guidance treats content in the tool role as untrusted, because data returned by tools and context providers can originate in external or user-influenced sources. The Zero Trust guidance on least privilege for AI agents and on identity, access and least privilege describes agent identity, scoped and just-in-time entitlements, per-tool and per-action policy, downstream authorization, logging and revocation; the shared responsibility model for AI agents sets out which of those duties belong to the platform and which to the application team. These are product-level recommendations and are cited as such.

On the research side, Greshake et al. established the practical viability of indirect prompt injection against LLM-integrated applications, and AgentDojo provides an evaluation framework for agents executing tools over untrusted data, separating benign task utility from security test cases. Research on the tool boundary, including causal attribution of tool invocations and tool result parsing defenses, is more specific to tool output injection than to the agent loop as a whole. No attack procedures are reproduced here.

The defense area places these controls into the broader architecture for provenance, least privilege, information flow, action control and recovery.

Frequently Asked Questions