A single link can open a user's AI assistant with the first prompt already written by someone else, and the assistant then acts with that user's memory, data and connected tools. MITRE ATLAS tracks this as AML.T0131 Crafted AI Assistant Links, in the Initial Access tactic (AML.TA0004), and rates it as realised. ATLAS notes that many assistants accept a prompt through URL parameters such as ?q= or ?prompt=, which is populated and in some cases submitted when the link is opened, and that these links are often disguised as "Summarize with AI" buttons or share links. This guide is for security operations, email security and AI platform teams: how the technique shows up, what to hunt for in URL and click telemetry, and which controls reduce it. The related technique AML.T0078 Drive-by Compromise, where the instructions arrive from a visited page rather than the link itself, has its own page: MITRE ATLAS AML.T0078 Drive-by Compromise Guide. Prompt injection in general is covered in the Prompt Injection Guide, and attacks needing no click at all in Zero Click AI Agent Exploits.
Source note: technique, tactic, mitigation and case study details on this page are from MITRE ATLAS release 2026.10 (ATLAS data modified 28 October 2026). Confirm against the official text before relying on it.
Key takeaways
- The adversary writes turn one. A crafted link lets whoever controls the hyperlink author the opening prompt of a session that runs in the target's own assistant.
- Memory turns one click into lasting influence. In the ATLAS case study, a hidden clause asked the assistant to remember a domain as trusted, which biased later, unrelated answers.
- It is one-click, not zero-click. The user must open the link, which makes email, chat and web click telemetry the best place to detect it.
- The prompt is visible in the URL. Unlike most injections, the instruction text sits in a query string that gateways, proxies and click logs already record.
- Impact depends on what the assistant can reach. Memory, connected mailboxes, files and tools decide whether a crafted link produces biased advice or data loss.
How the technique works
Assistant products support deep links so that websites, extensions and colleagues can share a ready-made question. AML.T0131 abuses that convenience. The chain has four parts:
- Craft: the adversary encodes instructions into the prompt parameter of a link to a legitimate assistant domain. ATLAS case study AML.CS0072 records operators adopting publicly available tooling to generate these links (mapped to AML.T0016 Obtain Capabilities).
- Disguise and distribute: the link sits behind a benign label such as a "Summarize with AI" button, a share widget or an email link. ATLAS maps the concealment to AML.T0068 LLM Prompt Obfuscation and the hosting to AML.T0079 Stage Capabilities.
- Open: the user clicks, the assistant opens on its real domain with the user's session, and the prompt is placed in the input field or run immediately.
- Act: the assistant follows the supplied instructions. Outcomes recorded so far include writing a persistent memory entry (AML.T0080.000 Memory) and biasing later answers (AML.T0130 AI Agent Response Biasing). ATLAS also lists exfiltration of data the assistant can access as a possible outcome.
Because the link points to the genuine assistant domain, domain reputation and certificate checks see nothing unusual. The signal is in the parameter content.
Crafted links versus related techniques
| Technique | Who supplies the instruction | User action | Best detection point |
|---|---|---|---|
| AML.T0131 Crafted AI Assistant Links | The link's query string | One click on a link | Email, chat and proxy URL logs |
| AML.T0078 Drive-by Compromise | Content on a page the user or agent visits | Browsing, or an agent fetching the page | Web gateway, agent retrieval logs |
| AML.T0051.001 Indirect prompt injection | Content the assistant retrieves (mail, files, web) | Often none | Assistant retrieval and output logs |
| AML.T0051.000 Direct prompt injection | The user typing or pasting a prompt | User submits the prompt | Prompt logs and guardrails |
The EchoLeak 2025 case shows the zero-click end of this spectrum: instructions arrived in an email the assistant retrieved, and data left through a URL the assistant generated. Crafted links invert that flow: the URL carries the instruction in, and a user click starts it.
Real cases
- AI Recommendation Poisoning (AML.CS0072): Microsoft's Defender Security Research Team reported in February 2026 that, reviewing AI assistant URLs seen in email traffic over about 60 days, it found more than 50 distinct promotional memory manipulation prompts from 31 companies across 14 industries. Each link paired a real summarisation request with an appended instruction to treat the operator's domain as a trusted source in future. ATLAS lists the targets as users of assistants with persistent memory, including ChatGPT, Claude, Grok, Microsoft 365 Copilot and Perplexity (listed alphabetically). Several prompts targeted health and financial sites, and Microsoft reported that effectiveness varied by platform and that some behaviours could no longer be reproduced as vendor protections evolved.
- Reprompt: Varonis Threat Labs described a single-click chain against Microsoft Copilot Personal in which the
qparameter filled and ran a prompt on page load, and follow-up instructions were then fetched from an adversary server step by step. Varonis states that Microsoft 365 Copilot for enterprise customers was not affected and that Microsoft has patched the issue. Its vendor-side lesson applies to any assistant builder: treat deep links and pre-filled prompts as untrusted input throughout the flow, and keep safeguards active across repeated and follow-up requests, not only the first prompt.
Detection
Microsoft's research recommends hunting for AI assistant URLs whose prompt parameters contain persistence and authority keywords such as remember, memory, trusted, authoritative, future, citation and cite, and applies the logic to email URL data, Teams message URLs and Safe Links click events, as well as web proxy, endpoint and browser history. Generalise that into a small detection set.
| Signal | Data source | Notes |
|---|---|---|
Links to assistant domains carrying a prompt parameter (q, prompt or the product's equivalent) in inbound email | Email gateway URL extraction | Baseline first: internal share links may be common |
| Prompt parameter text with persistence words (remember, always, from now on, trusted source) or tool verbs (send, forward, upload, open) | Email, chat and proxy URL logs after URL decoding | Decode percent and base64 encodings before matching |
| Unusually long prompt parameters, or parameters containing other URLs | Proxy and click logs | Long or nested URLs suggest hidden instructions or a callback address |
| Clicks on such links followed by new memory entries | Assistant audit logs where the product exposes them | Correlate click time to memory change time |
| Assistant sessions started from an external referrer that then call connected tools or fetch external URLs | Assistant and agent telemetry (AML.M0024 AI Telemetry Logging and Monitoring) | Highest-risk pattern for data loss |
| Web pages in your own estate embedding assistant deep links | Website and CMS content scans | Catches plugins that add "Summarize with AI" buttons with appended instructions |
Metrics
- Coverage: share of email, chat and web traffic where assistant URL parameters are extracted and decoded.
- Hits per week: crafted-link detections, split by persistence, exfiltration and benign share.
- Click rate: share of detected links that users opened, a measure of awareness effectiveness.
- Memory review completion: share of flagged users whose assistant memory was reviewed after a click.
- Time to block: hours from first detection to a block or rewrite rule for a new generator pattern.
Mitigations
ATLAS lists no mitigation mapped directly to AML.T0131 in the ATLAS 2026.10 data. The controls below draw on adjacent ATLAS mitigations and the case study guidance.
| Control | ATLAS reference | What to do |
|---|---|---|
| User awareness | AML.M0018 User Training | Teach users to hover over AI buttons, read pre-filled prompts before running them, and distrust "Summarize with AI" links from unknown sites |
| Memory protection | AML.M0031 Memory Hardening | Where the product allows, restrict or disable persistent memory for sensitive roles, and review and clear saved memories after a suspected click |
| Guardrails on input | AML.M0020 Generative AI Guardrails | Builders: treat URL-supplied prompts as untrusted, show them for confirmation instead of auto-submitting, and block persistence instructions from that channel |
| Tool restriction | AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data | Require confirmation for tool calls in sessions that began from an external link |
| Human approval for consequential actions | AML.M0029 Human In-the-Loop for AI Agent Actions | Sending mail, sharing files and calling external URLs should need explicit user approval |
| Logging | AML.M0024 AI Telemetry Logging and Monitoring | Capture session origin, memory writes and tool use so a link can be traced to its effects |
Organisation controls
- URL rewriting and detonation: extend email and chat link protection to parse assistant URLs and flag or strip prompt parameters that match the persistence and exfiltration patterns above.
- Proxy policy: where enterprise assistants are sanctioned, consider blocking or warning on requests to assistant domains that carry prompt parameters from external referrers. Test in monitor mode first, since some internal tools rely on share links.
- Browser controls: managed browsers can warn on assistant deep links or route them to an interstitial that shows the decoded prompt. See the Browser Security Hardening Guide.
- Your own websites: remove "Summarize with AI" plugins that append instructions beyond the summarisation request; ATLAS records that the case study operators were legitimate businesses using marketed tooling.
- Least privilege for assistants: narrow which mailboxes, drives and connectors an assistant can reach, so a hijacked session has less to expose. See the Enterprise AI Copilot Security Guide.
Decision guidance
- Small organisations without a mail gateway that parses URLs: focus on awareness, memory review and limiting assistant connectors.
- Organisations with a sanctioned enterprise assistant: add assistant URL parsing to email and proxy detection, and align assistant admin settings for memory and connectors to role sensitivity.
- Organisations building their own assistant: do not auto-submit URL-supplied prompts, label them as externally supplied in the interface, and keep safety checks active for every turn in the session.
Where identity fits
A crafted link runs under the user's authenticated session, so the assistant acts as that user, with their delegated access to mail, files and connected SaaS. Treat the assistant's connectors as delegated non-human access: inventory the OAuth grants and service connections it uses, scope them to what each role needs, and log their use. The AI Agent Memory Poisoning Guide covers the persistent state side.
How to test
- Inventory deep-link behaviour: for each sanctioned assistant, record whether URL prompts are pre-filled only or auto-submitted, and whether memory and tools are available in such sessions. Check vendor documentation, as behaviour changes.
- Benign canary prompts: in an authorised test, send links whose prompt asks the assistant to repeat a harmless marker, and confirm detection fires in email, chat and proxy logs.
- Memory review drill: confirm that the service desk can guide a user to view and delete saved memories in each sanctioned assistant.
- Red team scope: include crafted links in AI red team exercises (AML.M0035 AI Red Team), using harmless objectives and written authorisation.
Response
- Scope: find all recipients and clickers of the link from email, chat and proxy logs.
- Contain: block the link pattern at gateway and proxy, and remove the message from mailboxes.
- Clean memory: have affected users, or administrators where the product allows, review and delete memory entries created after the click.
- Check for data access: review the assistant's tool and connector activity in the affected sessions; if data left, follow the Prompt Injection Incident Response Playbook.
- Report: notify the assistant vendor where behaviour bypassed its safeguards.
Common failure patterns
- Trusting the domain: URL reputation passes the link because it points at a real assistant domain.
- Not decoding parameters: detection rules match raw URLs and miss percent-encoded or base64 prompts.
- Ignoring memory: the session is closed but the planted memory entry keeps shaping answers weeks later.
- Auto-submitting URL prompts in in-house assistants: the user never sees what ran.
- Checking only the first turn: Varonis's Reprompt research showed follow-up requests escaping safeguards applied to the initial prompt.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0131 in AML.TA0004; AML.T0078; case study AML.CS0072 | The technique, its drive-by sibling and the documented case |
| MITRE ATLAS follow-on | AML.T0080.000 Memory; AML.T0130 AI Agent Response Biasing | Outcomes recorded in the case study |
| MITRE ATT&CK | T1204.001 Malicious Link; T1566.002 Spearphishing Link; T1189 Drive-by Compromise | Enterprise analogues for delivery and execution |
| OWASP Top 10 for LLM Applications 2025 | LLM01:2025 Prompt Injection | The underlying vulnerability class |
| NIST SP 800-53 Rev. 5 | AT-2, SI-8, SI-4, SI-10 | Awareness, spam and link protection, monitoring, input validation |
| NIST CSF 2.0 | PR.AT-01, DE.CM-01, DE.CM-09 | Awareness and monitoring |
Practitioner checklist
- List sanctioned assistants and record how each handles URL-supplied prompts, memory and tools.
- Extract and decode assistant URL prompt parameters in email, chat and proxy logs.
- Alert on persistence and exfiltration keywords in those parameters.
- Correlate link clicks with assistant memory writes and tool calls where logs allow.
- Train users to read pre-filled prompts and to be wary of "Summarize with AI" buttons.
- Give the service desk a memory review procedure for each sanctioned assistant.
- Limit assistant connectors and require approval for sending and sharing actions.
- In assistants you build, never auto-submit URL prompts and keep checks on every turn.
Standards and references
- MITRE ATLAS: Crafted AI Assistant Links
- MITRE ATLAS: AI Recommendation Poisoning via Crafted AI Assistant Links
- MITRE ATLAS: Drive-by Compromise
- Microsoft Security: Manipulating AI memory for profit: The rise of AI Recommendation Poisoning
- Varonis: Reprompt, the single-click Microsoft Copilot attack
- OWASP: LLM01:2025 Prompt Injection
- MITRE ATT&CK: User Execution: Malicious Link
Related NHI Mgmt Group resources: Prompt Injection Guide · Zero Click AI Agent Exploits · AI Agent Memory Poisoning Guide · MITRE ATLAS AML.T0051 LLM Prompt Injection · MITRE ATLAS AML.T0053 AI Agent Tool Invocation · MITRE ATLAS Guide