MITRE ATT&CK T1698 Indirect Prompt Injection: Detecting Malicious Execution

An AI agent that reads a web page, email, ticket or file can be steered by instructions an attacker planted there, and it then acts with the agent's own permissions. MITRE ATT&CK v20 added T1698 Indirect Prompt Injection to the Execution tactic for SaaS and Windows: adversaries embed prompts in content they expect an agent, copilot or other AI system to retrieve, so that processing it causes unintended behaviour, including unauthorised use of any capability available to the model. NIST's glossary, drawing on NIST AI 100-2e2025, defines it as prompt injection executed through resource control rather than user-provided input. This guide covers the ATT&CK view: why it sits under Execution, the cases its sources describe, detection strategy DET0942, the six mitigations, and how to test them. It is for AI platform, identity and SOC teams. For injection channels and screening in depth, see the Prompt Injection Guide; this page does not repeat it.

Key takeaways

• It is execution through someone else's identity. The injected text runs as tool calls, file writes and API requests made by the agent's credentials, which is why ATT&CK files it under Execution.
• The model is not the control point. ATT&CK's mitigations are all about permissions, authorisation outside the model, segmentation and dedicated agent identities, not better prompts.
• Detection correlates retrieval with action. DET0942 looks for lower-trust content containing instructions followed, in the same agent run, by an action outside the task's authorisation.
• It is happening on the open web. Unit 42 reported in March 2026 hidden instructions on live web pages aimed at ad review, recommendation, payment and destructive actions.
• Pipelines are a target too. In the Cline case, an issue title fed to an AI triage agent in GitHub Actions led to a cache poisoning chain and an unauthorised package release.

What the technique covers

ATT&CK v20 lists T1698 with no sub-techniques. Carriers named in the description are web pages, documents, emails, tickets and code. Its sibling T1699 Direct Prompt Injection (see the MITRE ATT&CK T1699 Direct Prompt Injection guide) covers prompts the adversary types into the AI system themselves; T1698 is the case where the adversary never talks to the model and relies on it reading their content. ATT&CK also notes that indirect injection may be used to impair autonomous defences (T1685.007, a sub-technique of T1685; see the T1685 Disable or Modify Tools Defensive Guide), for example against AI-driven triage or review tools.

The AI-specific counterpart in MITRE ATLAS is AML.T0051.001, the Indirect sub-technique of LLM Prompt Injection; see AML.T0051 LLM Prompt Injection. Use the ATT&CK ID in enterprise detection coverage and the ATLAS ID in AI red team and model risk work.

Cases from ATT&CK's sources and NHI Mgmt Group analysis

ATT&CK v20 records no group or software procedure examples for T1698 yet. Its cited sources and public disclosures show the pattern:

• Web injection in the wild (Unit 42, March 2026): Palo Alto Networks Unit 42 described 12 in-the-wild cases plus an AI ad review bypass first reported in December 2025, where a scam advert page carried hidden text telling the reviewing AI to approve it. Other intents included SEO manipulation of LLM recommendations, steering agents to payment pages, and commands to delete data. Concealment used zero font size, display:none, zero opacity, off-screen positioning, HTML attributes, encoding and JavaScript that assembles text after page load. Unit 42 counted 22 payload techniques and found social engineering framing, such as fake developer-mode authority, in 85.2% of cases.
• AI triage agent in CI (Cline, early 2026): Snyk reported that an AI issue triage workflow, which any GitHub user could trigger, interpolated the issue title into the agent's prompt and gave it shell, write and edit tools. A crafted title could make the agent install a package from an attacker's fork, whose install script then poisoned the shared GitHub Actions cache used by the nightly release workflow and exposed publishing tokens. After the wrong token was revoked, an unauthorised [email protected] was published on 17 February 2026 and was live for about eight hours. The pipeline side of this chain is covered in MITRE ATT&CK T1677 Poisoned Pipeline Execution.
• Email to copilot (EchoLeak, 2025): a crafted email was later retrieved by Microsoft 365 Copilot as context, and its instructions caused internal data to be placed in a URL the browser fetched automatically. Microsoft fixed it server-side as CVE-2025-32711 and reported no exploitation in the wild. See the EchoLeak analysis.
• Calendar invite to assistant (January 2026): Miggo Security showed instructions in an invite description causing Gemini to summarise a user's private meetings into a new event the attacker could read. Google mitigated it. See the Gemini calendar prompt injection analysis.

Where identity fits

An agent that reads untrusted content and acts on it is a non-human identity whose effective permissions are borrowed by whoever wrote that content. Two of ATT&CK's mitigations are identity controls: M1018 asks for dedicated identities for AI agents with minimum permissions and says retrieved content must not change the agent's authorisation context, and M1026 asks that agents processing untrusted content do not automatically exercise privileged permissions. In the Cline case, the damage path ran through publishing tokens that were shared between nightly and production releases. See the Agent Identity and Access Guide and the AI Agent Authorisation Guide.

What to detect and where

ATT&CK v20.1 publishes detection strategy DET0942, Retrieved Instruction with Unauthorized Agent Action, with analytic AN2293 for SaaS. It correlates four things: where content came from, evidence that it contained instructions, the operation that followed, and whether that operation was authorised for the original task. Its example log source is Amazon Bedrock agent traces (knowledge base lookup input and action group invocation input, under data component DC0038 Application Log Content). Its tunable elements are worth adopting as design inputs:

NHI Mgmt Group recommends these practical signals alongside DET0942:

• Tool calls the task did not need: a summarisation run that sends mail, writes files, creates events or calls payment APIs.
• New egress from agent runtimes: requests to domains never seen before, or URLs carrying long encoded query strings, right after retrieval.
• Agent identity anomalies: the agent's service principal or OAuth client accessing resources outside its baseline, in identity provider and cloud audit logs.
• Hidden content in retrieved material: HTML with invisible text, zero-width characters or encoded blocks, logged at ingestion for later correlation.

Correlation depends on a trace ID that follows a request from retrieval to tool call. If your agent platform cannot emit one, fix that first. See the AI Agent Behaviour Baselining and Anomaly Detection Guide.

Mitigations

ATT&CK v20 maps six mitigations with text written for this technique:

Content screening and model-level defences such as separating untrusted content from instructions and instruction hierarchy, which Unit 42 recommends, reduce the success rate but do not replace these controls.

How to put it in place

1. Inventory agents and their inputs: for each agent, list what untrusted content it reads and what tools and permissions it holds. Agents that do both are the priority.
2. Split read and act: where possible, an agent that reads untrusted content proposes, and a separate, authorised step executes.
3. Enforce outside the model: put a policy check at the tool or API gateway that decides on the agent identity, the task and the action, not the model's text. Start in log-only mode and review what would have been blocked.
4. Restrict egress and data paths: allowlist destinations; block automatic fetching of model-generated URLs and images where the client allows it.
5. Instrument traces: make sure retrieval events and tool calls share a trace ID and reach the SIEM; then build DET0942 style correlations.
6. Roll back safely: keep a kill switch per agent that revokes its tokens without affecting human users. See the AI Agent Kill Switch and Containment Guide.

How to test

• Benign canary instructions: in an authorised test, plant a harmless instruction in a document, email or ticket the agent will read, for example to call a test endpoint, and confirm the gateway blocks it and an alert fires.
• Hidden text variants: repeat with the concealment methods Unit 42 lists, to test ingestion logging.
• Identity scope check: confirm each agent token cannot reach resources outside its role, independent of what the model asks.
• CI agents: confirm that AI workflows triggered by external users have no secrets, no shell and no shared cache with release jobs.

Decision guidance

• Read-only assistants: the main risk is data leaving through links, images or replies; focus on egress control and output rendering.
• Agents with write or payment tools: require out-of-model authorisation and human approval for consequential actions; accept the friction.
• Agents in public-facing workflows (issue triage, support inboxes, web browsing): assume every input is hostile; give them the fewest tools you can.
• Small teams: use the platform's built-in approval and scope settings and keep agents read-only until monitoring exists.

Measurement

• Percentage of agents that both read untrusted content and hold write or privileged permissions.
• Percentage of agent tool calls passing through an independent policy check.
• Agents with dedicated identities and short-lived credentials, against total agents.
• Blocked or flagged content-driven actions per week, and their review time.
• Canary test success rate: planted instructions that were blocked and alerted.

Common failure patterns

• Relying on a classifier: EchoLeak chained bypasses of a prompt injection classifier, link redaction and content security policy.
• Interpolating untrusted text into the prompt of an agent with shell access, as in the Cline triage workflow.
• Shared credentials and caches: one agent's compromise reaches release or production identities.
• Write tools on read tasks: an assistant that only needs to summarise can also create events, send mail or edit files.
• No trace linkage: retrieval and tool call logs exist but cannot be joined, so DET0942 style detection is impossible.

Framework mapping

Practitioner checklist

• Every agent has a dedicated identity with minimum, short-lived permissions.
• Agents that read untrusted content cannot perform privileged actions without separate authorisation.
• Tool and API calls pass a policy check that does not depend on the model's output.
• Agent runtimes have egress allowlists.
• Retrieval events and tool calls share a trace ID and reach the SIEM.
• DET0942 style correlations run for the highest-risk agents.
• AI workflows triggered by outside users hold no secrets and no shell tools.
• Canary injection tests run after every significant agent change.

Standards and references

• MITRE ATT&CK: T1698 Indirect Prompt Injection
• MITRE ATLAS: AML.T0051.001 LLM Prompt Injection, Indirect
• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• NIST CSRC Glossary: Indirect prompt injection
• Palo Alto Networks Unit 42: Fooling AI agents, web-based indirect prompt injection observed in the wild
• Snyk: Cline supply chain attack via prompt injection in GitHub Actions

Related NHI Mgmt Group resources: OWASP LLM Top 10 LLM01 Prompt Injection Guide, Prompt Injection Incident Response Playbook, ATT&CK Execution Tactic Guide, AI Agent Action Approvals and Spending Limits Guide.