Two releases, one collapse
The first was an emergency briefing from four security organisations after an AI system generated 181 working exploits against a mainstream browser in testing — ninety times the previous best — with a success rate above seventy percent. Around it, the briefing catalogued the pattern: an autonomous system topping a bug-bounty leaderboard, a government challenge finding fifty-four vulnerabilities across fifty-four million lines of code in four hours, a model provider disclosing a state-sponsored group had used its models in an espionage campaign. By the briefing’s metric, the average time between a vulnerability’s disclosure and its exploitation has fallen from over two years in 2019 to less than a day.
The second was quieter and, for most organisations, closer to home. A survey of 445 IT and security professionals found that 53 percent had seen an AI agent exceed its intended permissions and 47 percent had already handled a security incident involving one. Half said their agent policies were only partially documented; 31 percent had formally adopted any. Only 16 percent were highly confident of detecting an agent-specific threat.
One of the report’s contributors put the shift in a sentence: for years the AI security conversation was about prompts; the real question is “why did the agent do that?”
“Exceeded its intended permissions” is a revealing phrase
Read it carefully. Half of organisations have watched an agent do something outside what they meant it to do. Not outside what it was allowed to do — outside what was intended. The gap between those two words is the whole problem, and it is not an AI problem. It is how permissions have always worked.
Enterprise systems grant access to accounts, not to tasks. A service account that can read the customer table can read all of it, for any purpose; a user credential that can raise a ticket can raise any ticket. When a person holds that credential, intent is enforced by their judgment and their job description. When an agent holds it, there is no judgment — only the credential — and the “intended” scope exists nowhere in the system. The agent did not exceed its permissions. It used them.
The fix follows directly, and it is a data-platform fix before it is an AI fix. Intent has to become a permission: row- and column-level access scoped to the task, service identities per agent rather than shared credentials, write access limited to the specific records and fields the job description names, and time- or budget-bounded grants rather than standing ones. Organisations that already run fine-grained access on the warehouse have most of the machinery. The work is extending it to the agent as a first-class identity.
Answering the question
“Why did the agent do that?” can only be answered if the evidence exists, and the survey’s detection-confidence numbers suggest it mostly does not. A transcript of the agent’s reasoning is not an audit trail; it is a story the agent told about itself. The audit trail is in the systems it touched: which rows it read from the warehouse (lineage), which record it changed in the ERP (change history), which ticket it raised and closed (the ITSM log), under which identity, at what time.
Wire agents through the governed paths and that evidence is produced as a by-product of the action — the same argument we make for humans. Let agents act through side channels and direct API calls, and the answer to “why did it do that” is a shrug and a screenshot of a chat window.
The other half: the window is now hours
The exploitation figure changes something for data platforms specifically. A warehouse, a catalog, a set of connectors and the AI services around them are software with vulnerabilities like any other, and the assumption that a patch can wait for the next maintenance window was built for a world where exploitation took months. It now takes a day. The platform’s patch cadence, the connectors’ update discipline and the allow-list of what may reach the data are therefore security controls of the first rank — and the one place where the “agents finding exploits” story and the “agents exceeding permissions” story meet, because an agent with over-broad access to an unpatched platform is the exact scenario the briefing was written for.
Something to do this week
The briefing’s authors made a point of shipping a risk register with priority actions and start dates rather than commentary, because chief security officers needed it now. The equivalent for a data platform fits on a page: an inventory of every agent and the identity it runs under; the gap between each one’s intended scope and its actual permissions; the paths by which agents reach the platform, allow-listed or not; and the patch age of everything on that list. None of it requires new technology. All of it is the difference between being in the 53 percent and being able to explain what happened.
