Loading interactive filters…

1200KM / simulation

T1698 Indirect Prompt Injection — Attack Simulation

Adversaries may deliver malicious prompts to an LLM indirectly by embedding the prompts in content that the adversary expects may be processed by an LLM. These prompts can be included in web pages, documents, emails, tickets, code, or other sources that an agent, copilot, or other AI system may retrieve and process. When an LLM processes this content, the embedded instructions may cause the system to perform unintended behaviors. Adversaries may…

Complete technique description

Adversaries may deliver malicious prompts to an LLM indirectly by embedding the prompts in content that the adversary expects may be processed by an LLM.[NIST indirect prompt injection] These prompts can be included in web pages,[Palo Alto Indirect Prompt Injection ITW] documents, emails, tickets,[Snyk Indirect Prompt Injection] code, or other sources that an agent, copilot, or other AI system may retrieve and process. When an LLM processes this content, the embedded instructions may cause the system to perform unintended behaviors.[GTIG AI Threats Sep 2026]

Adversaries may use indirect prompt injection to Impair Autonomous Defenses, and for unauthorized execution of any capabilities available to the LLM.

Official technique definition · Open in the interactive matrix

Detection telemetry and configuration

These contracts are selected through exact technique-to-data-component relationships or explicitly labelled planning overrides. Configure a collector at the relevant observation point; a telemetry name alone is not coverage.

No source-mapped collection contract is available for T1698. Read the technique-specific MITRE guidance below to determine what is observable and which party controls that data.

Detection rules and analytic guidance

Open the dedicated detection workspace · Existing query engineering

Source rule directory and observation requirements

No exact-tagged Sigma source rule was imported. This does not establish that the technique is undetectable; the MITRE guidance and collection requirements remain relevant.

Before treating a rule as coverage

Read the actual condition and logsource; identify attacker-side, victim-side or third-party visibility.
Map native sensor fields, parse times and identities, then compile for the selected backend.
Replay a behavior-positive case, a normal control, an authorized look-alike and a missing-telemetry case.
Record matches and misses with rule version and source events. No match is inconclusive when required telemetry is absent.

Anomaly-based detection

No exact technique-specific Atlas model is present for T1698 in the selected source snapshot. The following is a design worksheet, not a newly validated model.

Anomaly engineering worksheet

Start from the exact analytic above. The collection-specific lenses below are analyst recommendations; they do not assert that an arbitrary statistical deviation detects this technique.

Resolve the observation point before defining measurable features. Private attacker preparation can be outside victim visibility.

Define an entity/peer group and feature; exclude the evaluation period from baseline training.
Use representative normal and maintenance activity. Do not invent a production threshold from a synthetic example.
Evaluate held-out behavior-positive and benign cases; measure false positives, misses and telemetry loss separately.
Keep abnormality separate from maliciousness. Correlate with the behavior-specific source evidence.

Anomaly Detection Atlas · Baseline, validation and blind spots

Attack tools and documented software

No reviewed lab-tool association is selected for this exact technique. This is a curation gap, not a statement that no tool can implement the behavior.

Simulation design and documented procedures

Atomic evidence: no compatible candidate in this snapshot. Live lab status: not run for these imported procedures.

Use disposable lab hosts and test accounts, explicit target allowlists, a clean snapshot, bounded egress and a restore plan. Review every candidate and dependency before any execution.

No compatible Atomic procedure is present in this pinned evidence set. Technical feasibility has not been ruled out. A custom procedure must define the behavior, target, collection point, success observable and rollback before execution.

Technique-specific experiment contract

Choose one procedure implementing T1698 Indirect Prompt Injection; identify the observable behavior in the source definition, not just its tactic.
Record exact target, tool/version, inputs, privileges, network limits and approval. Never run an imported default target automatically.
Enable the collection sources above and verify a benign baseline reaches the detector.
Run only the approved isolated scenario; capture native events and an independent behavior observable.
Evaluate the exact rule/model, restore the lab, and preserve configuration, event hashes, alerts, controls and misses.

Synthetic logs and offline contract check

No synthetic event is invented when the relevant collection point is unresolved. Download the workbook and define the observable source with the system owner first.

Validation status and remaining work

Source identity: Joined by exact technique/object IDs against hash-pinned sources.
Collection fixture: Not supplied because no collection contract is available.
Native telemetry / backend / real attack: Not validated for these imported procedures. Source fidelity and page tests cannot establish sensor or detector effectiveness.

All-page audit and evidence inventory · This page’s machine-readable workbook

Sources and evidence boundaries

Pinned MITRE STIX source · SHA-256 81113ba98afa2928f3dcff62022539f7ce30c315c32e14422f11ff95ce534352. Definition and procedure context are reproduced from this snapshot, not independently re-investigated incidents.

Source-linked mitigations

M1017 User Training
Train users and administrators to treat content processed by AI agents as potentially adversarial and to require independent validation before approving sensitive actions proposed as a result of externally sourced content.
M1018 User Account Management
Use dedicated identities for AI agents and restrict their permissions to the minimum resources and actions required by the approved workflow. Do not allow retrieved content to change the authorization context associated with the agent.
M1022 Restrict File and Directory Permissions
Restrict AI agents to files, directories, repositories, and content stores required for their approved workflows. Limit write access separately from read access where possible to reduce the actions available following successful indirect prompt injection.
M1026 Privileged Account Management
Prevent AI agents processing untrusted or externally controlled content from automatically exercising privileged permissions. Require additional authorization for sensitive operations derived from retrieved content.
M1030 Network Segmentation
Restrict network resources and external destinations accessible to AI agents that process untrusted content. Limit outbound communication and access to unrelated internal services to reduce exfiltration and lateral effects following successful injection.
M1038 Execution Prevention
Prevent instructions contained in retrieved or externally supplied content from independently authorizing consequential agent actions. Require tool/API requests derived from external content to satisfy authorization and policy controls independent of the model-generated decision.

Connected ecosystem references

Linked tags

No Atomic candidate in snapshot technique source_mapping_gap

Detection and collection

T1698 detection workspace

No reviewed association in this snapshot.

Existing research

Threat Matrix: knowledge routes, evidence and actor context

Pinned research references. No browser attack runner or production-validated detector is asserted. Imported procedures remain unvalidated; any bounded lab evidence has its own scope. ATT&CK / Atomic provenance · Detection provenance.