Claude Desktop prompt injection exposes the human approval gap

At a glance

What this is: A Claude Desktop flaw let a single crafted link deliver instructions to the assistant without a send step or human review, turning prompt injection into immediate action.

Why it matters: It matters because identity and access programmes now need to govern not just who can use an AI assistant, but which instructions can reach it and whether a human approved the specific action.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Oasis Security's analysis of the Claude Desktop prompt injection flaw

Context

Claude Desktop prompt injection is a case where a link, rather than a user command, became the vehicle for instruction delivery. That matters for AI agent identity governance because the control problem is no longer only authentication at login, but assurance at the point the assistant decides what to do.

The vulnerability exposed a familiar but under-governed assumption: that instructions reaching the assistant were user-authored and user-approved. Once that assumption fails, a desktop AI becomes a runtime access surface, and the risk spans agentic AI, non-human identities, and the human approval boundary that should separate the two.

For organisations deploying AI assistants with access to conversation history, files, or development tools, the question is not whether the model is “smart” enough. The question is whether governance can still prove intent, scope, and approval when the instruction arrives through a hidden or crafted path.

Key questions

Q: What breaks when an AI assistant accepts instructions before a human reviews them?

A: The approval model breaks, because the system can no longer prove that the instruction was user-authored or user-approved. That creates a trust gap between what the human intended and what the assistant executed. In practice, hidden or pre-filled prompt content can drive data exposure or tool use without a genuine consent step.

Q: Why do AI assistants with file or memory access increase security risk?

A: Because the assistant’s delegated access defines the blast radius of any prompt injection. If the assistant can read conversations, files, or development tools, an attacker who controls the instruction path can turn that access into real impact. The more standing privilege the assistant has, the less useful a simple “be careful what you click” defence becomes.

Q: How should security teams implement approval controls for AI assistants?

A: Place the approval control at the point of execution, not just at login or onboarding. The assistant should wait for an explicit human confirm step before acting on any prompt that arrived through an external or indirect channel. That gives governance a verifiable decision point instead of assuming the prompt was safe because the session was legitimate.

Q: Who is accountable when an AI agent performs an unauthorized action after injection?

A: Accountability follows the governance model that granted the agent its permissions and execution rights. The owner of the agent workflow, the approver of its tool scope, and the team operating the control plane all share responsibility. Frameworks such as OWASP-NHI and zero trust expect those boundaries to be explicit.

Technical breakdown

How one-click prompt injection bypasses the user boundary

Claude Desktop could be opened by a link, but the flaw let a crafted link carry instructions as well as the app launch. That collapses the normal trust boundary between navigation and command submission. In practice, the assistant received prompt content before the user had a chance to inspect or approve it, which means the application treated external text as if it were a legitimate runtime instruction. This is classic prompt injection, but delivered through the user interface rather than through a chat box.

Practical implication: treat app-opening links as an input channel that needs inspection and policy control, not just phishing awareness.

Why visible prompts and hidden instructions create governance risk

The attack relied on separating what the user saw from what the assistant processed. A harmless-looking visible prompt could mask additional instructions below the fold, creating a mismatch between human intent and machine action. That is an identity problem as much as a UX problem, because authorisation depends on knowing which instruction was actually approved. When hidden content can drive action, the system loses the ability to distinguish a user request from an attacker-supplied command.

Practical implication: enforce instruction provenance checks so AI systems can tell approved prompts from injected content.

Why the impact depends on the assistant’s reachable privileges

The consequence of prompt injection depends on what the assistant can already reach. If it can access chat history, the exposure may be private conversations, source code, or internal documents. If it can read and write files or invoke tooling, the same injection can escalate into code execution or broader environment impact. In identity terms, the assistant is operating as a non-human identity with delegated access, so the blast radius is defined by its standing permissions and connected tools.

Practical implication: map every reachable data source and tool to the assistant’s delegated access before allowing production use.

Threat narrative

Attacker objective: The attacker wants to turn a single user click into trusted AI action that exposes data or executes code through the assistant’s delegated access.

1. Entry occurs when a user clicks a crafted link that opens Claude Desktop and delivers hidden instructions instead of a simple app launch.
2. Escalation occurs when the assistant accepts those instructions as valid prompt content and acts within whatever delegated access it already has, including history, files, or coding tools.
3. Impact occurs when the assistant copies sensitive conversations, processes internal content, or runs attacker-supplied code through its authorised capabilities.

Breaches seen in the wild

• Gemini AI Breach — Google Calendar Prompt Injection — Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.
• Amazon Q AI Coding Agent Compromised — Amazon Q AI coding agent compromised via prompt injection enabling hackers to inject data-wiping commands.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prompt provenance is the control that failed here. The security assumption was that instructions reaching the assistant were authored or approved by the human who opened the session. PromptFiction shows that assumption is too weak when a link can smuggle instructions into the runtime path. The practical conclusion is that AI governance must separate launch, prompt delivery, and action approval instead of treating them as one event.

Human approval at the moment of action is the new trust boundary. A pre-filled prompt is not the same as a user decision, and AI systems that act before explicit send or confirm steps are effectively operating on borrowed consent. That is not just a UX defect, it is an identity failure because authorisation is being inferred from navigation rather than granted through a deliberate step. Organisations should read this as evidence that approval gates need to sit directly on the action path.

Identity blast radius now includes the assistant’s delegated tools and memory. Once an AI assistant is allowed to see conversations, files, or coding surfaces, prompt injection stops being a nuisance and becomes a path to real impact. The problem is not that the model is autonomous in the strict sense, but that it can still execute within a broad delegated trust envelope. That makes access scoping, tool binding, and runtime provenance checks central to AI agent governance.

PromptFiction is a named example of instruction-channel hijack. The link did not merely exploit a vulnerability, it redirected the control plane for instruction delivery. That matters because many governance models still assume the request channel and the approval channel are the same thing. They are not, and practitioners should design for the possibility that a trusted interface can carry untrusted instructions.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap is why the OWASP Agentic AI Top 10 belongs in prompt-injection threat modelling, alongside runtime provenance checks and action gating.

What this signals

Prompt provenance will become a standard control surface for AI assistants. Teams that only manage identity at login will keep missing the moment an assistant actually receives instructions. That is why the governance model has to extend into runtime, with provenance, approval, and tool-binding controls that can tell a user request from an injected command. For teams aligning to external guidance, the NIST AI Risk Management Framework is a sensible anchor for the governance layer.

Instruction-channel hijack is the right concept for this class of flaw. The attacker is not trying to break the model’s reasoning, but to seize the path by which instructions enter the system. Once that concept is named, the right operational questions become visible: can the system prove source, can it enforce human approval, and can it prevent hidden content from altering the action path? That is a materially different problem from ordinary phishing.

If your AI assistant can reach files, chats, or code, the next governance milestone is not broader adoption but narrower delegation. Organisations should pair prompt-path controls with the OWASP Agentic AI Top 10 and reduce standing access before a single click becomes a runtime breach.

For practitioners

• Separate prompt delivery from action approval Require an explicit human confirmation step before any AI assistant executes a real action, especially when the instruction originates from a link, attachment, or hidden prompt content.
• Validate instruction provenance Log and inspect where prompts came from, how they were inserted, and whether the visible text matched the content actually consumed by the assistant.
• Reduce delegated assistant scope Limit chat history, file access, and tool invocation to the smallest task-bound permissions needed, and remove blanket trust from desktop AI deployments.
• Treat app-opening links as security events Review links that open AI apps with the same caution applied to file downloads, since they can carry hidden instructions that bypass user intent.
• Test for hidden-prompt abuse paths Add red-team scenarios for folded, masked, and pre-filled prompt content so the organisation can see whether the assistant acts before a human review occurs.

Key takeaways

• A one-click prompt injection shows that AI governance fails when the instruction path is trusted more than the human.
• The impact of the flaw scales with delegated access, because assistant privileges determine whether the outcome is data exposure or code execution.
• Practitioners need runtime approval, instruction provenance, and tighter tool scope, not just safer login flows.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Prompt-Path Control: Prompt-path control is the set of checks that govern how instructions enter an AI system, including source validation, approval gating, and content inspection. It matters because the security problem often appears before the model reasons, at the point where text becomes an action trigger.

What's in the full report

Oasis Security's full blog post covers the technical detail this post intentionally leaves for the source:

• A step-by-step explanation of how the crafted Claude Desktop link delivered hidden instructions into the assistant.
• Configuration-specific behaviour showing what the assistant could access on standard installs versus coding-enabled setups.
• The precise mitigation change Anthropic applied after disclosure, including how the pre-filled prompt now waits for explicit user send.
• A technical walkthrough of the attack path and why the visible content could differ from the prompt content the assistant processed.

👉 The full Oasis Security post covers the attack path, configuration differences, and the fix applied after disclosure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing identity security in your organisation, it is worth exploring.