AI agents have moved from demos into production faster than the controls around them. This month’s reports put numbers on that gap, and they are worth reading by anyone planning to launch an agent in a regulated organisation.

What the numbers say

On 13 October Salt Security published its State of Agentic AI and API Security 2H 2026, based on a survey of over 380 security and technology professionals combined with telemetry from its customer environments. The headline findings:

  • 49.8% of respondents confirmed or suspected that an AI agent in their organisation took an action in the past 12 months that the organisation did not intend, expect or authorise. More than half of those reported an unauthorised external API call or transaction, and more than 40% reported an agent that modified or deleted data.
  • Only 12.5% can consistently trace a complete agent path across all agents, and more than 60% would need hours or days of manual work to reconstruct what a specific agent did the previous day.
  • Only 17.5% can automatically stop an agent that begins behaving unexpectedly in production.
  • 32.9% have found an unauthorised, shadow or misconfigured MCP server in the past 12 months, and 54.3% confirmed or suspected one.

The same picture appears in Gravitee’s State of AI Agent Security 2026, written by Jorge Ruiz in February from a survey of over 900 executives and technical practitioners: 45.6% of teams still rely on shared API keys for agent-to-agent authentication, and only 21.9% treat agents as independent, identity-bearing entities. In the UK, the Information Commissioner’s Office opened a call for evidence on agentic AI on 8 October after reports of agents bypassing protections and using unauthorised communication channels, with a plain message from Richard Nevinson, its Director of Technology Regulation: an agent’s autonomy is not an excuse for poor compliance.

A necessary caveat: Salt and Gravitee sell security products, and their definitions of an incident differ, so do not compare their figures directly. What makes the message worth attention is that they and a regulator point at the same gaps.

Five questions before launch

  1. Can the agent reach the internet at all? Most of the unauthorised actions in the reports were external calls. In an air-gapped deployment there is no network path out, so that whole class of incident is impossible by design, not by policy.
  2. Does each agent have its own identity and least-privilege access? A shared key means you cannot tell which agent did what. Bind every agent to your identity provider and grant it only what its task needs.
  3. Is every action logged and reconstructable in minutes? If tracing what an agent did yesterday takes a day of work, you cannot show it to an auditor. Every step needs a version and an immutable log.
  4. Who can stop it, and how? An automatic stop on unexpected behaviour is not a luxury. Define the triggers and the owner before launch.
  5. Which tools can the agent call, and who approved them? Unauthorised MCP servers are the new shadow IT. Keep an approved tool list, and block everything outside it.

How we build for this

These questions are why our stack puts a security control at each of its five layers: ingress, model, retrieval, action and operations. Agent actions run through approved tools only, every step is versioned, traced and reviewable, and all of it runs inside your environment with no external call. The agent is then evaluated on questions and tasks from your own operations before a single user sees it.

Sources

Related pages