What a security practitioner sees in AI builds

What to actually look at when an AI can use tools

Every agent in a recent DeepMind study was compromised at least once. Meanwhile 82% of executives believe their policies cover agents and 14% deploy them with security approval. Eight controls, and why most organisations have them in the wrong place.

An AI that writes you a paragraph and an AI that can send an email are not the same category of thing. We keep governing them as though they are.

The distinction is simple: an advisory system produces output a human then acts on. An agentic system acts. Once a model can invoke a tool, move money, modify a record or message a customer, the human review step that made advisory AI tolerable has been designed out — and everything downstream of that decision inherits the consequence.

The research position here is worse than most boards realise, and the gap between confidence and control is the story.

The confidence gap

Two findings, side by side.

82% of executives believe their existing policies protect agentic deployments. 14.4% of organisations actually deploy agents with full security approval. More than half of deployed agents run with no security oversight or logging at all.

That is not a small calibration error. Four in five leaders think they are covered; one in seven organisations is.

Underneath it sits an identity problem. 92% of large-enterprise security leaders report lacking full visibility into AI identities. 86% do not enforce access policies for them. 71% say AI systems have access to core business platforms — and 16% govern that access.

So: agents are in production, they can reach the systems that matter, and most organisations cannot enumerate them, let alone attribute an action to one.

Everything tested got compromised

Google DeepMind’s agent-security research, published in March 2026, ran attacks across agent architectures. The headline result is unambiguous: 100% of agents tested were compromised at least once.

The category-level numbers matter more than the headline:

  • Content injection succeeded in up to 86% of scenarios
  • Data exfiltration exceeded 80% success across five tested agents
  • Sub-agent spawning succeeded 58–90% depending on the orchestrator
  • Memory poisoning at 0.1% data contamination redirected agent behaviour 80% of the time
  • Microsoft 365 Copilot leaked privileged context in 10 out of 10 tests

Read the memory poisoning number twice. One part in a thousand of contaminated context was sufficient to redirect behaviour four times in five. That is not a system with a large tolerance for dirty inputs.

A separate NIST red-team exercise in February 2026 reported an 81% attack success rate. Different team, different method, same conclusion.

The lethal trifecta, and why it is your default architecture

Simon Willison — who named prompt injection back in 2022 — describes a lethal trifecta. An agent is exposed when it simultaneously has:

  1. Access to private data
  2. Exposure to untrusted content
  3. The ability to communicate externally

With all three, one poisoned input can cause data exfiltration without exploiting a single code vulnerability. Nothing is broken. The system does exactly what it was built to do, on instructions it should not have followed.

Now describe a normal enterprise AI deployment. A cloud LLM, connected to internal documents or email or a database, that can read web content or receive messages, and can send something outward.

That is all three. Not as an unusual configuration — as the standard one. This is not a future risk to monitor. It is the current default, and most organisations arrived at it without deciding to.

MCP is a supply chain, and it is not a clean one

The Model Context Protocol has become the common way agents connect to tools — reasonably described as the USB port of the agent world. The analogy holds further than its advocates intend, because USB was also a significant attack vector.

The credential picture:

MCP servers requiring credentials 88%
Using long-lived static secrets — API keys, PATs 53%
Using modern OAuth 8.5%
Public-internet MCP servers with no authentication 1,800+

Over half of the ecosystem is authenticating with static secrets that do not rotate and do not expire. Fewer than one in ten uses OAuth.

Two structural problems compound this. First, an MCP server can be safe today and modified tomorrow — a weather tool that ships an update which exfiltrates environment variables. Once it is in an agent’s approved toolkit, it operates inside the trust boundary. Second, the confused deputy problem: the MCP server executes with its own permissions, not the user’s, so an agent can reach systems the requesting user was never authorised to touch.

Version-pin your MCP servers. Maintain an approved registry and do not let agents connect to servers they discover. Run them in isolated execution. Replace static secrets with OAuth. And treat every connection as potentially hostile — this is ordinary supply-chain hygiene applied to a surface most organisations have not yet classified as a supply chain.

Most controls are in the wrong place

The agent kill chain has five stages: environment preparation, agent ingestion, instruction execution, persistence and propagation, objective completion.

Most organisations have controls at stage five — data loss prevention, incident response, network isolation. Those fire after the agent is compromised and acting.

The high-value interception points are stages one and two, before compromise: content sanitisation, input validation, MCP server vetting, domain reputation scoring, pre-ingestion scanning, sandboxed content processing.

This is the same argument as shifting security left in a build pipeline, and it lands the same way. Detection at the point of damage is the most expensive place to catch anything — and with agents it is worse, because the compression is brutal. The fastest adversary breakout time reported at RSAC 2026 was 27 seconds. Your incident response process does not run in 27 seconds.

The eight controls, and how they actually score

This is the scorecard I use. What is striking is not the list — it is how consistently the “commonly implemented” column reads no.

Per-agent identity. Standards exist — Entra Agent ID, Vertex, AgentCore IAM. Implementation is rare, and shared API keys across an agent fleet mean one compromise is all of them.

Human approval gates for consequential actions. Policy standard exists, no technical standard. Under 14.4% adoption. Watch for approval fatigue: a gate a human clicks through fifty times a day is not a control, and human-in-the-loop bypass is a documented attack category precisely because of it.

Least-privilege tool permissions. Well-understood principle, in the OWASP LLM Top 10. Nearly half of enterprises still use shared keys across fleets.

Structured decision-chain logging. OpenTelemetry GenAI semantic conventions define the standard. Over half of deployed agents have no logging, and most of what exists is unstructured and uncorrelated. Without this you cannot attribute an action, detect compromise, or meet a 48- or 72-hour notification window.

Plugin and MCP marketplace vetting. No enforced standard. See the 1,800 unauthenticated servers above.

Incident response for agent compromise. OWASP and CISA publish starting points. Almost no IR playbook covers an agent scenario — which means the first agent incident is also the first rehearsal.

A tested kill-switch. No standard, widely recommended, rarely implemented, almost never tested. Untested means unknown.

Behavioural baseline monitoring. The clearest gap in the market. At RSAC 2026, CrowdStrike, Cisco and Palo Alto were all identified as not shipping an agent behavioural baseline. Without one you cannot distinguish an agent doing its job from an agent doing its job under an attacker’s influence — and that distinction is the entire detection problem.

Where this is heading

Gartner projects that more than 40% of agentic AI projects will be cancelled by the end of 2027, attributed to governance failure rather than technical failure. Not because the technology does not work. Because organisations cannot demonstrate control over systems that act.

There is a hopeful data point worth holding onto: DeepMind’s CaMeL dual-LLM architecture neutralised 67% of attacks. Architectural separation works better than bolting detection on afterwards. That is a design decision, and it has to be made early.

If you are deploying agents, the fifth governance non-negotiable is the shortest version of everything above. No agentic system reaches production without a documented list of what it may and may not do, a human approval gate before consequential actions, tamper-evident decision-chain logging, a tested kill-switch with credential revocation, and a behavioural baseline.

And the clause I would fight hardest for: an agent operating beyond its permission scope is a security incident, not a configuration issue. Organisations that classify scope violations as drift close them as tickets. The ones that classify them as incidents find out early.


Attack findings are from Google DeepMind’s March 2026 agent-security research, accessed via DTA Advisory’s analysis — the underlying paper is not publicly linked. Survey data from Gravitee’s State of AI Agent Security 2026 and Cloud Security Alliance, April 2026. Threat taxonomy mapped against MITRE ATLAS v5.4.0. Figures are as assessed in April 2026.