AI agents now operate inside your perimeter with legitimate credentials, autonomous execution, and the ability to exfiltrate data, escalate privileges, or execute unauthorised transactions at machine speed. Your insider risk controls cannot catch this. They were built to detect humans, and agents aren’t human. Every UEBA baseline, every DLP rule, every IRM behavioural model assumes a person on the other end. The assumption is wrong, and the gap is open right now.
Why This Is Already Your Problem
Agent-driven compromise looks identical to authorised work at the credential level, because it is authorised work. The access is legitimate. The actions are authenticated. The only thing subverted is intent, and intent is the one thing your existing controls were never designed to inspect.
AI agents built on MCP can browse the web, read and write files, call external APIs, query databases, and chain those actions together using credentials you provisioned. That’s the productivity case. The risk profile follows directly from it: an attacker who compromises the agent doesn’t need to breach your perimeter. They’re already inside it, operating under the agent’s identity.
Your SIEM is logging these actions, but our SOC is almost certainly not reviewing that telemetry with the same scrutiny applied to a privileged human user. Most teams haven’t been told to treat agent activity as insider-risk-class behaviour. That’s the gap.
How the Attacks Work
Two mechanisms dominate. Prompt injection plants malicious instructions in content the agent consumes — a document it reads, a web page it visits, a tool response it processes. The agent follows those instructions as faithfully as it follows any other. Confused deputy attacks manipulate the agent into misusing a token it legitimately holds: redirecting an API call, escalating a permission request, exfiltrating data to an attacker-controlled endpoint using credentials your organisation trusted.
In both cases the resulting behaviour is authenticated. There’s no anomalous login, no lateral movement, no unusual authentication event. The attack surface is the agent’s decision-making layer, and most security tooling has no visibility into it.
The velocity compounds the problem. An agent doesn’t pause, doesn’t second-guess, doesn’t notice it’s doing something unusual. It will chain API calls across six systems in thirty seconds because that’s what efficient automation looks like. The same capability that makes these tools valuable is what makes a compromised one so dangerous.
Why Your Controls Miss It
User behaviour analytics (UEBA) platforms build baselines from login patterns, data access rhythms, email sentiment, behavioural anomalies. Insider risk management (IRM) programmes model human psychology: the disgruntled employee, financial pressure, the departing contractor with a USB drive. Data loss prevention (DLP) rules trigger on volume thresholds, access spikes, the unusual print job at 2am.
An AI agent defeats all of it by design. It has no psychology. It doesn’t get disgruntled. It will exfiltrate a terabyte at 2am on a Tuesday without hesitation because it was instructed to, and it has no concept that this is anomalous. The cross-system reach and execution speed that UEBA flags as suspicious in a human are normal operating parameters for an agent.
The architecture of insider risk management is built around a human adversary. That adversary no longer needs to be present.
What Needs to Change
Least privilege for agents is not optional. Most organisations provision AI agents with broad credentials because it’s convenient. Scope credentials to the minimum required action and rotate them. Agents should not hold long-lived tokens. Every tool call that isn’t strictly necessary is attack surface.
Treat agent audit trails as forensic evidence from day one. I’ve done expert witness work where log quality determined whether causation could be established. With AI agents you need immutable, granular records of every tool call, every prompt, every external resource accessed. “The AI did it” will not satisfy a data protection authority. Regulatory scrutiny will come; the question is whether your records are adequate when it does.
Define behavioural baselines for non-human principals. What does normal look like for a given agent workflow? What constitutes anomalous action chaining? Most UEBA vendors don’t have off-the-shelf answers. Your team needs to start defining them now. Waiting for the market to produce a product assumes you have more time than you probably do.
Treat agent identity as a first-class principal in your IAM architecture. Modelling agents as service accounts or application identities misses what they actually are: decision-making entities that respond to context and can be manipulated through that context. Identity governance needs to reflect that.
Background: MCP and the Agent Access Model
Model Context Protocol has matured quickly into the dominant integration layer for AI agent tooling. Agents built on MCP gain structured access to external systems — file stores, APIs, databases, communication platforms — through a defined set of tool calls. The protocol’s power is in composability: agents can chain actions across multiple systems to complete complex tasks with minimal human involvement.
That composability is also why the risk profile is worse than most organisations have assessed. An agent operating under legitimate credentials across six integrated systems isn’t a single attack surface. It’s six, linked by a decision layer that can be manipulated with a few sentences of injected text.
The Thirty-Three-Year View
The pattern in this industry is consistent: we build controls for the last attack. Insider threat programmes were designed for Edward Snowden, not for an MCP server that’s been instructed to behave like him. The organisations that get ahead of this will do it by asking a question most aren’t currently asking: What is my agent allowed to do, and how would I know if it was doing something else?
If you can’t answer that today, you already have a problem.
