Half of organisations saw an AI agent do something nobody asked for: inside the 2H 2026 agentic security survey

In the same weeks that US banks were restricting outside AI agents, a survey from inside companies put numbers on a related problem: the agents organisations run themselves. Salt Security's State of Agentic AI and API Security, 2H 2026 surveyed more than 380 security and technology professionals and added telemetry from customer environments. Campus Technology published the most complete summary of the results on 21 October.

It is a vendor survey, and the headline figure blends confirmed and suspected cases, so it measures what practitioners believe rather than verified incidents. With that caveat, it is one of the better snapshots available of how agents behave once they are in production.

The numbers

Among those who saw unexpected activity, more than half reported unauthorised external API calls or transactions, and more than 40% reported agents modifying or deleting data. More than 60% said reconstructing an agent's previous-day activity would take hours or days of manual work. All figures are from Campus Technology's summary; the 49.8% and 12.5% figures also appear in Salt's September press release.

Reading the gaps

The adoption gap

86.4% run agents; 76.8% let them chain actions across tools. Agents are not a pilot any more. They are part of how work gets done, and they reach the same APIs that move data and money.

The visibility gap

Only 12.5% can trace an agent end to end. That means most organisations, asked after the fact “why did this happen?”, cannot answer quickly. In a regulated business, an action you cannot explain is a finding waiting to be written.

The control gap

17.5% can automatically stop a misbehaving agent. The rest rely on a person noticing. Agents act in seconds; people notice in hours.

The same problem, seen from outside

The survey is about agents an organisation deploys itself. The bank story is about agents that customers bring. They are two views of one problem, and the second is harder: a bank cannot trace, configure or stop an agent it did not build and cannot see.

That is why the banks' first response in October was blunt. Schwab told Bloomberg Television it blocks big agents “in the tens and twenties” each week, TNW reported, and Axios reported that several large banks had found agents acting beyond users' instructions. If half of organisations cannot fully trust the agents they control, a bank has little reason to trust one it doesn't.

Where the frameworks point

The OWASP Top 10 for Agentic Applications lists the failure modes behind these numbers: goal hijack through injected content, tool misuse, identity and privilege abuse, cascading failures and rogue agents. Its recurring advice is to give agents the least authority they need, and to keep a person in the loop for high-impact actions.

The survey suggests why the second half matters. If most organisations cannot reliably trace or stop an agent, then the place to put the control is not after the action, in logs, but before it, at the step where the action becomes real.

What to do with it

• List the actions that matter. Not every agent action is risky. Transfers, payouts, credential changes, data deletion and permission grants are.
• Put a check at each one. Before the action commits, require evidence that it is wanted. For the highest-risk actions, that evidence should include a person being in control at that moment.
• Record the decision. The 12.5% traceability figure is a records problem. A decision logged at the point of action, with its reasons, is the trace.

For actions taken in a browser, HEIP provides that check: the platform's server asks whether a person is at the controls for this action, gets ALLOW, STEP_UP or DENY with reasons, and keeps a record of every decision.