A technique where attacker-controlled content is written to look like higher-priority or more trusted instructions inside the model context. In AI assistant environments, this can override the intended hierarchy between system, user, and document inputs and redirect tool use.
What Context Authority Spoofing Is
Context authority spoofing is a prompt and instruction-layer attack in which untrusted content is made to resemble higher-priority guidance inside a model’s context window. The goal is to trick an AI assistant into treating attacker-written text as system-level, policy-level, or otherwise authoritative input, so the model follows the wrong instruction hierarchy.
How It Works in Assistant Contexts
This technique depends on the model or surrounding application failing to preserve clear separation between instruction sources. Spoofed text may imitate system prompts, developer notes, policy excerpts, document headings, or tool instructions, then exploit the model’s tendency to privilege recent, salient, or formally framed content.
In practice, the attack is strongest when an assistant ingests documents, web pages, tickets, emails, or retrieval results that can contain attacker-controlled wording. If the model is not tightly constrained, the spoofed content can redirect the conversation, alter refusal behaviour, or change which tools the assistant attempts to call.
Why It Is Dangerous
The security problem is not just incorrect text generation, but authority confusion. Once the model accepts spoofed context as trusted instruction, it may reveal sensitive data, ignore safety rules, or act on malicious requests that were never legitimately authorised.
That makes context authority spoofing especially dangerous in systems that combine retrieval, tool use, and delegated actions. It can be used to steer the assistant into a harmful workflow even when the original user prompt was benign. MITRE’s MITRE ATLAS adversarial AI threat matrix is a useful reference for this broader class of prompt injection, context poisoning, and tool misuse behaviour.
Typical Defences and Design Assumptions
Defence starts with treating all retrieved or inserted content as data, not instructions, unless it has been explicitly promoted by the application. A robust assistant should preserve a strict instruction hierarchy, isolate untrusted text, and avoid giving retrieved content equal standing with system or policy messages.
Designers should also reduce the amount of authority the model can exercise over tools and downstream actions. The Model Context Protocol authorization specification is relevant here because it formalises token boundaries and server-side authorization instead of relying on the model to self-police access. For a broader threat-modeling view, the OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework both help map how context manipulation can cascade into tool misuse or privilege abuse.
Detection and Review After Exposure
Detection is usually behavioural rather than purely signature-based. Warning signs include sudden instruction drift, unusual tool selection, policy bypass attempts, or responses that begin citing attacker-provided phrasing as if it were authoritative. Logging the full prompt assembly path, including retrieved content and tool decisions, is critical for post-incident analysis.
After suspected exploitation, teams should review the affected conversation transcripts, retriever output, tool calls, and any side effects created by the assistant. If the assistant could act on behalf of users or systems, the review should also consider whether any secrets, tokens, or other sensitive operational material were exposed or misused during the interaction.
Risk and Threat Considerations
Context authority spoofing is dangerous because it exploits a trust boundary inside the assistant itself, not just the user interface around it. Attackers can hide malicious instructions in documents, web content, or other retrieved material and rely on the model to elevate that content above legitimate policy or developer guidance.
Failure mechanism: The model or orchestration layer fails to preserve instruction provenance, so attacker-controlled text is interpreted as a higher-priority instruction source and can redirect reasoning or tool use.
Impact: The assistant may exfiltrate data, perform unintended actions, violate policy, or chain the spoofed instruction into downstream compromise of connected systems and workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1056 — Input Capture: Keylogging / User Input Capture | Covers prompt and context manipulation as adversary input abuse |
| Recommendation — Map context-spoofing behaviour to adversary input manipulation and hunt for instruction-injection patterns. | ||
| OWASP Agentic AI Top 10 | ASI01 — Agent Goal Hijack | Directly addresses attacker redirection of an agent’s intended objective |
| ASI02 — Tool Misuse | Context spoofing often steers agents into unauthorized or harmful tool use | |
| ASI03 — Identity & Privilege Abuse | Spoofed context can induce an agent to act with more authority than intended | |
| Recommendation — Constrain goal-setting inputs so untrusted context cannot replace the agent’s intended objective. Authorize tool calls server-side and verify the request origin before execution. Enforce least-privilege boundaries so agent instructions cannot expand execution authority. | ||
| NIST AI RMF | GV.1 — Govern AI Risk | Applies to governance of AI risks from manipulated context and unsafe agent behaviour |
| Recommendation — Establish governance for prompt, retrieval, and tool-risk controls across the AI system lifecycle. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Limits harm when spoofed context tries to trigger overbroad actions or access |
| AU-2 — Event Logging | Supports investigation of prompt assembly, tool calls, and suspicious instruction drift | |
| Recommendation — Restrict each tool and service account to the minimum permissions required for its function. Log prompt inputs, retrieval results, and tool decisions to support compromise review. | ||
Practitioner Guidance
Why practitioners should care: Context authority spoofing is a control-plane problem, not just a prompt-quality issue. If your assistant can ingest external text or call tools, you need to assume that untrusted content will try to impersonate authority somewhere in the flow.
Common misunderstanding: Many teams focus on filtering harmful phrases but overlook the more important issue of instruction hierarchy. A harmless-looking sentence can still be dangerous if it is framed to look like a system rule, policy statement, or tool directive.
Practitioner takeaway: Treat context provenance, instruction separation, and tool authorization as core security controls, not optional prompt-engineering refinements.
Related resources from NHI Mgmt Group
- What breaks when agentic systems rely on logs without intent and authority context?
- Is CVE-2021-36942 (Microsoft Windows Local Security Authority (LSA) Spoofing) being exploited in the wild?
- How do you patch or mitigate CVE-2021-36942 (Microsoft Windows Local Security Authority (LSA) Spoofing)?
- Context-Bound Authority
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org