Every chat box that fronts an AI system is also an input anyone with access can try to abuse. MITRE ATT&CK T1699, Direct Prompt Injection, covers adversaries who enter malicious prompts directly into an LLM's user interface. It is in the Execution tactic and lists Windows and SaaS as platforms.
How attackers use it
MITRE describes prompts designed to bypass safeguards, manipulate context, override earlier instructions or coerce the model into unauthorized behavior. Typical moves are telling the model to ignore previous instructions or safety rules, or claiming a role such as a researcher or privileged user.
The page names two uses. Adversaries may use it to Generate Content (T1683) that the model's guardrails prohibit, or to push the system to use its capabilities in ways that were not intended or are prohibited. The second matters most when the model is connected to tools, files or accounts, because words then turn into actions.
The page lists two procedure examples. In one, an adversary entered a prompt claiming the user worked for a cybersecurity firm and that the AI was being used for defensive testing, in order to authorize restricted operations. In the other, a file-write operation inside a prompt created an instruction file that held a long pre-written document of testing scripts. Both show the same weakness: a claim in text was treated as if it carried authority.
The difference from indirect injection (T1698) is where the text comes from. Here the adversary types it. There the text hides in content the model later reads.
How to detect it
The MITRE page has no detection section for this technique. A prompt is free text, and the same wording can be an honest question or an attack. Instead, concentrate on what the system did and on whose behalf:
- Tie every AI interaction to an authenticated identity, so there is someone to ask.
- Log prompts and tool calls, subject to your privacy rules, with the identity, time and outcome.
- Flag tool calls that exceed what the user normally does, such as a first-ever request to write files or touch an admin function.
- Look for repeated refusals followed by rewording from the same user, which can indicate someone testing the guardrails.
- Watch for actions that were denied by policy outside the model, since those denials are the cleanest signal that a prompt asked for too much.
How to reduce the risk
MITRE lists four mitigations.
- User account management. Associate AI interactions with authenticated identities and limit AI-mediated actions to the permissions of the user who started them. Prompt content must not set or raise the authorization context used by downstream tools or services.
- Execution prevention. User prompts must not directly authorize consequential actions. Enforce tool, API, command and resource authorization outside the model, and reject requested actions that exceed the permissions of the initiating user or agent task.
- User training. Teach the people who run AI systems to recognize attempts to manipulate system instructions, role boundaries or safety controls, and to check consequential AI-generated actions independently.
- Privileged account management. Restrict privileged AI capabilities and require explicit authorization or human approval for AI-generated actions involving administration, sensitive resources or privileged tools.
The theme is one rule. Authority comes from the identity and the policy layer, never from what the prompt says about itself. A model cannot reliably tell a real security researcher from someone who claims to be one, so do not ask it to.
Check your own environment
- Does each AI feature run as the signed-in user, or as one shared powerful account?
- If a user lacks permission to delete a record, does the AI assistant lack it too?
- Are tool permissions enforced by the tool or API, not by instructions in the system prompt?
- Is there a human approval step for admin actions, payments and data export?
- Are prompts and tool calls logged with identity, and who reviews them?
- Do the people who maintain your AI systems know the role-claim trick described above?
Try it yourself
This demo walks through a guardrail that checks tool requests against policy instead of trusting the prompt.
Click through it at your own pace, or open it full screen.
Quick check
A prompt says the user is a security tester and asks for restricted actions. What should decide the answer?
The authenticated identity and the policy enforced outside the model. A claim made in text does not change what the user is allowed to do.
How is direct injection different from indirect injection?
In direct injection the adversary types the malicious prompt into the interface. In indirect injection the prompt is hidden in content such as a page, ticket or document that the model retrieves later.
