In June 2025, researchers at security firm Aim Security disclosed a flaw in Microsoft's AI assistant built into Word, Excel, Outlook, and Teams. Named EchoLeak, it allowed an attacker to steal internal company data with a single email — no click from the victim, no attachment opened, no command typed.
The mechanism is simpler, and more unsettling, than a traditional virus. The email carried no malicious program. It carried a piece of text written to look like a legitimate instruction, which the assistant read alongside everything else — and obeyed as if it had come from the company itself.
This type of attack has a technical name: indirect prompt injection. And according to the United Kingdom's cybersecurity agency, it is a structural problem companies will need to manage for a long time, not an isolated bug someone will simply patch away for good.
The difference from an ordinary security flaw is subtle, but it matters. A virus exploits a coding mistake that, once found, can be fixed and closed. Hidden text inside a message exploits the very way an AI assistant works: it reads everything it receives — email, page, document, spreadsheet — as one continuous stream of words, with no clean line between "this is information" and "this is an order." Closing that gap for good would mean changing that trait at the root, not just applying a one-time patch.
The case that exposed the risk
The flaw was assigned the identifier CVE-2025-32711 and a near-maximum severity score on virtually every scale the industry uses. The attack exploited a feature of Microsoft's assistant: it automatically pulled relevant information from a company's documents and conversations to answer with more precision.
The problem was that the same mechanism couldn't tell a legitimate document from text planted by a stranger. An email only had to land in the inbox — without being opened — for the malicious content to enter the pool the assistant consulted, and effectively become an internal order.
According to Aim Security, the flaw would allow an attacker to automatically exfiltrate the most sensitive information from the assistant's corporate context, with zero interaction from the victim. The potential reach included chat history, files stored in the company's cloud, internal collaboration pages, and team messages — everything the assistant already had permission to consult on behalf of a legitimate user.
Microsoft confirmed the issue, applied a server-side fix, and stated it found no evidence of real-world exploitation before the patch. But the warning stood: a piece of text can disguise itself as a command, and the assistant has no way to tell the difference on its own. What saved the situation this time wasn't the assistant catching the trick — it was a researcher finding the gap before a real attacker did.
Why filtering suspicious phrases doesn't work
The most common reaction to a case like EchoLeak is to try to block dangerous words or text patterns before they reach the assistant. The UK's cybersecurity agency explains why that approach has a ceiling: under the hood, an AI assistant does not separate "this is an instruction" from "this is just content to read" — it processes everything together, in the same sequence. No word filter can cover the infinite ways of rephrasing the same disguised order.
Researchers at Brave showed how far this goes in assistants that browse the web on their own. They hid instructions inside images and in white text on a white background — invisible to a person, perfectly readable to the assistant. In tests, those hidden instructions made the agent open the victim's inbox, extract message subject lines, and send that data to an attacker-controlled address.
Other researchers cited by The Register managed to manipulate browsing assistants into ignoring a document's real content and answering with a predetermined text instead, or into switching the page's display mode without the user asking for it. The security chief at one of the world's largest AI companies publicly admitted that this kind of attack remains, in his words, "a frontier, unsolved security problem."
What has to be in place
If filtering text doesn't work, the defense has to come from somewhere else: limiting what an agent can do on its own, even after it has already been fooled.
Minimum permission per function. An agent that only answers questions about internal policy doesn't need access to send email, move money, or change records. The smaller each agent's blast radius, the smaller the damage a hidden instruction it happens to obey can cause.
A mandatory stop before any sensitive action. Sending a document outside the company, approving a payment, changing a permission — none of that should happen just because some piece of text asked for it. It should pause and wait for a person's confirmation, right inside the conversation.
A personal credential per tool. When an agent uses the same password shared across a whole team to reach a system, a hidden instruction inherits that same generic, ownerless access. With a personal credential, what the agent can do on someone's behalf is limited to what that specific person can do.
A log of everything the agent tried to do. Even when the defense works and the sensitive action is blocked, someone needs to be able to look back and answer: what did this agent try to do, when, and because of which content. Without that trail, an attack attempt disappears without a trace — even when it failed.
This is how Skyller was designed: human approval before sensitive actions, access scoped to each person's role, and a personal credential per tool instead of one generic key shared by everyone.
What changes for day-to-day use
For people who use the assistant every day, these mechanisms don't show up as extra red tape — they show up as a single pause on a specific action, not approval for every message exchanged. The vast majority of everyday questions and answers keep flowing without interruption; it's only when the agent is about to do something that leaves the conversation itself — sending an email, touching a system, moving a file — that confirmation comes into play.
For the security team, the gain is different: instead of trying to guess every disguised phrase an attacker might invent — an impossible task according to the UK's own cybersecurity agency — the team gets to control what actually matters, which is the reach of each agent. An agent with limited access and sensitive actions under approval stays safe even on the day someone, somewhere, tries to slip it a hidden order inside a document.
That shift changes the conversation between IT and business leadership, too. Instead of asking "how do we stop anyone from writing a malicious instruction" — a question with no definitive answer, as both the Copilot case and the browsing-assistant tests show — the question that can actually be answered with confidence is "what can each agent do, even if it's fooled." It's a far more concrete question, and a far easier one to audit.
Questions to bring to your next security meeting
Before assuming "this doesn't happen here," it's worth putting concrete questions to the technical team:
- Do our AI agents have access to more systems than their task requires? If the answer is yes, every extra system is one more door for a hidden instruction to exploit.
- Is there any action the agent performs alone, without pausing for human confirmation, that would be serious if done by mistake? Sending data out, approving something, changing a permission — any of these deserves a mandatory stop.
- If an agent attempted a suspicious action today, is there a log to investigate afterward? Without an audit trail, even a successfully blocked attempt teaches nothing.
- Does any tool used by the agents run on a login shared across the team? If so, it's time to swap it for a personal credential before it becomes the next case cited in a security report.
