Invisible prompt attack chains expose weak AI assistant trust models

At a glance

What this is: A new attack chain against Claude combined an open redirect, invisible prompt injection, and API-based exfiltration to target prior chat content and connected MCP integrations.

Why it matters: AI assistant governance now has to account for hidden instructions, delegated tool access, and user interaction flows that can bypass human review before damage is done.

Context

The core problem is trust collapse in AI assistant entry points. A link can look legitimate to a user while still carrying hidden instructions for the model, which means the security boundary is no longer the visible URL alone.

In this case, the attack chain used an open redirect, concealed prompt text, and an API-based exfiltration path. That combination matters for agentic AI and NHI governance because the assistant, its API key, and any connected MCP tools can all become part of the same abuse path.

Anthropic had reportedly patched the specific pre-filled chat URL mechanism before publication, but the article says the redirect and hidden-prompt techniques remain exploitable in similar services. That makes the broader control gap the real subject, not a single product flaw.

Key questions

Q: What breaks when hidden prompt instructions are delivered through a seemingly safe link?

A: The assumption that users can validate what an AI assistant will execute breaks immediately. If the malicious instruction is hidden behind redirects or formatting tricks, the user sees a safe-looking link while the model receives an unsafe prompt. That makes visual review insufficient and shifts the control problem to prompt provenance and runtime filtering.

Q: Why do AI assistant attack chains create higher exfiltration risk than ordinary prompt injection?

A: Because the attack can couple prompt manipulation with an outbound API or tool path. Once the assistant is persuaded to summarise or forward sensitive context, the attacker is no longer relying on model output alone. The risk is multiplied when the assistant has delegated access to files, messages, or external services.

Q: What are the signs that an AI assistant prompt flow is being misused?

A: Watch for links or prompts that behave differently for the user and the model, repeated attempts to hide text, unusual summarisation requests, and responses that attempt to reach external APIs or connected tools. Those signals often indicate that the prompt is being used as a delivery vehicle rather than a normal user request.

Q: How should teams govern AI chatbots that can touch sessions or support tools?

A: They should treat the chatbot as an operational actor with bounded authority, separate its state from authenticated credentials, and review every integration that can convert a prompt into a support action. Governance should focus on trust boundaries, not model prompts alone.

Technical breakdown

How invisible prompt injection survives the user interface

Invisible prompt injection is a delivery technique, not a model capability. The attacker places instructions in a URL or page element that the user cannot see, then relies on browser handling, redirects, or formatting tricks to surface the content only to the AI assistant. The control failure is that the human reviewer sees a benign link while the model receives a malicious instruction set. In practice, this breaks any governance model that assumes user awareness is enough to validate a prompt before execution.

Practical implication: treat prompt provenance as a security control, not a UI concern.

Why API-based exfiltration changes the blast radius

The exfiltration path matters because it turns a model response into a delivery channel for stolen context. In the article’s chain, the assistant is induced to summarise sensitive prior chat content and then send that summary through the Claude API under attacker-controlled conditions. That shifts the risk from a simple prompt attack to credential-backed data removal. When the API key and prompt flow belong to different trust domains, the organisation has to govern both the model interaction and the outbound transport path.

Practical implication: separate prompt handling controls from outbound API controls and monitor both for abuse.

What MCP integrations change about AI assistant privilege

MCP tools extend the assistant’s reach into files, messages, and other connected systems. That means a prompt attack can become a privilege abuse event if the assistant is allowed to call tools that were intended for normal user assistance rather than adversarial content retrieval. The architectural issue is not just access, but delegated execution scope. If the assistant can query, summarise, or forward content across tools, the attacker can amplify a single hidden instruction into multi-system exposure.

Practical implication: inventory connected tools and constrain which assistant actions can reach sensitive data or messaging paths.

Threat narrative

Attacker objective: Steal sensitive information from prior AI assistant conversations and, where available, extend that access into connected MCP tools or other linked data sources.

1. Entry begins when the victim clicks a tainted search result that uses a legitimate-looking Claude redirect to mask the malicious destination. The visible link appears safe, but the hidden prompt content is already in place.
2. Credentialed abuse follows when Claude is induced to process the hidden instructions and to summarise prior chat content or other sensitive context. The attacker then uses the API-based delivery path to pull the stolen summary from logs or responses.
3. Escalation occurs if MCP integrations or connected tools are present, because the same prompt path can request files or messages beyond the initial chat history. The attack therefore turns a single click into broader data exposure across linked services.
4. Impact is the unauthorised disclosure of sensitive prior conversations and potentially connected workspace content. The attacker objective is to extract hidden data from the assistant context without the user recognising the malicious instruction set in time.

Breaches seen in the wild

• EchoLeak (Microsoft 365 Copilot) 2025: A crafted email could make Microsoft 365 Copilot leak data from its context with no click, a zero-click prompt injection fixed as CVE-2025-32711.
• ForcedLeak (Salesforce Agentforce) 2025: A critical Agentforce flaw let attackers steer an AI agent through a Web-to-Lead form to leak CRM data via an expired allowlisted domain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Invisible prompt delivery is an assumption collapse, not just a content trick: The governance premise that users can visually validate what an AI assistant will process fails when the instruction payload is hidden inside a redirect or formatted text. That premise was designed for human-readable prompts and transparent review loops. It fails when the actor is autonomous enough to parse and act on content the user never sees. The implication is that prompt trust has to be treated as a runtime control surface, not a user-awareness problem.

AI assistant trust models now need identity-aware boundary control: The article shows that the assistant, its API key, and its MCP tools can participate in one chained abuse path. That means the relevant security question is no longer whether a prompt is benign in isolation, but whether the identity that can issue the prompt also has a controlled path to exfiltration or tool execution. This is exactly where NHI governance and agentic AI governance converge for practitioners.

Delegated execution expands the blast radius of a single click: When an assistant can summarise prior chat content and call external APIs, one tainted interaction can move from prompt injection to data removal without any additional user action. That raises the stakes for lifecycle control over API credentials and connected tools, because the attack does not need to defeat the assistant’s reasoning, only its delegated authority. Practitioners should assume that prompt provenance, credential scope, and tool reach are now one governance problem.

Hidden prompt attacks create trust debt across search, browser, and assistant layers: The article’s chain depends on a search result, browser rendering, model interpretation, and API delivery all agreeing to trust the same flow. That is a fragile model for any programme that still separates web security, IAM, and AI governance into disconnected controls. The practical conclusion is that assistant access paths need the same scrutiny as privileged workflows, because the attack path is already cross-domain by design.

Invisible prompt chains are the clearest case yet for runtime governance of AI assistants: Static policy checks cannot reliably catch instructions that only become visible after click-through or after model interpretation. The field needs controls that understand provenance, instruction visibility, delegated tool reach, and outbound data paths as one system. That is the governance shift this incident makes unavoidable.

What this signals

Prompt visibility is now a governance control: Security teams cannot assume that a link the user can inspect is the same instruction set the model will receive. For AI assistants, prompt provenance has to be validated before execution, especially where redirects and formatted content can hide attacker instructions.

The more assistants can reach prior chats, files, or external APIs, the more the programme has to govern delegated authority rather than just model behaviour. That means IAM, NHI governance, and AI security are converging around the same design question: who can make the assistant act, and what can it do once it does.

Invisible prompt chains turn the assistant into a cross-domain identity problem: Once the prompt can drive outbound data movement, the security boundary is no longer only the model. It is the combined trust path across browser, assistant, API key, and connected tools.

For practitioners

• Audit hidden-instruction delivery paths Review search, redirect, and pre-filled prompt flows to identify where user-visible content diverges from model-visible content. Remove or isolate any path that can carry instructions the user cannot inspect before execution.
• Constrain assistant exfiltration paths Map every API, logging, and response channel that can carry assistant output outside the tenant. Require explicit approval or separate controls for any path that can move chat history or summarised content off platform.
• Inventory MCP-connected tools List every file, message, and workflow tool exposed to the assistant, then classify which ones can read sensitive content or send messages. Restrict high-risk tools to narrow, task-scoped access.
• Separate prompt trust from user trust Do not treat a clicked link as evidence that the embedded instruction set is safe. Add controls that validate prompt provenance, not just user authentication or session state.
• Test for invisible prompt abuse Red-team the assistant with hidden prompt payloads, masked redirects, and tool-reach scenarios to confirm whether the model can be induced to reveal prior context or contact downstream services.

Key takeaways

• Hidden prompt injection can bypass user awareness and turn a safe-looking link into a model execution path.
• The attack chain matters because it links prompt manipulation to API-backed exfiltration and tool reach, not just to misleading text.
• Practitioners need controls for prompt provenance, delegated tool scope, and outbound data paths if they want AI assistant governance to hold up.

Key terms

• Invisible Prompt Injection: A prompt injection technique that hides malicious instructions from the user while leaving them available to the model in machine-readable form. It relies on presentation gaps, redirects, or formatting tricks so the assistant acts on content the human reviewer cannot reliably see in time.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.
• Plugin Provenance: Plugin provenance is the label Claude Code uses to identify where a plugin came from, such as a marketplace cache, inline path, skills directory, synced source, or built-in location. Policy can match on provenance, so security teams need to know which sources can auto-load code without a separate installation step.
• Assistant Exfiltration: Assistant exfiltration is the transfer of sensitive data out of an environment through the actions or outputs of an AI assistant, often after it has read material it should not have handled. This can happen through normal-looking channels such as tool calls, outbound queries, or encoded responses.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.