How T1698 indirect prompt injection gets an AI agent to act for an attacker
T1698 indirect prompt injection lets an attacker make an AI assistant or agent act on their behalf by hiding instructions in content the agent reads during normal work, such as email, documents, web pages or SaaS records. It shows up in intrusions wherever an agent with tool access processes content that someone outside the organization can write, because the agent may treat embedded text as a request from its user. For a SOC lead, the practical shift is to treat each agent as an execution path that carries its own identity, permissions and logs. This page targets Enterprise ATT&CK v20.0. Before you map controls, confirm the technique's current tactic placement, sub-techniques and detection strategies against the enterprise-attack 20.0 STIX bundle, because ATT&CK v18 replaced detections in technique pages with detection strategies and later releases can rename, deprecate or revoke techniques.
Start with an inventory. List every AI assistant or agent in your environment, the content sources each one reads, and the tools each can call, such as sending mail, editing records, creating tickets or calling APIs. Then decide which combinations are acceptable without a human confirming the action. Here is an illustrative case: an assistant that summarizes shared documents and can also share files on the user's behalf could be steered by text hidden in a document it was asked to summarize, so the file-sharing action should require explicit approval or sit outside the agent's permissions. Ask each vendor, in writing, whether its platform separates instructions from user input and tool results, and what it records for each tool call. Treat the answers as unverified until you test them in your own environment.
The agent acts under whatever identity and scope it was granted, so the control question is what that identity can reach. Review agent service accounts and OAuth grants under the same discipline you apply to people, using the ATT&CK mitigations User Account Management (M1018) and Privileged Account Management (M1026) as the reference points, and remove standing rights the agent does not need for its stated task. Confirm that tool calls are logged with the content source that preceded them, the identity used and the target object, because those three fields let an analyst reconstruct how external content led to an action. The detection logic and response steps follow in the sections below, but the logging gap is best closed now, before an incident forces the question.
Which telemetry reveals indirect prompt injection on Windows and SaaS
This table maps each telemetry signal for indirect prompt injection on Windows and SaaS to its data source, the observable to look for and the open-source collector that gathers it. Treat each row as a hypothesis to test, because the signals depend on which agent and SaaS platforms you run and what they log. The main takeaway is that no single log proves injection, so correlate endpoint process activity with outbound network and SaaS audit events.
| Signal | Data source and component | Open-source collector | What to look for |
|---|---|---|---|
| Agent process spawns an unexpected child process | Process Creation (DC0032) | Wazuh ingesting Sysmon events, or Velociraptor | An assistant or agent runtime launching shells, script interpreters or downloaders it does not normally start |
| Assistant sends data to an external destination after reading a document | Network Connection Creation (DC0082) and Network Traffic Content (DC0085) | Zeek and Suricata on the agent network segment | Outbound sessions from the agent host to destinations outside the allow list shortly after a file or web read |
| Commands run by agent-invoked tools | Command Execution (DC0064) | Velociraptor artifacts or Wazuh command monitoring | Tool invocations whose arguments contain content copied from untrusted input or unusual encoded text |
| Agent writes new files to staging or startup locations | File Creation (DC0039) | Wazuh file integrity monitoring or Velociraptor hunts | New files created by the agent process in temporary, user profile or startup paths |
| SaaS assistant reads untrusted content, then shares or sends it | Application Log Content (DC0038) | SaaS audit log forwarding into Wazuh or Security Onion, confirm the export method with each vendor | A content retrieval event followed by an email, share or connector action within the same session |
| Connector or plugin scope changes | Application Log Content (DC0038) | Wazuh decoders on SaaS audit feeds | New integrations, expanded permissions or new mail forwarding or sharing rules created without a matching user request |
| Actions taken without a matching user prompt | Application Log Content (DC0038) | SIEM correlation in Wazuh or Security Onion | Tool calls in a session that cannot be traced to a user instruction, so confirm your platform logs prompts and tool calls |
Detection ideas for T1698 that SOC teams can build with open-source tools
The four cards below share one premise: an assistant that reads untrusted content can be steered into doing something new on the host or in SaaS. Each idea pairs a telemetry source with a baseline, so an alert means a deviation from known agent behavior. Treat every rule as a starting hypothesis that needs tuning in your own environment.
Windows process lineage from assistants
Track child processes started by AI assistant, agent runtime or browser-integrated helper processes on Windows. Process Creation events (DC0032) with parent image, child image, command line and user context show when an agent launches a shell, script host or downloader it does not normally use. Alert when such a child appears shortly after the agent opens a document or web page. Map the rule to ATT&CK version 20.0. Tune it by allow-listing approved tool invocations per agent. Expect false positives from developer tooling, package managers and agent updates.
SaaS read-then-write audit sequence
Correlate SaaS audit events in which an assistant or integration reads external or untrusted content, then performs a privileged write within a short window, such as sharing a file, changing a permission, sending mail or altering a configuration. Application Log Content (DC0038) is the main telemetry. Agree the correlation window and the list of privileged actions with the data owner, start narrow and widen after review. Expect false positives from summarize-then-share workflows, scheduled automation and administrators who use assistants.
Outbound connections from agent hosts
Baseline the destinations contacted by hosts that run agents, then alert on first-seen domains, unusual ports or unexpected outbound transfers originating from agent processes. Network Connection Creation (DC0082) and Network Traffic Content (DC0085) from Zeek or Suricata supply the signal. Enrich destinations with domain age and reputation from your threat intelligence feed, and set the new-destination threshold during the baseline period. Expect false positives from vendor API endpoints added by updates, CDN address changes and newly onboarded SaaS tools.
Sigma rules and ATT&CK 20.0 validation
Write the three detections above as Sigma rules, record ATT&CK version 20.0 in each rule's metadata, and keep the version field current when MITRE publishes later releases. Validate every rule in your local SIEM against replayed benign activity and staged test events before promotion, and confirm that your pipeline exposes the field names the rule uses. Releases can rename, deprecate or revoke techniques, so recheck mappings after each update. Review the STIX data repository when you refresh mappings.
Tuning T1698 detections so they fire on injection and not on normal assistant use
Tune T1698 detections by first learning what normal assistant behavior looks like for each user group and each application. Group users by role, then record which agents, connectors and data sources each group uses, such as mailboxes, document stores, ticket queues and web retrieval. Application Log Content (DC0038) and Network Traffic Content (DC0085) show which sources an agent reads and where its outbound requests go. Build the baseline from a period you have already reviewed, and confirm the window length with the owners of each application. An alert that flags a read from a source outside its group's profile is far more useful than a generic alert on every external fetch.
Separate sanctioned automation from unexpected tool use by registering every scheduled summarization job, integration service account and approved agent identity in an inventory. Tie each tool invocation to one of those identities, so the detection can ask whether a call matches the job's documented source and destination. Allowlist approved sources and destinations explicitly, and keep the list owned by a named person for each application. Handle false positives from legitimate summarization or integration jobs by suppressing on the combination of job identity, expected source and expected destination. A suppression keyed only to a user or a broad domain would also hide a compromised job, so keep the match narrow and document why each rule exists.
Set a review cadence for tuning and treat every change as a detection change. Review suppressions, allowlist entries and baselines on a fixed schedule agreed with your security operations and application owners, and again after any change to a model, connector, prompt template or tool permission. Record each alert outcome as a true or false positive so the tuning history can be audited. Map detections to the ATT&CK version you target, such as Enterprise ATT&CK 20.0, because releases can rename or deprecate techniques (MITRE ATT&CK updates). Rehearse tuning changes in a private cyber range with benign test content before they reach production.
How to confirm the T1698 detection fires before you rely on it
This sequence proves, in a private lab or cyber range, that the telemetry for indirect prompt injection reaches your SIEM, that the alert logic fires on the scenario you defined, and that you know the detection time, fidelity and gaps before any production reliance. It produces a dated evidence record tied to the ATT&CK version and rule version under test.
Define the emulation scenario and expected telemetry
The detection owner and the security engineer write down one indirect prompt injection scenario for the assistant under test, such as untrusted content entering through a document or web page that the assistant reads on a user's behalf. For each step of the scenario, they list the telemetry expected to appear, such as application log content from the assistant platform, network connection records to external destinations and any file creation events on the endpoint. The step is done when the expected events are written in a table that the rule will be checked against. Record the ATT&CK version (for example, the version you target from the MITRE updates page) and the detection rule version in the same record.
Prepare an isolated test assistant
The platform team stands up a test assistant inside the private range, connected only to synthetic data and to a test identity with the same permission model as the production role being modeled. No production data, production credentials or production connectors are attached. The team confirms the test environment cannot reach production systems or external networks beyond what the scenario requires. The step is done when a network and identity review signs off the isolation and that sign-off is stored with the evidence record.
Run the scripted scenario in the range
A tester, working from the written scenario and not from improvised content, places the untrusted content in a location the test assistant will ingest and triggers the normal user workflow that causes the assistant to process it. The run is recorded with timestamps, the exact content version used and the account that performed each action, so the event can be matched later. Keep the scenario content in version control so the run can be repeated. The step is done when the run log shows the scenario completed end to end, including any step where the assistant did not behave as expected.
Confirm expected events reach the SIEM
The security engineer searches the SIEM for each telemetry source listed in step one, filtered by the run's timestamps and test identity. They check that every expected event arrived, that fields such as source, destination, user and process are populated and that ingestion delay is noted. Missing or malformed events are logged as collection gaps, not as detection failures, and routed to the data pipeline owner. The step is done when a per-source table shows received, missing or partial status for each expected event.
Check alert logic and thresholds
The detection engineer compares the rule's conditions against the observed events and asks whether the alert would have fired on them. They test the threshold and correlation window with the recorded events, then run one variant that changes a single non-malicious detail to see whether the rule is overly sensitive. Benign assistant activity from the same test account is included to measure false positives. The step is done when the rule has been reviewed against both the malicious run and the benign baseline, and any tuning is recorded as a new rule version.
Record detection time, fidelity and gaps
The analyst measures the interval between the first scenario event and the alert, judges whether the alert contains enough context to triage and lists every technique behavior the rule did not cover. Fidelity is recorded as the share of alerts that the analyst judged to be true activity during the run and the benign baseline. Gaps are written as open items with an owner. The step is done when the evidence record contains detection time, alert content review, fidelity result and a gap register, and the record names the ATT&CK version and rule version tested.
Decide whether the detection is ready for reliance
The detection owner, the incident response lead and the platform owner review the evidence record together and decide one of three outcomes: ready with stated limits, needs tuning and retest, or not ready. A ready decision lists the scenarios it covers and the ones it does not, so that responders know what the alert can and cannot be trusted to show. The step is done when the decision, its limits and the sign-off are stored with the record, and the record is scheduled for re-validation after any ATT&CK version change or rule change.
Preventive controls that reduce T1698 exposure
These controls limit what an injected instruction can achieve once an agent reads untrusted content. They work on the agent's identity, its privileges and the tools it can call, so a successful injection lands in a narrow space. Map each control to the ATT&CK version you target and confirm the mapping in the bundle before you cite it.
User account management (M1018)
Give each AI agent a dedicated identity with a named owner, a documented purpose and a scheduled access review. Disable idle or orphaned agent accounts so that no forgotten identity remains usable. For T1698, check whether each agent account can read mail, documents or tickets it does not need for its task. An injected instruction carried in a document inherits whatever that identity can reach, so keep each agent account scoped to one workflow.
Privileged account management (M1026)
Keep administrator rights, write-scoped API tokens and cloud admin roles out of agent identities unless a specific task requires them. Where elevation is needed, grant it just in time for a bounded window and log every elevated action. Store agent credentials in a secrets manager with rotation so a leaked token has a short life. Review whether any agent can change its own permissions, create accounts or alter approval settings, because those are the actions an injected instruction would most want to reach.
Least-privilege tool access for agents
Treat every tool an agent can call as a capability granted on purpose. Use an allowlist of tools for each workflow, scope each tool to read or write on specific resources, and require human approval for actions that send data outside the organization, delete records or change configuration. Restrict outbound network destinations for the agent runtime so retrieved content has fewer routes to unapproved hosts. Illustrative: an agent that summarizes support tickets needs read access to the queue, not the ability to send email to customers.
User training as a supporting control
ATT&CK lists User Training (M1017) as a mitigation for Execution techniques. Confirm in the enterprise-attack 20.0 bundle that it maps to T1698 before citing it for this technique. Training helps staff understand that documents, web pages and emails can carry instructions aimed at an assistant, and that an unexpected agent request to share data or change settings should be reported. Treat training as a supporting control only, since it does not stop an agent with broad access from following an injected instruction.
What to do in the first hour after a T1698 alert
Start by deciding whether the alert reflects injected instructions or benign content, because that decision determines whether this is a security incident or a tuning event. Pull the source document, mailbox item, ticket, or record that the agent read in the flagged session, and compare the text that reached the model with what the source owner expects it to contain. Identify the agent session identifier, the time window, and the user or service identity the agent ran under. Keep this triage factual: record what the content said, which tool calls followed it, and whether any of those calls changed data, sent messages, or accessed records outside the task the user requested. Confirm these details with the platform team rather than assuming the logging schema, since field names differ between agent frameworks and SaaS connectors.
Next, review every action the agent took after it read the suspicious content. Map each tool invocation to the account or token it used, and check whether that identity holds more privilege than the task required. Where the agent acted under a shared service account or a broadly scoped OAuth grant, treat the whole grant as in scope until you have confirmed otherwise. Contain the session by stopping or suspending it, disabling the affected connector or agent identity if other sessions may be exposed, and revoking tool tokens and refresh tokens tied to the session. Expect that revocation will break legitimate workflows, so agree the impact with the application owner in advance. Preserve logs from the agent platform, the SaaS audit trail, identity provider sign-in events, and any retrieval or vector store entries before retention rules roll them over.
Escalate in parallel rather than in sequence. Notify the application owner so they can judge business impact and confirm which downstream records may be wrong. Open an incident record with the incident response team and give them the session identifier, source reference, preserved log locations, and the list of tools the agent could reach. Ask the incident response team to decide whether the content source is a third-party input that needs wider review. Once the incident is contained, document what the content looked like, which control should have caught it, and which signal was missing or noisy. Feed those notes back into detection tuning, such as adjusting the thresholds in the detection analytics, adding the affected tool to the monitored set, or narrowing the permissions that the agent identity holds.
How to rehearse T1698 detection and response in a private cyber range
Build a Windows host in the private range that runs a locally deployed AI agent with access to synthetic documents, mailboxes and a set of permitted tools. Populate the host with fake files and fake records only, and place a Wazuh agent or equivalent collector on it so process, command and file telemetry reaches the SIEM. The blue team receives injects describing unusual agent behavior in general terms, such as an agent taking an action its task did not request, rather than any technical payload. Good detection means an analyst sees a correlated alert from the host telemetry and the agent's action log within the time window set by the exercise plan, and can name the process chain and the data touched. Good response means the analyst isolates the agent session, revokes its tool tokens, preserves the logs and scopes which synthetic files were read or changed.
- Telemetry coverage: confirm that Process Creation, Command Execution and File Creation events reach the SIEM from the host before the exercise starts.
- Agent action logging: verify that the agent records each tool call with a timestamp and identity so analysts can tie actions to a session.
- Time to alert: record the elapsed time from the first inject to the first analyst-confirmed alert.
- Scoping accuracy: score whether the team lists every synthetic file and tool the agent touched.
- Containment quality: check that the host is isolated without destroying evidence and that the agent's credentials are rotated.
Before the first run, confirm with your SIEM and agent vendors which log fields are available in your version, since field names differ between releases.
Create a SaaS assistant tenant in a sandbox subscription with synthetic mailboxes, shared documents and connectors the assistant is allowed to use. The range should capture the vendor's audit and activity logs for the assistant, along with sign-in and connector events, and forward them to the SIEM. Injects arrive as content the assistant processes, such as a synthetic document with instructions that do not match the user's request. Good detection means the analyst links an assistant action to the content that preceded it, recognizes the connector or data scope involved, and raises an alert based on the mismatch between requested and performed actions. Good response means the team suspends the connector or the assistant's access, reviews sharing and mail rules created during the window, and restores affected synthetic objects from the range's known-good state.
- Log availability: confirm which assistant, connector and sign-in events the tenant exposes and how long they are retained.
- Content lineage: check whether analysts can trace an assistant action back to the document or message that was processed.
- Scope review: score whether the team identifies every connector and shared object the assistant touched.
- Access restriction: measure how quickly the team suspends the assistant's access without disrupting unrelated synthetic users.
- Recovery check: verify that restored objects match the known-good baseline.
Confirm with the tenant's administrators which logging features are included in your licensing tier, because log coverage for assistant activity can vary.
The combined scenario runs the Windows host and the SaaS tenant in one exercise, so the blue team must correlate an endpoint signal with a cloud signal. The inject plan starts with content in the SaaS tenant that causes the assistant to request an action, then shows the Windows agent carrying out a related step. Analysts must connect the two environments through shared identifiers such as session IDs, user accounts and timestamps. Scoring should reward the team for building a single timeline across both systems and for deciding containment order, such as suspending the cloud connector before isolating the host. Facilitators record decision points so the after-action review can compare what the team did against the plan.
- Cross-environment correlation: score whether analysts link the SaaS event and the endpoint event to one incident.
- Decision sequencing: evaluate whether containment steps are ordered to limit further actions by the agent.
- Timeline quality: check that the timeline records detection, scoping, containment and recovery times in one place.
- Communication: assess whether the incident lead briefs the compliance and application owners with accurate scope.
- Lessons captured: require a written list of detection gaps with an owner for each.
Ask the facilitator to mark every injected event with its ATT&CK version and detection strategy so results can be compared between runs.
Questions SOC leads and detection engineers ask about T1698
How is indirect prompt injection different from direct prompt injection for detection?
The difference is where the malicious instruction enters the workflow. Direct prompt injection comes from the user typing into the assistant, while indirect prompt injection sits inside content the assistant reads on the user's behalf, such as an email, shared document, web page or support ticket. That shifts detection from user input to content ingestion. Look for the assistant retrieving external or untrusted content, followed by tool or connector actions that do not match the user's request. Keep the two techniques mapped separately so coverage gaps are visible. Confirm the current definitions for T1698 and T1699 in the ATT&CK version your team targets before writing rules.
Which logs should we forward first from a SaaS AI assistant?
Start with the logs that show what the assistant read and what it did, then add identity context. In most environments that means:
- Activity or audit logs for tool, plugin and connector invocations made by the assistant
- Content access events for the mailboxes, sites or files the assistant retrieved
- Sign-in and administrative change events for the account and connectors it uses
Ask each vendor which of these exist, how long they are retained, whether they include content or only metadata, and how they are exported to your SIEM. Some platforms expose agent action logs only on higher tiers or through an API, so confirm this in writing before you design the pipeline.
How can we test detection rules without production data?
Build synthetic test content in a private cyber range and replay it through the same log pipeline your production uses. The content should imitate the pattern the rule targets, with an agreed marker so every test has a known expected result. Record the events each test produces, then check whether the rule fires, how long it takes, and what the analyst sees. Sigma rules can also be validated against sample events outside the SIEM, which makes regression testing easier after each change. Keep test data clearly labeled, separate from client records, and reviewed by the data owner before any run. This is illustrative of the approach, not a substitute for testing against your own log schema.
How do we map detections to the ATT&CK version we use?
Record the ATT&CK version in every rule's metadata and in the coverage map, then review that map whenever MITRE publishes a new release. MITRE's updates pages list renamed, deprecated or revoked techniques, and a mapping that names no version becomes hard to audit. The current reference bundle used for this page is Enterprise ATT&CK 20.0, which MITRE published on 2026-10-13. When you move to a new version, compare the technique IDs, detection strategies and data component references against your rules, then log each change. Confirm with your own tooling how it reads the STIX bundle for the version you choose.
What should we do if a SaaS vendor does not expose agent action logs?
Treat the gap as a documented risk decision and reduce what the assistant can reach until visibility improves. Options include narrowing the connectors and data sources the assistant can read, applying least privilege to its service account, and routing tool calls through a gateway or proxy you control so that actions can be logged. Add the gap to the contract or procurement questions for the next renewal and ask for log export as a requirement. Record the residual risk, the owner who accepted it and the review date, since auditors will ask how the gap was handled. Compensating controls should be tested in your environment rather than assumed to work.
Can our own team run this detection program, or do we need a partner?
Your team can run it if it has detection engineering skills, administrative access to the SaaS platforms in scope, and time to maintain rules after each platform change. Most organizations split ownership between the vendor, the platform team that operates the SIEM and the SOC that triages alerts. A partner can help with a fixed-scope piece, such as implementing log pipelines, writing and testing rules, or running a cyber range rehearsal. DeployOpen works on fixed scopes agreed in writing before work starts, and offers retainers for ongoing tuning and testing. Ask any provider to name who maintains each rule after handover.
What does a cyber range rehearsal of this detection actually prove?
A rehearsal shows whether the detection, the triage steps and the response actions work together under realistic pressure, using your own logs and tooling. It should confirm that the expected alert fires, that the analyst has enough context to decide, and that the playbook can disable or restrict the affected connector without breaking unrelated workflows. It should also confirm that evidence is captured in a form your incident process and auditors can use. A rehearsal does not prove that every future variant will be caught, so record what was tested and what was not. Agree the scenarios, success criteria and environment in writing before the exercise.
How DeployOpen builds T1698 detections, purple team exercises and range scenarios
DeployOpen approaches T1698 Indirect prompt injection as a written, fixed-scope engagement that runs inside your own infrastructure. The work turns the detection logic for this technique into telemetry you can monitor, test in a private cyber range and hand over with documentation your teams can maintain.
How we scope
- Confirm which Windows hosts, SaaS applications and identity sources fall inside the written scope for T1698 Indirect prompt injection.
- Agree which data components, such as Process Creation and Application Log Content, are available in your environment before detection work begins.
- Record the ATT&CK version the detection mapping targets, so later technique changes can be traced to a specific release.
How we build
- Draft detection logic in plain language, then express it in open-source rule formats such as Sigma for your SIEM and log pipeline.
- Map alerts to the User Account Management and Privileged Account Management mitigations, and document where each control is enforced or only partly covered.
- Test detection content against replayed telemetry from a private cyber range before any rule is promoted to production monitoring.
How we hand over
- Deliver rule files, data source requirements, triage notes and a response runbook written for your analysts, with the owners of each step named.
- Run a purple team exercise in the cyber range so your blue team can observe detections firing and record gaps in coverage or logging.
- Provide a tuning and validation record that shows which tests were run, what fired, what was missed and what changed as a result.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing for T1698 detections are available as a retainer, if your monitoring needs continue after handover.
- Ask us to confirm in the quote how detection content will be updated when a new ATT&CK version changes or deprecates related techniques.
