Your Next Insider Threat Won’t be Human: Securing AI Agents From the Outside in

Why the controls on an AI agent have to live outside of it, and what a security operations team can implement and maintain those controls.

The new privileged user in your environment

Security teams spent two decades learning how to work with the people they trust most. Domain admins, DBAs, finance approvers and contractors with VPN access all get a mature playbook: verified identity, scoped access, logged activity and a fast way to revoke it all.

Today, we’re navigating the same kind of access with regard to AI agents. They read our mailboxes, query our data lakes, open tickets, push code and increasingly, act on production systems. Unlike a new hire, an agent can’t be interviewed, background-checked or made to sign an acceptable-use policy.

The industry has largely settled on one framing: AI agents are the new insider threat but that label only tells us half of the story. It tells us who to worry about, not where the controls should sit. Our argument is that the answer is a security idea from 1972, the reference monitor, and that the SOC is where it gets enforced in practice.

Why agents break the trust model we had

With traditional software, a security incident ends in a root cause. You find the vulnerable function, the misconfigured rule or the bad commit, and you fix it. The behavior lived in code we could read.

Large language models don't give us that. We can't point to the training example or the set of weights that produced a specific decision. The same prompt can produce different actions on different runs. For a defender, that removes the most basic assumption we rely on: that the system will do tomorrow what it did today.

The attack surface changes too, and computer science has an old name for this problem: the confused deputy. This is a trusted program tricked into misusing its own authority on someone else's behalf. An agent that reads a poisoned email, web page or document and then acts on hidden instructions is a confused deputy with API keys. No password is stolen and no exploit fires, which makes the agent's permissions the real blast radius, not the model's intelligence.

Where the insider analogy holds, and where it breaks

Most discussion of agents as insiders focuses on two gaps: agents have no career to lose, and they act at machine speed. Both are real. From a detection and forensics seat, though, four other differences change the work more:

Difference

Human insider

AI agent

What it means for defenders

Monoculture

One person fails on their own

Many identical copies share one weakness

Treat a working injection like a wormable bug: fix the fleet, not one instance

Replayability

Events can be reconstructed and the person interviewed

The same input can produce a different action on a rerun

Forensics must rest on recorded inputs and tool calls, not on replaying the agent

Command channel

Instructions come from a manager

Instructions arrive mixed in with the data it processes

Any content the agent reads is a potential command

Self-report

A person can be questioned and cross-checked

Its account of its reasoning may not match what it did

Evidence must come from outside the agent

The last row matters most. We can't make an agent's self-reported reasoning the basis of trust, because we don't yet know how to guarantee that reasoning is faithful. Evidence has to come from outside the agent.

Put the controls outside the model

If the model can't be fully trusted, the controls that govern it can't live inside of it. A system prompt that says "never delete production data" is a suggestion, not a control. A well-crafted injection can talk the model out of it.

Security architects solved a version of this problem in the 1970s with the reference monitor: a mechanism that checks every access request, can't be bypassed and can't be tampered with by the program it governs. For AI agents, that means separating three things: the model that reasons, the harness that orchestrates it and the policy layer that decides which actions are actually allowed.

Figure 1: Agent control architecture · enforcement outside the model

The agent can propose anything, but only the enforcement point decides what reaches real systems, and every decision lands in a log the agent can't alter.

A security playbook for AI agents

None of these controls are new. What's new is applying them consistently to a non-human actor that reasons, plans and acts.

1. Give every agent its own identity. An agent should never run under a shared service account or a person's own credentials. It needs an identity that can be scoped, monitored, and revoked independently.

2. Enforce least privilege on actions, not just data. Define an explicit action space: which tools, which APIs, which parameters. High-impact actions like payments, deletions or production changes need step-up approval from a human.

3. Log everything in a place the agent can't touch. Every tool call, input, and output goes to tamper-evident storage outside the agent's reach. You should be able to reconstruct what happened without asking the

Read the original article:

Your Next Insider Threat Won’t be Human: Securing AI Agents From the Outside in