Only 37% of companies can take back an AI agent’s key. The risk isn’t in the model.

The cause isn't the model. In security, it isn't either

In August, Vicente Conde opened an issue of his newsletter with a number that is hard to forget: $4.3 million, which he presents as the average cost of a serious incident caused by an AI agent inside a company. His argument is that the next corporate AI crisis will come from words, not technology. The same term defined one way in each system, and an agent acting on it with nobody to review.

I agree. I just think that, when it comes to security, we can go one step further. The problem rarely lies in the model. It lies in the key they handed to it.

"Agent" has become an umbrella word, so let me be clear about what I mean. Not the chatbot that answers questions on a website. A program that receives a task and goes off to carry it out: it reads email, queries databases, opens tickets, moves files, calls other systems. To do any of these things it needs credentials. And in security, credentials have another name. Identity.

One hundred and nine to one

CyberArk, now part of Palo Alto Networks, surveyed 2,930 security leaders for the "2026 Identity Security Landscape", released in May. The headline figure: machine identities (service accounts, bots and AI agents combined) now number 109 for every human identity. A year earlier the ratio was 82.

What really bothered me came in the material on agents. Of the agents in use, 40% already access company data. Only 37% of companies can revoke an AI agent's credentials. And just 30% keep audit logs that no one can alter.

In boardroom terms: most companies handed over the key and don't know how to get it back. If something goes wrong, seven in ten will investigate without any guarantee that the record of what happened is intact.

The agent that obeys the wrong note

Picture a highly efficient employee with the building's master key who acts on any note left on his desk. If the note is from the boss, fine. If it was left by a stranger walking down the hallway, he acts on it all the same.

That is roughly what prompt injection is. The agent reads an email, a web page or a document carrying hidden instructions and executes them as if they were a legitimate order. OWASP, the foundation whose risk lists the industry uses as a benchmark, ranks prompt injection first among the risks of applications built on language models. In December 2025 it released a list devoted to agentic applications and singled out identity and privilege abuse among the core risks.

The analogy breaks down at one point, and that point counts against the agent: the employee sometimes finds the handwriting on the note odd. The agent, in many cases, has no way of telling data apart from instructions.

This is no longer theoretical. In June 2025, CVE-2025-32711 was published, a flaw in Microsoft 365 Copilot that NIST's vulnerability database describes as AI command injection, capable of allowing an unauthorized attacker to obtain information over a network. Microsoft itself rated it 9.3 out of 10.

Eight in ten have already seen an agent do what it shouldn't

In May 2025, SailPoint and Dimensional Research surveyed 353 IT and security professionals across five continents for the study "AI agents: The new attack surface". Eighty percent said their agents had already done something nobody asked for. Among those unintended actions, 39% involved access to unauthorized systems and 32% the download of sensitive content. And 23% reported that their agents had been tricked into handing over access credentials.

A policy to protect these agents? Only 44% had one.

The attack didn't go through the model. It went through the door next to it

If I had to pick a single data point to take to a CISO, or to a CTO who has just approved an agent project, it would be this one. In the "Cost of a Data Breach 2026", published by IBM in July with the Ponemon Institute, more than 20% of the 602 organizations studied reported breaches targeting AI models or applications. The most common causes had nothing to do with the model itself: compromised APIs, applications or plug-ins (27%) and cloud misconfiguration in AI workloads (27%).

IBM's own recommendation in the report is to run agents with restricted permissions, enforced continuously at runtime, with attribution to a human and an audit trail. Note that this is an identity recommendation.

In Brazil, the 2025 edition of the same study already showed the size of the gap: 87% of organizations had no AI governance policy and 61% had no access controls for AI. The average cost of a breach in the country came to R$ 7.19 million.

What Gartner expects to happen

Gartner has two forecasts pointing the same way. They are projections, not measurements, but they help show where things are heading. In 2024, the firm predicted that by 2028 a quarter (25%) of enterprise breaches will be traced back to the abuse of AI agents, by outsiders or insiders. In May 2026 it got more specific: by 2027, 40% of companies will downgrade or switch off autonomous agents because of governance failures that only surfaced after an incident in production.

The same analysis contains a sentence I wish I had written. According to Gartner, failure is most likely when a company does not separate what an agent is capable of doing from the scope of access it is given. That is the argument of this piece, put by an analyst.

Three decisions before you switch on the next agent

1. Every agent is an identity, and every identity has an owner. No agents running on the team's generic service account or, worse, on the personal credentials of whoever set them up. Its own identity, and a named human responsible for it.

2. What an agent can do is not what it may access. The agent that summarizes contracts does not need permission to delete the folder where they are stored. Least privilege, enforced at the moment of action, not just in the policy document. The Replit case, in July 2025, shows this well: the agent deleted a production database in the middle of a code freeze, and before it was an AI problem it was a permissions problem. It had write access where it shouldn't have.

3. You must be able to take the key back, and see what was done with it. Fast revocation and immutable logs look like technical details until the day of the incident, when they become the difference between containing the damage and investigating in the dark. I would add one thing: watch behavior. Agents have usage patterns, just as people do, and when one breaks its pattern, that is already a signal.

The question for the next demo

The next time someone shows you an agent doing in minutes what used to take days, whether a vendor or your own team, ask just one question: if I need to cut this agent's access at three in the morning, who does it, in how many minutes, and where do I see everything it did before?

According to CyberArk's numbers, only 37% of companies have that answer. The rest are hoping the agent never reads the wrong note.