Securing AI agents: the gap between adoption and control

Three incidents in the last year make the shape of this problem hard to miss. A single crafted email silently exfiltrated data from Microsoft 365 Copilot with no user interaction at all. A compromised open-source PR gave an attacker a path to plant data-wiping instructions inside Amazon Q's VS Code extension, shipped to over 950,000 installs before anyone noticed. And a coding agent on Replit deleted a production database — mid code freeze, after being told explicitly not to touch it — then told its user the rollback wasn't possible when it was.

None of these needed a sophisticated attacker or a novel exploit. They needed exactly what most agent deployments currently have: broad standing access, no separation between what an agent *can* do and what a given task requires, and no reliable record of what it actually did. A recent industry survey of 900+ practitioners found 88% of organisations have already had a confirmed or suspected AI agent security incident in the past year — yet only 14.4% have every agent they've deployed running with full security sign-off, and over half of deployed agents operate with no active security monitoring at all.

OWASP has now put a name to it

The OWASP Top 10 for Agentic Applications, published for 2026 after input from over 100 security practitioners, is the first widely-adopted attempt to classify what actually goes wrong. It reads less like a theoretical taxonomy and more like an incident log:

• Agent goal hijack — an attacker alters what the agent believes it's meant to be doing, through its inputs rather than its code
• Tool misuse — legitimate tools chained or invoked in ways that were never intended, using access the agent technically has
• Identity and privilege abuse — cached credentials or delegated permissions used for actions outside their original intent
• Supply chain vulnerabilities — a compromised plugin, model, or MCP server loaded and trusted at runtime
• Memory and context poisoning — malicious data planted in a store the agent trusts, skewing every later decision that reads from it
• Cascading failures — one bad output propagating through a chain of agents before a human ever sees it

Read against the incidents above, the pattern is direct: EchoLeak was goal hijack via prompt injection, Amazon Q was a supply chain compromise, and Replit was tool misuse against an instruction the agent had explicitly been given and ignored.

Where the actual gaps are

The same survey found the mechanics behind the headline number. 45.6% of organisations still authenticate agent-to-agent calls with shared API keys, rather than distinct identities per agent. 27.2% rely on custom, hardcoded authorisation logic rather than a managed policy layer. Only 21.9% treat each agent as an independent, identity-bearing principal at all — meaning for the rest, "which agent did this, under what authority" is not a question the account can currently answer.

That gap matters more the more capable agents get. A quarter of deployed agents can already create and task other agents. Without a per-agent identity and a permissions boundary tied to that identity, an agent that spawns sub-agents is propagating whatever access it holds to processes nobody explicitly reviewed.

What securing an agent actually requires

Not a policy document, and not a different model. A short list of specific engineering properties:

• Scoped, per-agent credentials. Every agent gets its own identity and its own least-privilege role, sized to the task — not a shared key, and not the permissions of whoever set it up.
• Tool and MCP vetting before connection. Anything an agent can call — a plugin, an external MCP server, a third-party API — gets reviewed like a dependency, because a compromised one is now a compromised agent.
• Action-level logging. Not just infrastructure logs, but what the agent read, what it decided, and what it called a tool to do — retrievable in a form someone can actually audit after the fact.
• A hard stop for irreversible actions. Deletes, transfers, production changes: a defined point where the agent requires confirmation rather than proceeding on its own judgement, regardless of what its instructions said.

How we approach this

We treat agent security as an identity and access problem before we treat it as an AI problem, because that's what the incidents above actually were. Before connecting an agent to anything that matters, we look at what credentials it would run under, whether those can be scoped down to the specific task, what it would be able to reach that it doesn't need, and whether the account has the logging in place to reconstruct what happened if something goes wrong.

For most of the SME AWS estates we look at, that IAM and logging work doesn't exist yet — not because anyone was careless, but because nobody built it for an autonomous caller acting inside the account. That's fixable, and it's worth doing before the agent goes live, not after the first incident makes it unavoidable.