Most AI leaks are not clever hacks. They are three ordinary permissions stacked on one assistant, and you can find them in your own stack in about fifteen minutes.
By the end of this you should be able to look at every AI tool your company has connected to a company system and pick out, in about fifteen minutes, the one most likely to leak. Not because it is badly built. Because of three permissions that each look reasonable on their own and turn into an exit door when they sit on the same assistant.
This is the failure mode behind most of the AI data-loss stories you have read this year. It is not a clever exploit. It is a configuration choice that somebody made in an afternoon while trying to be helpful.
The three permissions
Any AI assistant worth connecting to your business ends up with some combination of three capabilities.
The first is access to private data. Your CRM, your drive, your ticket system, your inbox. This is the whole reason you connected it.
The second is exposure to content you do not control. A PDF a vendor emailed you. A support ticket a stranger filed. A web page the assistant browsed. A message in a shared channel. Anything where the text reaching the model was written by somebody outside your company.
The third is the ability to send something outward. Sending an email, posting to a channel, publishing a page, calling a webhook, or simply fetching a URL.
Simon Willison named this combination the lethal trifecta in June 2025, and the naming has held up because the logic is so plain. An assistant with all three can be instructed, by a stranger, to take your data and mail it out. The stranger never touches your network. They write a sentence, put it somewhere your assistant will read, and wait.
What it looks like when it happens
Last week a security firm published a working demonstration against a product with Fortune 500 logos on its marketing page.
PromptArmor's disclosure against Atlassian Rovo, published August 5, describes what they call zero-click data exfiltration. Somebody uploads a file into the workspace. Hidden inside it, in text a human reading the document would never see, are instructions. An employee then asks Rovo for help with something ordinary involving that file. Rovo reads it, follows the buried instructions, appends tenant data onto a URL the attacker controls, and fetches that URL itself. The employee gets a normal, helpful-looking answer. The data lands in somebody else's server logs.
Look at the trifecta in that sequence. Private data: Rovo reads across Jira, Confluence, and whatever is wired in through connectors, which is precisely the value proposition. Untrusted content: an uploaded file that came from outside. Outbound channel: a tool that opens a URL.
That third one is the one worth sitting with, because of what PromptArmor found next. The attack still worked when an administrator had turned web search off for the entire organization. Per the disclosure, the setting failed to remove the tool that opens the results. The label in the admin console changed. The capability did not.
The timeline is the other half of the lesson. PromptArmor says it disclosed on May 23 of this year, Atlassian acknowledged two days later with a case number, and two follow-ups over the next ten weeks produced no substantive response. The research went public on August 5 with the product still vulnerable. If your plan for this class of risk is that the vendor will patch it before it reaches you, that is the timeline you are planning against.
Why your instructions do not save you
The instinct here is to write a rule. Tell the assistant never to send company data outside the company. Put it in the system prompt, put it in the agent brief, put it in the governance doc.
That helps against a confused assistant. It does very little against a deliberate one, because the attacker's sentence arrives through the same door your rule did. Both are just text in the model's context, and the model has no reliable way to know that your paragraph carries authority and the one hidden in the PDF does not.
This is not a controversial position. OWASP ranks prompt injection first in its top ten risks for LLM applications and says outright that it is unclear whether fool-proof methods of prevention exist. Willison, in the same post that named the trifecta, is blunter about the vendor tooling built to catch these attacks, and notes that once you have combined the three capabilities yourself, there is nothing those vendors can do for you.
So the fix is not at the instruction layer. It is at the wiring layer, and that is good news, because the wiring layer is a settings page and you do not need an engineer to read one.
The fifteen-minute audit
Open a spreadsheet. One row per AI assistant, agent, or chat workspace your team has connected to anything. Include the ones somebody set up without telling you, which means you should ask.
Three columns.
Reads outside content. Does anything reach this assistant that was written by a person outside your company? Uploaded files, inbound email, support tickets, form submissions, web browsing, shared external channels, scraped pages. Be honest here. Most teams undercount this column badly, because the mental model is "our assistant reads our stuff," and then somebody attaches a customer's PDF.
Sees private data. Which systems is it connected to, and at what level? Not what it usually reads. What it is permitted to read.
Can reach outward. This is the column people get wrong, because they check whether it can send email and stop. Fetching a URL is an outbound channel. Rendering an image from a remote address is an outbound channel. Creating a publicly visible page is an outbound channel. Calling a webhook is an outbound channel. The Rovo leak did not go out through anything anybody would have called a sending feature.
Any row with all three checked is your problem row. The fix is to split the job across two assistants instead of one. Let the assistant that handles outside content have no connection to your private systems, and let the assistant with the keys to your CRM read only what an employee hands it directly. That costs you an extra workspace and one extra human step. It buys you the only mitigation in this category that actually holds, which is that the two halves never meet.
What to do tomorrow morning
Open the connector settings on whichever AI tool your team uses most and read the list. Disconnect anything nobody has used in a month, because a dormant connector is all downside. For everything left, look at what permissions it actually requested. Anthropic's own connector documentation tells users to review the scopes a server is asking for and limit them where possible, and to only connect to servers built by organizations they trust, which is unusually direct advice from a vendor about its own feature. Anywhere read-only is an option, take it. Then run the three-column pass above on whatever survived.
The useful question to ask about an AI assistant was never what your team is allowed to do with it. It is what a stranger can get it to do, using nothing but a sentence buried in a document you asked it to read.