How T1699 direct prompt injection shows up in SaaS and Windows estates
T1699 Direct prompt injection is an ATT&CK Enterprise technique, and in ATT&CK Enterprise 20.0 it sits under the Execution tactic (TA0002), which MITRE defines as the adversary trying to run malicious code or instructions on a system. It matters here because a language model interprets instructions. When an adversary who controls text reaching a model-facing input can get the model to act on that text, the execution step happens inside an assistant, copilot or agent. For a SOC lead whose AI-enabled features are reaching users, the instruction path deserves the same monitoring attention as any other execution path.
In intrusions, the pattern is that attacker-influenced text reaches a model through a field the user or a connected tool supplies, and the model then takes actions with permissions the assistant already holds. On Windows, this can involve desktop assistants, browser-embedded copilots or local agents that invoke scripts, files or applications on the endpoint. In SaaS estates, the same pattern appears in assistants connected to mail, documents, tickets or code repositories, where the action is an API call made under a user or service identity. The SOC lead should decide which of these features are in scope, which identities they run under, and which logs record the actions the assistant takes.
Before building detections, confirm the current T1699 definition, its scope and its mapped data components in the ATT&CK version you target. The current release is 20.0, and MITRE's update notes make clear that releases can rename, deprecate or revoke techniques, so a mapping written against an earlier version may drift. Review the ATT&CK updates page at each planned rollout. Also confirm with your SaaS and endpoint vendors which assistant actions are written to audit logs, because detection depends on those records existing in the first place.
Which telemetry reveals direct prompt injection and which open-source tool collects it
This table maps each ATT&CK data component relevant to T1699 to the signal a defender should look for and the open-source collector that gathers it. Read it as a starting point, because what a SaaS AI feature records about model inputs is set by the vendor, so confirm that before relying on any row.
| Data component | Signal to look for | Open-source collector and notes |
|---|---|---|
| Application Log Content (DC0038) from SaaS audit logs | Requests to an AI assistant feature by an unexpected user or service account, or unusual spikes in prompts that contain instruction-like text such as attempts to override system rules | Wazuh log collection or a SaaS log export into Security Onion. Confirm with the vendor whether prompt and response text is logged at all, and at what detail. |
| Application Log Content (DC0038) from AI feature logs | Prompts that reference internal documents, credentials, or tool names the user should not know, and sudden changes in tool or plugin invocation patterns | Wazuh with a custom decoder for the feature's log format. Confirm retention and whether logs are redacted before storage. |
| Process Creation (DC0032) on Windows hosts | An AI desktop client or local agent launching child processes such as shells or script hosts after handling user text | Wazuh Sysmon-based process events or Velociraptor artifacts for process history. Confirm the client is not launching processes only through a vendor-managed sandbox that hides them. |
| Command Execution (DC0064) on Windows hosts | Command lines issued by an agent that include arguments built from free-form user or retrieved text | Velociraptor hunts over command line history and Wazuh rules on command line content. Expect false positives from legitimate automation. |
| Network Connection Creation (DC0082) from assistant tooling | Outbound connections from an agent process to destinations that are not on its approved list, shortly after a prompt is processed | Zeek connection logs and Suricata alerts in Security Onion, correlated with host process data. Encrypted traffic limits payload visibility. |
| Network Traffic Content (DC0085) for assistant tooling | Plaintext or proxied content showing instruction-like phrases in requests to AI endpoints, where TLS inspection is in place | Suricata rules and Zeek content extraction at a TLS-inspecting proxy. Confirm legal and privacy approval for inspection before deployment. |
Detection logic for T1699 that a detection engineer can write and tune
The four ideas below share one premise: direct prompt injection shows up as a change in what an AI-enabled feature does, not as a malware signature. Each card names the telemetry to watch, the baseline to tune against, and the benign activity that will trigger it first. Write each rule in Sigma for portability, and name the ATT&CK version it targets in the rule metadata.
Unexpected child process from an assistant
On Windows, an AI desktop helper or a browser-hosted assistant launching a shell, scripting host or command interpreter is a strong signal that model output was turned into execution. Build the rule on Process Creation events where the parent image belongs to the assistant and the child is an interpreter or LOLBin you do not expect from that application. Baseline each assistant for two to four weeks before alerting. Expect false positives from approved automation plugins, developer testing of agent tools and IT scripts that run under the same service account. Allowlist by signed path and parent-child pair, not by the application name alone.
Assistant actions outside the user's role
In SaaS platforms, a copilot or in-app assistant that performs actions the signed-in user would not normally perform is the core indicator of T1699 when the injected instruction came from user-supplied content. Correlate Application Log Content from the SaaS audit trail with the user's role, the actor identity recorded for the action, and the action type, such as bulk export, permission change or sharing. Alert when an assistant-originated action falls outside that user's historical action set. Expect noise from administrators running approved bulk jobs and from integrations that act on behalf of users. Confirm with each SaaS vendor which audit fields distinguish assistant-initiated actions from manual ones.
Spike in instruction-like input
A sudden rise in prompts that contain imperative phrases aimed at the model, such as requests to ignore prior rules, reveal hidden configuration or call a tool, points to an attempt to steer a model-facing feature. Measure the rate of flagged inputs per user, per form or per API client against a rolling baseline, and alert on a sustained increase rather than single hits. Pair the rule with Network Traffic Content on the model gateway where your platform exposes it. Expect false positives from security teams testing their own guardrails, from developers writing system prompts and from support staff pasting customer text. Tag test accounts so that they are excluded from production alerting.
Tool calls with unusual parameters
When a model-facing feature invokes tools, a call whose parameters do not match the tool's normal shape, such as a file path outside the expected directory, a recipient outside the approved domain list or a query against a table the feature never reads, is a sensitive signal for direct injection. Log tool name, arguments hash, caller identity and result size, then compare each call against a per-tool profile. Start with a short list of high-impact tools, such as email, file write and data export, before extending coverage. Expect false positives from new legitimate workflows added without a profile update, so tie profile changes to the change management process.
Privileged assistant sessions without approval
An assistant running under an account with administrative rights, especially on infrastructure where a privileged session is required, should not perform actions without a recorded approval. Check that the assistant identity is covered by the same privileged access controls as human administrators, and alert when it starts a privileged session outside an approved change window. This card maps to the ATT&CK mitigations User Account Management and Privileged Account Management, so review service accounts assigned to assistants and remove standing rights they do not need. Expect false positives from approved maintenance jobs, so the rule should check against the change calendar rather than time of day alone.
How to validate that a T1699 detection fires before you trust it
This sequence shows whether a T1699 Direct prompt injection detection actually fires, under known and approved conditions, before anyone relies on it for alerting or reporting. It produces a dated, versioned record that a CISO, auditor or detection engineer can read without rerunning the work.
Confirm the ATT&CK version and rule scope
The detection engineer and the security lead agree which ATT&CK version the detection targets and which platforms are in scope, such as Windows endpoints and the SaaS tenants that host AI assistants. T1699 is a sub-technique-level concept in practice, so the team also confirms how the detection maps to the technique and its current detection strategy. The step is done when the scope, the ATT&CK version and the rule identifier are written into the test plan. ATT&CK releases can rename or revoke techniques, so this record is the anchor for every later step.
Define the expected telemetry in advance
Before any test, the team lists the data sources the rule depends on, mapped to ATT&CK data components such as Application Log Content, Process Creation and Command Execution for endpoints, and the SaaS audit or application logs for tenants. For each source, the team writes the fields it expects to see, the log path or connector that delivers them, and the expected delivery latency. The step closes when the expected-fields list is approved by the detection owner and the system owner. Without this list, a missing alert cannot be told apart from a missing log.
Agree a benign test scenario with the system owner
The detection engineer drafts a benign, non-destructive test scenario that produces the behavior the rule is meant to catch, and the system owner approves it in writing. The scenario runs only in a lab, a private cyber range or a dedicated test tenant, never against production assistants holding client data. The approval records the systems involved, the people on call, the stop conditions and the change window. The step is complete when the signed-off scenario card is filed with the test plan. Illustrative example: a test account in a sandbox tenant submits a labeled, harmless test request that the rule should classify.
Run the scenario and capture raw telemetry
The tester executes the approved scenario exactly as written, with a unique run identifier in the test record so the events can be traced later. The platform team confirms that the raw events reached the log pipeline, whether on the Wazuh manager, in the SIEM or in the SaaS audit feed. The step is done when raw events for the run are present and their timestamps and host or tenant values are captured. If nothing arrives, the run is logged as a telemetry gap and the detection is not yet tested.
Confirm the rule fires and check field fidelity
The detection engineer checks whether the rule produced an alert for the run identifier and compares the observed fields against the expected-fields list from step two. Fields that are missing, renamed, truncated or populated with unexpected values are noted, because they often break correlation later. The step closes with one of three outcomes recorded: fired as expected, fired with field defects, or did not fire. A rule that fires on the wrong events is treated as a failed test even if an alert appears.
Measure alert fidelity and tune the rule
The team reviews whether the alert is specific enough for an analyst to act on, and whether benign activity in the same environment also triggers it. They run the approved scenario again after each tuning change, and they keep a short log of what changed and why. Tuning is limited to thresholds, allowlists tied to named owners, and field normalization, not to removing coverage silently. The step is complete when the team agrees the alert volume is workable and the rule still fires on the approved scenario.
Record results against the rule and ATT&CK version
The team writes a result record for every run, covering the timestamp, host or tenant, expected and observed fields, alert outcome, any gaps in logging, the tuning applied, and the ATT&CK and rule versions in use. Reviewers sign off on the record, and the detection is marked as validated only for the scope and version it was tested against. Records are kept with the detection's change history so that a later ATT&CK update or rule edit triggers retesting. Auditors and compliance leads can then trace the evidence without rebuilding the test.
Preventive controls that reduce T1699 exposure: M1018 and M1026
T1699 Direct prompt injection does not need a malware payload, but it still acts through the permissions of the account or service that runs the AI feature. The two mitigations in scope, User Account Management (M1018) and Privileged Account Management (M1026), limit how far a successful instruction can reach. The cards below describe the decisions that connect them across AI-enabled SaaS features and Windows hosts.
Scope AI feature service accounts
Give each AI-enabled SaaS integration or Windows-hosted assistant its own service identity rather than a shared or personal account. Limit that identity to the mailboxes, folders, tickets or records the feature must read for its stated job. When a prompt injection succeeds, the attacker inherits only that narrow scope. Check whether the vendor lets you restrict the connector's OAuth scopes and whether those restrictions are documented.
Remove standing administrator rights
Make sure no account used by an AI assistant, plugin or automation holds domain admin, tenant admin or local administrator rights on Windows hosts. If an assistant can run tools, those tools should execute as standard users. Where elevation is needed, require a separate, time-bound privileged path that a person approves. This keeps an injected instruction from turning into system-wide changes.
Gate tool and action permissions
Map each action an AI feature can take, such as sending email, creating tickets, exporting files or calling APIs, to an explicit permission. Require step-up approval for high-impact actions such as deletion, external sharing or configuration changes. Review the default permission set when a feature is enabled, because vendors may grant broad rights out of the box. Ask vendors to document which actions the model can trigger without user confirmation.
Separate privileged administration from assistant use
Administrators who manage AI feature settings should use dedicated accounts that they do not use to chat with the assistant or open external content. This limits the chance that an injected instruction in a document or web page reaches a session with elevated rights. Enforce this with separate identities and role assignments, and record privileged sessions for review.
Review and recertify access regularly
Schedule periodic reviews of every account, connector and token used by AI features, and remove those that no longer have an owner or a business purpose. Stale OAuth grants and unused service accounts widen what an injection can reach without anyone noticing. Confirm with your identity team how often reviews run and who signs off on them, and keep the review evidence for assessors.
What the SOC does in the first hours after a T1699 alert
The first task for the SOC is to decide whether the alert reflects an approved test or a live event. Check the red team calendar, the cyber range schedule and the change record for the AI feature before anything else, because a prompt injection test run against a production assistant can look identical to a hostile one. If no approval exists, treat the alert as a live event and open an incident. Next, pin down the identities involved: the user account that submitted the prompt, the session identifier, the tenant or workspace, and any host the user was working from. Record these in the case before pivoting, since later steps depend on them. Confirm the time window from the first suspicious prompt to the alert, and widen it if the detection fired on a single response rather than on a sequence.
Preserve evidence before anyone changes the environment. For SaaS assistants, export the audit and prompt logs for the tenant and window, including any tool or connector invocations the feature made on the user's behalf, and hash the export. For the Windows endpoint, use Velociraptor to collect the process, network and browser artifacts for the host, and keep the collection scoped to what the case needs. Then determine what the AI feature could reach at the time: which connectors were enabled, which mailboxes, file shares or records its service identity could read or write, and whether it could send messages or call external URLs. Ask the application owner for the configuration history, because permissions often changed in the weeks before an alert. Containment comes after this snapshot. Options include suspending the feature's service token, disabling the specific connector, or revoking the affected user's sessions, and each choice should be recorded with the person who approved it.
Escalate in parallel rather than in sequence. The application owner confirms expected behavior and can explain whether the output or action was intended. Legal and compliance teams need early notice if personal data, client records or regulated information may have left the feature's reach, because their notification clocks may depend on facts the SOC is still establishing. Align every step above with your own incident response plan, including who has authority to suspend a production feature, how severity is assigned and how communications are logged. Confirm these roles and thresholds with your IR lead before the first alert arrives, not during it.
Rehearsing T1699 detection and response in a private cyber range
The range is a private environment, isolated from production networks, corporate identity systems and live customer data. It mirrors the parts of the estate where direct prompt injection would matter: an isolated Windows domain with a test identity store, and a SaaS sandbox tenant that holds the same application configuration as the production tenant but contains only synthetic records. Logging from both is forwarded to a Wazuh manager or a Security Onion deployment so the analyst sees the same telemetry they would see in production.
- Isolated Windows domain: Build a small domain with test users, workstations and an administrative group that mirrors production naming, with no trust relationship to production.
- SaaS sandbox tenant: Request a non-production tenant from the vendor where possible, and confirm in writing what audit and application logs it exposes.
- Log forwarding: Forward Windows event logs and SaaS audit logs to Wazuh or Security Onion, and confirm which fields arrive for user and session context.
- Time and identity hygiene: Synchronize clocks across all components and label every test account so correlation during analysis is unambiguous.
- Change control: Record the range configuration as a versioned artifact so the same build can be rebuilt for each exercise.
Before the first exercise, check that every log source the detection depends on is present in the range and that retention matches the period the team plans to review.
Injects are scripted benign scenarios that the system owner approves in advance. Each one describes the observable behavior the detection should catch, such as a user submitting unexpected instruction-like text to an internal assistant, without containing any working attack payload. The script records the expected alert, the expected data components, and the owner who agreed to the scenario. Injects are written so that a trained facilitator can run them repeatedly and compare results across rounds.
- Agreed scenario list: Document each inject with its purpose, the system it touches, the approving owner and the date it was signed off.
- Benign content only: Use placeholder text that describes the behavior in plain language, and keep any test strings in a restricted repository rather than in the exercise handout.
- Mapped signals: Tie each inject to the telemetry it should produce, such as application log content or user session events, so the expected evidence is known in advance.
- Controlled timing: Publish a run schedule to the operations and service desk teams so injects are not confused with genuine incidents.
- Stop conditions: Define how the facilitator halts an inject, rolls back test state and reports the halt to the system owner.
Before each run, confirm that the owner has re-approved the scenario list if the application or its configuration has changed since the last exercise.
A useful exercise has clear success criteria agreed before the run, so the team can judge the outcome against expectations rather than memory. Good performance means the alert fires within the window the team set for itself, the analyst can enrich the event with user, session and asset context, and the containment decision is proportionate and recorded. The output is a lessons-learned list that assigns each gap to an owner, so the next round can show whether it closed.
- Detection within the window: Measure the time from inject to alert and compare it with the window the detection owner set before the exercise.
- Correct enrichment: Confirm the analyst can identify the account, the session, the application and the affected data scope without leaving the platform.
- Clean containment decision: Check that the containment step is documented, reversible where possible, and approved by the right role, such as the system owner or incident commander.
- Documented lessons learned: Record each gap, its owner and its target date, and review the list at the next exercise.
- Detection quality review: Note false positives and missed events, then feed them back into the rule logic and the data component coverage.
After each exercise, confirm that the results are tied to the ATT&CK version the team targets, because detection mappings can change between releases.
Questions detection engineers ask about T1699 direct prompt injection
Can Windows process telemetry alone reveal T1699 direct prompt injection?
Usually not on its own. Process creation events show that an AI client, script or agent process started, which user launched it and what its parent process was, but they do not carry the text sent to a model. To see the prompt, you need application logs from the model gateway, browser extension, agent framework or internal chat front end where prompts are recorded. Use process and network events to narrow the scope, such as an unexpected binary calling a model endpoint, then correlate with application logs. Confirm where your prompts are captured, and whether they are captured at all, before writing rules that assume the content is available.
How do you separate direct prompt injection from indirect injection?
The distinction is where the instruction came from. Direct injection arrives in the input the user typed into the model interface or API call. Indirect injection arrives inside content the model reads on the user's behalf, such as a document, web page, email or ticket. Your telemetry has to preserve that provenance, so tag prompt sources at ingestion, separate user-typed fields from retrieved content, and record which tool or data connector supplied each segment. For the other half of this pair, read the T1698 Indirect prompt injection page on this site, which covers the content-borne side and its own mitigations. Keep the two rule sets separate so that one does not hide the other.
What should you do when a SaaS vendor logs little model input?
Start by asking the vendor in writing which fields are logged: user identity, session identifier, prompt text, system prompt, tool or plugin invocations, model output, and retention period. If prompt text is not logged, shift your detection to observable effects. Look for tool calls that the account has never made before, bulk data access or export shortly after an AI session, changes to sharing settings, and actions taken outside normal working hours. Ask whether the vendor can export audit logs to your SIEM and whether it supports customer-managed log retention. Record the answers, because a rule built on fields the vendor does not provide will never fire.
How do you version Sigma rules against ATT&CK releases?
Record the ATT&CK version each rule was mapped against in the rule metadata and in your change log, so that every alert can be traced to the mapping that produced it. Enterprise ATT&CK 20.0 was released on October 13, 2026, according to the attack-stix-data repository index. Since releases can rename, deprecate or revoke techniques and detection strategies, compare each new release's STIX bundle with your mapped techniques and sub-techniques after every update, then update or retire affected rules. Keep the previous version's rules available until you confirm that alerts still map correctly. The ATT&CK updates page lists each release and its changes.
How do you test a T1699 rule for false positives?
Test against benign activity first. Replay a representative period of logs from approved AI tools, developer test sessions, service integrations and shared accounts, and count how often the rule fires and why. Then build allowlists by identity, application and endpoint, keeping each exception documented and time-limited. In a private cyber range, inject labeled test prompts into a lab tenant or sandbox model so you know which events should alert and which should not, and measure detection and false positive rates against that ground truth. Repeat the test after every logging or model configuration change, because a change in prompt formatting can silently break a rule.
What should you confirm before relying on a T1699 detection rule?
Confirm five things before the rule can alert in production:
- The log sources exist, are complete and carry the fields the rule needs, with clock sync across sources.
- Retention covers your investigation window, and the stored prompts are handled under your privacy and data classification policy, since prompts often contain personal or confidential data.
- The ATT&CK version the rule targets is recorded, and the mapping was reviewed against the current release.
- The rule has passed the false positive and range tests described above.
- A named owner and a written response runbook exist, including who can disable a session or revoke a token. Confirm each item in your own environment and with your vendors, not only in the rule text.
Can our own team build this detection without outside help?
It depends on your SIEM engineering capacity and access to the model and application logs. The work breaks into four parts: confirming log sources with each vendor, writing and versioning rules, testing in a range, and maintaining the rules after each ATT&CK release. Internal teams can do all four if they have those skills and time. An external partner can take on part or all of this under a fixed-scope agreement with written deliverables, or provide ongoing tuning under a retainer. DeployOpen implements and tests open-source security tooling inside the client's own infrastructure, and the scope is agreed in writing before work starts.
How DeployOpen builds T1699 detections, purple team exercises and range scenarios
DeployOpen treats T1699 Direct prompt injection as a detection and testing problem inside the client's own Windows and SaaS environments. Scope, detection content, range exercises and documentation are agreed in writing before work starts. Ongoing support and continuous testing are available as a retainer, and each detection is mapped to the ATT&CK version the team agrees to target.
How we scope
- The written scope names the platforms covered, such as Windows endpoints and the SaaS applications that accept user prompts.
- Scope lists which AI assistants, agents and prompt logs are in view for Application Log Content collection.
- Scope records the User Account Management and Privileged Account Management controls the client will review with us.
How we build
- Detection logic is written in plain terms first, then encoded as Sigma rules and tuned for the client's log sources.
- Telemetry is routed into the client's chosen open-source stack, such as Wazuh or Security Onion, after confirming log coverage.
- Each detection is tested against the agreed ATT&CK version, with notes on gaps in Network Traffic Content.
How we hand over
- Deliverables include detection rules, data source mappings, runbooks and a range exercise script for the client's team.
- Purple team sessions are run in a private cyber range, with results recorded against each detection and response step.
- Handover includes a walkthrough so the client's analysts can tune alerts and rerun the test themselves.
How we support
- Ongoing support is available as a retainer covering rule tuning and re-testing after platform upgrades.
- When ATT&CK releases rename or deprecate techniques, detection mappings are reviewed against the new version.
- Continuous testing of AI and agent security controls can be scoped separately under a written agreement.
