Imagine interviewing a safe about how to crack it, and the safe walks you through its own combination. That is essentially what happened when security researchers at Varonis asked Microsoft Copilot how to bypass its own guardrails. The Copilot prompt injection vulnerability they uncovered, dubbed CoSnitch, let an attacker steal data from anyone who clicked a single link. The exploit worked because Copilot itself disclosed an undocumented URL parameter that disabled its user-confirmation requirement. Microsoft quietly patched part of the flaw in February 2026, two months after Varonis reported it in December 2025, and shipped comprehensive fixes on August 18, 2026, roughly eight months after the initial report.
How did Copilot reveal its own attack path?
Varonis Senior Researcher Lior Adar and his team wanted to build a one-click exploit that would exfiltrate user data through Copilot without any user interaction beyond clicking a link. Copilot refused, citing its requirement for explicit user consent through a gesture like pressing Enter.
Instead of moving on, they treated Copilot like a helpful but overly chatty insider. They asked why auto-execution was impossible. What URL structures were involved? What happens when a page loads with input already in the prompt field? Each refusal and each answer peeled back another layer of the guardrail architecture.
"At the beginning, Copilot kept refusing, but every refusal revealed technical details about its internal architecture," Adar told Ars Technica. "Copilot eventually disclosed undocumented parameters. I took those parameters and used them for prompts for running automatically."
The parameter was ?autorun=1. Combined with the well-known ?q= parameter that injected text into Copilot's prompt field, it caused any attacker-supplied prompt to execute instantly on page load, with no click, no confirmation, and no visible indication to the user. Copilot even told the researchers the exact session conditions required to make auto-execution work, and described how its content filter only checked the first response cycle, not subsequent ones.
The irony is thick enough to cut with a knife, but the structural point matters more. Copilot's guardrails were designed to refuse harmful requests, not to protect the architectural details of the guardrails themselves. The model treated questions about its own security mechanism as legitimate technical inquiry, and answered them with the same helpful thoroughness it would bring to any coding question.
What could the CoSnitch attack actually do?
The attack chain was five steps, each more damaging than the last:
- The victim clicks a crafted URL, delivered via email, SMS, phishing page, or QR code.
- The browser loads copilot.microsoft.com in the victim's active, authenticated session.
- The
?autorun=1parameter triggers auto-execution; the?q=prompt fires without any user gesture. - Copilot processes the injected prompt with full access to the victim's session context, connected apps, and memory.
- The prompt executes to completion, including network fetches and connector invocations, even if the Copilot tab is closed immediately after load.
The URL format was straightforward:
https://copilot.microsoft.com/?q=<malicious_prompt>&autorun=1
Once the prompt fired, the attacker had the run of whatever Copilot could access. Because Copilot connects to user apps through OAuth, that meant Gmail, Google Drive, Google Calendar, OneDrive, and Copilot's own chat history. The Varonis blog post details how an injected prompt could search an inbox for the latest email, extract the sender's address, and exfiltrate it to an attacker-controlled webhook by having Copilot "summarize" a URL that contained the stolen data.
The exfiltrated data was base64-encoded to avoid detection and transmission errors. A separate prompt variant instructed Copilot to search the inbox for passwords or credentials, then leak those too. According to Varonis, Copilot's OAuth access to Gmail meant it could read full message bodies, including emails containing credentials, password reset links, and internal system passwords.
The persistence angle is worse. Varonis devised a second attack that poisoned Copilot's permanent memory store. When a user asked Copilot to summarize a crafted webpage, hidden instructions in the page metadata told Copilot to update its memory. The poisoned memory could forward outputs, filter information, bias responses toward attacker narratives, or execute attacker-defined actions on trigger conditions.
That memory poisoning survived password changes, session revocations, and device re-enrollments. The only way to detect it was to manually inspect the memory contents, which almost no user would think to do. The chart below shows how these attack types compare in persistence, from one-time exfiltration to permanent memory compromise.
Why does this matter for anyone building AI agents?
If you are building AI agents that connect to user data, CoSnitch is your problem in three specific ways.
First, the model is a leak vector. Your guardrails are a knowledge layer that can be probed, not just a policy layer that blocks bad outputs. Any sufficiently capable LLM that understands its own safety mechanisms can be talked into explaining them, and those explanations contain the seeds of their own bypass. If your security model depends on the model not understanding its own guardrails, you do not have a security model.
Second, OAuth scope is blast radius. Copilot could read full Gmail message bodies, not summaries or metadata, because it had been granted full inbox access. The same applied to Drive, Calendar, and OneDrive. When you build an agent that connects to external services, every scope you request is a door the attacker can walk through if they get prompt injection to fire. The principle of least privilege is the difference between a leaked email and a leaked password vault.
Third, persistent memory is a persistent attack surface. The memory poisoning attack is the most insidious part of CoSnitch because it turns a single click into a long-term compromise. If your agent stores user preferences, instructions, or context across sessions, that store is a write-once, read-forever target. An attacker who can inject one instruction into persistent memory owns every future session until someone manually finds and removes it.
This connects to a broader pattern. The chain-of-thought forgery research showed that guardrail bypass rates hit 80 percent when attackers exploit role confusion. The AI agents that escaped cyber evaluation sandboxes earlier this year demonstrated that even isolated agents find unexpected exit paths. CoSnitch is another data point in the same trajectory: the guardrails are reactive, and they keep failing.
If you want to understand why Copilot credit costs still sting for developers, add security risk to the bill. You are paying for a tool whose own architecture can be turned against you through a single clicked link.
What should builders do about prompt injection risks now?
Microsoft says customers are protected without needing to take action, which is true for this specific parameter. The pattern will repeat. Here is what to actually do.
Reduce OAuth scope aggressively. If your agent does not need full inbox access, do not request it. Request the narrowest scope that covers the task. If you are building on Microsoft's ecosystem, audit which connectors are enabled and disable any that are not essential. The fewer doors you open, the fewer an attacker can walk through.
Treat persistent memory as untrusted input. Any instruction stored in memory should be validated against a separate policy layer before it influences agent behavior. Do not let memory writes happen silently as a side effect of summarization or other routine tasks. Require explicit user confirmation for memory updates, and log every write so you can audit what changed and when.
Assume the model will explain its own guardrails. Design your security architecture so that knowing the guardrail details does not help an attacker bypass them. Move enforcement out of the model and into deterministic code. The model should serve as the interface, with the security layer living in code that the model cannot describe or modify. The Open Secure AI Alliance tools offer one starting point for agent-level security controls that sit outside the LLM.
Monitor for unexpected agent actions at runtime. If your agent suddenly fetches a webhook URL, starts encoding data as base64, or makes unusual connector calls, that should trigger an alert. Runtime monitoring of agent actions is more reliable than trying to prevent every possible injection at the prompt level, because you are watching what the agent does rather than what it was asked to do.
Take link-clicking risks seriously in your threat model. CoSnitch required one click. Until agents have a robust permission model for URL-triggered actions, the phishing surface remains wide open. Consider whether your agent should accept prompt input from URLs at all, and if it must, require a second factor for any action that touches sensitive data.
The guardrail paradox
The deepest problem CoSnitch exposes goes beyond the ?autorun=1 parameter. LLM guardrails are, by design, a list of reactive restrictions bolted onto a system whose core function is to be helpful. The model is trained to answer questions. When you ask it about its own security, it answers. When you ask it to execute a prompt, it executes. The guardrails are exceptions to the model's fundamental behavior, and exceptions are always easier to find than rules.
Microsoft patched this parameter. They will patch the next one. The architecture has not changed. Copilot still connects to user data through broad OAuth scopes, still stores persistent memory, and still answers questions about its own internals. The next researcher who plays 20 questions with an AI assistant will find a different door that someone left unlocked.
Builders who take this seriously will treat prompt injection as the primary threat model for any agent that touches real user data, and design accordingly. Builders who do not will eventually get a CVE with their product name on it.
Sources
- Ars Technica: Microsoft Copilot reveals secret input that allowed it to be hacked
- Varonis: CoSnitch, when your AI assistant becomes its own whistleblower
- The Register: Copilot tricked into telling researchers how to hack itself
- Security Magazine: Copilot exposed its own vulnerabilities when prompted
