MITRE ATT&CK T1699 Direct Prompt Injection: Detecting and Containing Malicious Prompts

When a user can type into a model that holds tools, data or account permissions, the prompt box becomes an execution surface, and ATT&CK now tracks it as one. MITRE ATT&CK T1699 Direct Prompt Injection, added in ATT&CK v20 under Execution (TA0002) on the Windows and SaaS platforms, describes adversaries entering malicious prompts straight into an LLM's user interface to bypass safeguards, override earlier instructions or coerce the model into unauthorised behaviour. This page takes the ATT&CK view: the procedures ATT&CK records, what to log and alert on, the four mitigations ATT&CK maps, and how to test. It is for SOC analysts, detection engineers and teams that run LLM chatbots, support assistants or coding agents. For the wider topic, including hiding techniques and screening, see the Prompt Injection Guide.

Key takeaways

• The attacker is the user. Direct injection arrives through the interface you exposed, so authentication and session identity are your best evidence, unlike indirect injection where the instructions ride in on data.
• Persona claims are the recorded tradecraft. In ATT&CK's procedure for campaign C0062, operators told Claude they worked for a cybersecurity firm doing defensive testing to authorise restricted operations.
• All four ATT&CK mitigations sit outside the model. M1018, M1038, M1026 and M1017 each say the same thing in different words: the prompt must never set or raise the authorisation context.
• Harm scales with what the model can do. A chatbot that only talks causes embarrassment; an assistant with write access to account APIs can reset passwords for an attacker.
• Detection lives in AI telemetry. Prompt and response logs, guardrail verdicts and tool-call authorisation decisions, tied to an authenticated identity, are the data sources that make this technique visible.

What T1699 covers in ATT&CK v20

ATT&CK describes prompts designed to bypass safeguards, manipulate context, override previous instructions or coerce the LLM into unauthorised behaviour. It names two goals: making the model produce content its guardrails prohibit (which links to T1683 Generate Content) and inducing the system to use its capabilities in unintended or prohibited ways. It names two methods: telling the model to ignore earlier instructions or safety rules, and impersonating a role such as a researcher or privileged user. ATT&CK grounds the definition in the NIST glossary, which takes its definition from NIST AI 100-2 E2025, and in OWASP LLM01:2025.

The practical boundary: if the adversary has to log in, open a chat or call your model endpoint to deliver the instruction, it is T1699. If they plant it in an email, web page, ticket or file for the model to read later, it is T1698. See AML.T0051 LLM Prompt Injection and the LLM Jailbreaks Guide for the AI-centred treatment.

How adversaries have used it

Procedures recorded in ATT&CK

• Anthropic AI-orchestrated Campaign (C0062): ATT&CK records that the adversary entered a prompt claiming the user was an employee of a cybersecurity firm and that Claude was being used for defensive testing, to authorise restricted operations. Anthropic's November 2025 report attributes the September 2025 activity, with high confidence, to a Chinese state-sponsored group it tracks as GTG-1002, says roughly thirty organisations were targeted with success in a small number of cases, and describes operators splitting the attack into small, innocuous-looking tasks so the model never saw the full purpose. Anthropic banned accounts as it identified them, notified affected entities and built better classifiers. See the Anthropic GTG-1002 campaign analysis.
• AI-Assisted Breach of Mexico's Government Infrastructure (C0064): ATT&CK records the adversary using a file-write operation inside a prompt to make Claude Code create a claude.md file holding a pre-written 1,084-line document of penetration testing material used in the campaign. The lesson for defenders is that a coding agent's project instruction files are part of the prompt surface: a direct prompt can write persistent instructions the agent reads in every later session.

Other reported cases

• Customer chatbots coerced off-task: in December 2023 a visitor told a car dealer's ChatGPT-based sales chatbot to agree with anything the customer said and to call its answers legally binding, and it accepted a $1 offer for a new SUV; no sale was honoured and the bot was taken offline. See the Chevrolet dealer chatbot analysis. In January 2024 a DPD customer got the firm's support bot to swear and criticise the company; DPD disabled the AI element after what it called an error following a system update. See the DPD chatbot incident analysis.
• Support assistant with account powers: one of ATT&CK's own references, a June 2026 report by The Cyber Security Guru, describes attackers reportedly asking Meta's AI support assistant in plain language to link an attacker-controlled email to Instagram accounts and trigger password resets, because the assistant had write access to account-management APIs without an out-of-band verification step. Meta said it fixed an issue that let an external party request password reset emails for some users and that its systems were not breached.
• Failed attempts are evidence too: Google Threat Intelligence Group's January 2025 report on adversarial misuse of generative AI found government-backed actors pasting publicly available jailbreak prompts with small changes, or rephrasing and resending requests. All the attempts it observed against Gemini failed with safety fallback responses. That repetition pattern is a usable detection signal.

Where the impact comes from

The same prompt has very different consequences depending on what sits behind the model. Use this table to rate each AI application before deciding how much detection it needs.

For the coding agent case, see the AI Coding Agents Security Guide and AML.T0053 AI Agent Tool Invocation.

What to detect and where

ATT&CK v20 maps mitigations to T1699 but, at the time of writing, no detection strategy, so the analytics below are NHI Mgmt Group recommendations built on the technique description and the recorded procedures. They depend on logging every prompt, response, guardrail decision and tool call against an authenticated identity and a session ID.

Ship these logs to the SIEM with the user or workload identity attached, not just the application's service account. Without that link you cannot separate one abusive account from a thousand honest ones. See the AI Agent Behaviour Baselining and Anomaly Detection Guide.

Mitigations ATT&CK maps, and how to apply them

NHI Mgmt Group recommendations that sit alongside these: keep commitments such as prices, discounts and refund limits in application code and systems of record; filter outputs before they reach customers; restrict each assistant to its business purpose; make instruction and memory files for coding agents read-only or reviewed; and keep a route to a human so frustrated users are not pushed to game the bot. See the M1038 Execution Prevention and M1018 User Account Management pages.

Where identity fits

Every direct injection that causes real harm ends in a credential being used: the assistant's API token, the agent's cloud role, the MCP server's service account. If that non-human identity holds broader rights than the user talking to it, the prompt is a privilege escalation path. Give each AI application its own scoped identity, prefer delegated user tokens over shared service accounts, keep secrets out of prompts and context, and review agent permissions on a schedule. See the AI Agent Authorisation Guide and Secrets in Prompts.

Rolling it out

1. Inventory AI interfaces: list every chatbot, assistant, copilot and agent that accepts user prompts, with the tools, data and identities behind each, and rate it using the impact table above.
2. Turn on logging first: capture prompts, responses, guardrail verdicts and tool calls with user identity and session ID; agree retention and access controls, since prompt logs hold personal data.
3. Move authorisation out of the model: for the highest-rated application, put a policy check in front of every tool call and run it in log-only mode for two weeks to see what would be denied.
4. Enforce and add approvals: switch the policy to enforce, add human or out-of-band approval for sensitive actions, then repeat for the next application.
5. Build the analytics: start with refusal bursts, role claims compared to directory role, and authorisation denials; tune on a baseline of normal sessions.
6. Roll back safely: keep a feature flag per tool and per assistant so you can disable an action, or the AI element as DPD did, without taking the whole service down.

How to test it

• Authorised red team prompts: run instruction-override, persona and binding-commitment prompts against each assistant before launch and after every model, prompt or tool change, using a written scope and test accounts.
• Privilege tests: as a low-privilege test user, ask the assistant to perform an action only an administrator may perform; the pass condition is a denial from the authorisation layer, logged and alerted, whatever the model says.
• Detection tests: replay a scripted session with repeated refusals and a role claim and confirm the SIEM alert fires within your target time.
• Regression: keep the prompts as a suite that runs in the release pipeline. See AI security regression testing and the AI Agent Security Testing Checklist.

Decision guidance

• Guardrail product or architecture first: input classifiers reduce noise and give detection signal, but they will miss novel phrasing. If the assistant can take actions, fund out-of-model authorisation before a second classifier.
• Anonymous or authenticated access: anonymous chat is acceptable for assistants with no tools and no private data; anything that touches accounts or internal data should require authentication so abuse is attributable.
• Small organisations: keep assistants read-only, use the provider's moderation and logging features, and route all account changes to a human.
• Large organisations and AI providers: central AI gateway with logging and policy, SOC-owned analytics, account-level enforcement and a playbook for banning and notifying, as Anthropic did for C0062.

Measurement

• Coverage: share of AI applications sending prompt, verdict and tool-call logs with user identity to the SIEM.
• Out-of-model enforcement: share of tool calls passing through an authorisation check that does not rely on the model.
• Red team pass rate: share of the standard injection suite blocked or contained per release.
• Time to contain: median minutes from a confirmed abusive session to account suspension or tool disablement.
• Denied sensitive actions reviewed: share of authorisation denials on sensitive tools reviewed within one working day.

Common failure patterns

• The system prompt as the only control: rules written into instructions that a user can talk the model out of, as in the dealer chatbot case.
• Assistant identity broader than the user: a support bot holding account-management write access with no verification step, the pattern in the reported Instagram abuse.
• No logs tied to identity: prompts discarded or logged under one shared service account, so abuse cannot be traced to an account or stopped.
• Testing once at launch: a model, prompt or vendor update changes behaviour, as DPD reported after a system update.
• Trusting role claims: letting "I am a security tester" or "I am the administrator" change what the model will do, the exact C0062 procedure.
• Writable agent instructions: coding agents allowed to create or edit their own instruction files from a prompt, as in C0064.

Framework mapping

Practitioner checklist

• Inventory every AI interface that accepts prompts, with the tools, data and identities behind it.
• Log prompts, responses, guardrail verdicts and tool calls with authenticated user identity and session ID.
• Enforce tool and API authorisation in a policy layer outside the model, against the initiating user's rights.
• Require out-of-band verification or human approval for resets, contact changes, payments, deletions and privilege grants.
• Alert on refusal bursts, role claims that do not match directory role, and authorisation denials.
• Make coding agent instruction and memory files read-only or reviewed before use.
• Run an authorised injection test suite before launch and after every model, prompt or tool change.
• Keep per-tool and per-assistant kill switches and a playbook for suspending abusive accounts.

Standards and references

• MITRE ATT&CK: T1699 Direct Prompt Injection
• MITRE ATT&CK: C0062 Anthropic AI-orchestrated Campaign
• NIST: AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• MITRE ATLAS: AML.T0051 LLM Prompt Injection
• Anthropic: Disrupting the first reported AI-orchestrated cyber espionage campaign
• Google Threat Intelligence Group: Adversarial Misuse of Generative AI
• The Cyber Security Guru: Instagram Meta AI account recovery exploit report

Related NHI Mgmt Group resources: Prompt Injection Guide, OWASP LLM Top 10 LLM01 Prompt Injection Guide, ATT&CK Execution Tactic Guide, T1683 Generate Content Defensive Guide, Prompt Injection Incident Response Playbook.