Path & Payload

AI Assistants Need a Different Threat Model: Why AI Security Doesn't End With Permissions

In August 2026, Varonis Threat Labs disclosed three vulnerabilities in Microsoft Copilot Personal that it collectively named CoSnitch. A single crafted link was enough to trigger the attack. Once a victim clicked, Copilot queried the connected services the user had previously authorized — pulling email bodies, subject lines, sender and recipient metadata, calendar titles, attendees and locations, file names and summaries from Google Drive, prior conversation history, and the stored instructions held in the user's memory store. It encoded the results in base64 and delivered them to an attacker-controlled webhook using the same URL fetch Copilot performs when it summarizes an ordinary web page. The chain completed without a confirmation dialog, error message, or visible anomaly.

No credential was compromised, and no permission was escalated. There was no connected service that was breached. The attack simply used the access Copilot already had, through the channels Copilot was designed to use.

The Assistant Performed the Way It Was Designed To

CoSnitch combined two URL parameters: the existing q parameter, which pre-fills Copilot's input box, and an undocumented autorun=1 parameter that caused the prompt to fire on page load without a user gesture. Together, they caused an attacker-supplied prompt to execute inside an authenticated session with the same capabilities as anything the user would have typed personally.

Querying connected mail and calendar accounts is what Copilot is designed to do. Fetching URLs is how Copilot summarizes web content. Encoding output is routine. The exfiltration request is, at the network layer, indistinguishable from the fetches Copilot performs during ordinary operation. The attacker didn't need to supply new privileges or malicious code, simply instructions, a trigger and an exfiltration destination. The assistant provided the rest.

This is important to note because patching the trigger mechanism — closing the autorun=1 parameter, which Microsoft did on August 18 — doesn't change the underlying architecture. A different trigger that gets a prompt into an authenticated session will reach the same connected services through the same trusted interface.

The Assistant Can Be Part of the Reconnaissance

The autorun=1 parameter wasn't found through code review or fuzzing. Varonis researchers asked Copilot directly why a prompt couldn't execute without user interaction. Copilot refused, multiple times, to supply an answer — but each refusal carried a technical justification that provided a bit more insight. The researchers kept asking. Eventually, Copilot named the parameter, described the session conditions under which it worked, and identified the protections that were supposed to have disabled it. When the researchers built the URL exactly as described, it executed.

Varonis summarized the approach aptly: Copilot “wasn't breached; it was played.”

The attack vector was surfaced by interrogating the assistant about its own architecture. Copilot had accurate operational information about the system surrounding it, and the attacker’s persistent questioning extracted enough of that information to construct an exploit.

Three Assistants, One Month, the Same Pattern

Less than two weeks before CoSnitch was disclosed, the same research team presented RovoBlast at DEF CON 34. The target was Atlassian's Rovo enterprise AI assistant. The mechanism was Rovo's rovoChatPrompt URL parameter, which pre-loaded attacker instructions into a signed-in user's live session.

What Rovo could reach through that session was substantial. The assistant spans Jira, Confluence, Bitbucket, and connected third-party tools including Slack, Microsoft 365, and Google Workspace. Its ResearchAgent capability runs multi-step tasks across those sources autonomously. In the proof of concept, it retrieved internal data, transformed it, and delivered it externally — all in a single agent run that generated an audit trail resembling ordinary research activity.

Varonis's January 2026 Reprompt research used Copilot's q parameter for the same one-click primitive. Three disclosures involving two assistants, with the same underlying attack shape.

Grok demonstrates that the entry point doesn't have to be a link — an ordinary summarization request is enough. Adversa AI's Cryptographic Context Injection technique hides attacker instructions as AES-encrypted ciphertext on a web page. When a user asks Grok to summarize that page, Grok's Python sandbox decrypts and executes the instructions as trusted context — exfiltrating the user's name, approximate location, subscription tier, and current conversation history to an attacker-controlled server. The trigger isn't a link, but instead an ordinary summarization request. Adversa reported the technique to xAI in June 2026. As of August 19, 2026, it remained unpatched, with a reported 40% success rate across testing — the failures attributed to Grok struggling with decryption rather than detecting the attack.

The entry points vary — URL parameters, encrypted page content, summarization requests — but these attacks share a similar structure: a promptable AI assistant with broad connected access, a mechanism for injecting untrusted instructions into a trusted session, and the assistant's own capabilities as the exfiltration channel.

Varonis noted parallels to earlier research in the same class: SearchLeak, EchoLeak, ShadowLeak, and Antigravity. The research community has been mapping this territory longer than recent headlines suggest.

Memory Is a Persistence Surface

The third CoSnitch vector has the longest operational shelf life. A crafted web page, when summarized by Copilot, can cause the assistant to write attacker instructions into the user's persistent memory store. Those instructions survive password changes, session revocation, and device re-enrollment. They produce no process, file, network connection, or log entry that security tooling would flag. They remain active in subsequent sessions until the user manually audits their Copilot memory settings and removes them.

Johann Rehberger documented memory writes and deletions through indirect prompt injection in Microsoft 365 Copilot (CVE-2026-24299). Håkon Måløy documented M365 Copilot memory poisoning via a summarization flow, publishing after a 90-day coordination period in June 2026. Microsoft's response for M365 — audit log visibility through a MemoryUpdated field in Defender Advanced Hunting and Sentinel — applies to the enterprise product only. Consumer Copilot, where CoSnitch landed, carries no equivalent forensic trail.

AI assistant memory stores are a persistence surface. Most threat models don't include them yet, and the detection tooling that does exist is unevenly distributed across product tiers.

What the Permissions Audit Misses

The permissions question — what can this AI assistant access? — is finally getting attention. But in this type of attack, the problem isn't only the permissions. It's that the assistant hands an attacker a single interaction that can reach multiple authorized systems, through a trusted channel, without touching any individual service's access controls.

When Rovo processes a single prompted query, it can search Jira, Confluence, Bitbucket, Slack, Google Workspace, and Microsoft 365 in a single agent run. When Copilot handles a session, mail, calendar, Google Drive, and chat history are simultaneously in scope. From the attacker's perspective, the assistant collapses multiple authorized systems into one queryable control surface.

Security teams reviewing AI assistant deployments are generally asking “What does this assistant have access to?” That's an important question, but not the only one that needs to be asked.

The Threat Model Needs Different Questions

Access scope is only one dimension of this threat surface. Trigger mechanisms, behavioral visibility, audit coverage, and persistence are the others — and they don't show up in a standard access review. These are the questions that address them.

Who can trigger the assistant, and through what entry points?

URL parameters, summarization requests, document processing, and email ingestion are all injection surfaces. A correctly scoped permission set doesn't prevent an attacker from seeding a prompt through a crafted link, a poisoned document, or a web page the assistant is asked to summarize. Identifying every interaction type that causes the assistant to handle attacker-controlled content is the first step toward understanding the actual attack surface. That surface is larger than most teams have modeled.

What does the assistant do during a session, and does anyone see it?

The exfiltration request in CoSnitch was indistinguishable at the network layer from an ordinary Copilot URL fetch. Rovo's ResearchAgent ran multi-step retrieval and external delivery in a single run that generated an audit trail resembling normal research activity. Behavioral monitoring of assistant-initiated actions — what it queried, what it returned, where it sent output — is the detection response to the aggregation problem.

What audit visibility actually exists for your assistant's actions?

This varies significantly across products and tiers. Microsoft 365 Copilot surfaces memory writes through a MemoryUpdated field in Defender Advanced Hunting and Sentinel. Consumer Copilot carries no equivalent forensic trail. Rovo logs assistant activity, but activity that resembles ordinary research doesn't trigger investigation. Before assuming that AI assistant actions are visible to your security team, verify what the assistant's action log actually contains — and whether anyone is watching it.

Is the memory store in your threat model?

For most teams, the answer is no — and the CoSnitch memory write vector makes that a meaningful gap. An injected memory entry that survives password changes, session revocation, and device re-enrollment, produces no forensic artifact, and persists until manual removal is a persistence mechanism. It belongs in the same threat model as other persistence techniques, not in a separate mental category of “AI assistant settings.”

Reducing connected app permissions is still worth doing. It limits the blast radius of any successful injection, regardless of how the prompt was seeded — and Varonis's guidance for Rovo was direct on this point: the less the assistant can see, the less it can leak. But that's a blast-radius answer. It addresses how much a successful attack can return. It doesn't address who can trigger the assistant, through what entry points, with what instructions, or whether anyone can see what happens next.

The Bottom Line

CoSnitch and RovoBlast are patched, while Grok isn't. But the underlying design pattern — AI assistants that aggregate broad connected access behind a single promptable interface, treat their session as trusted, and use their own built-in capabilities as the exfiltration channel — isn't something a parameter fix can close.

What's being documented isn't only a series of product vulnerabilities. It's a class of risk that emerges specifically from the combination of agentic capability, broad connected access, and the assumption that session context is trusted. Security teams that haven't modeled AI assistants as high-privilege exfiltration surfaces — and haven't asked who can reach their assistants, through what triggers, and with what instructions — are behind the research on this one.

Sources

#Perspectives