Every action was authorised. That is exactly why nothing fired.
The industry's "AI insider risk" story is an employee pasting a customer list into an unsanctioned chatbot, and your DLP already watches that door. The harder case runs the other way and through the agent you approved: an employee with ordinary permissions asks a question, and the agent performs four thousand individually-permitted reads across six systems and hands back the synthesis a determined person would have needed three weeks and a SQL client to assemble. No policy was violated, so no control had anything to fire on. What changed is not access. It is throughput, assembly, and who can now do it.
Separate the two problems the surveys keep merging.
Almost every 2026 report on AI and insider risk is measuring shadow AI — unsanctioned tools, data leaving the perimeter, negligence rather than intent. DTEX's 2026 insider-threat work found 92% of organisations saying generative AI has changed how employees access and share information, and Ponemon's cost study put negligent employees behind 53% of insider incidents. That is a real problem and a well-served one: it is an egress problem, and egress controls work on it.
The number in the same body of research that should worry you more is a different one: only about 19% of organisations classify AI agents as equivalent to human insiders. That gap is where this page lives.
- Shadow AI is unsanctioned and outbound. Data crosses a boundary you own. Blocking, classifying and inspecting all apply.
- Agent-assisted insider misuse is sanctioned and inbound. The agent is one you deployed, running with the employee's own entitlements, reading systems they are allowed to read. Nothing crosses a boundary until the very last step, and by then it is a screenshot.
- Only the second one defeats your access controls by design, because it never contradicts them. An authorisation system that fired here would be malfunctioning.
What the agent removes is friction, and friction was doing security work.
Most insider-risk programmes inherited two protections nobody ever wrote down, and an agent deletes both in the same afternoon.
- The skill floor. Bulk extraction used to require knowing where the data lived, how to join it, and how to get it out — which quietly restricted the population capable of large-scale misuse to a few dozen engineers and analysts. A capable agent moves that population to everyone with a login.
- The cost of aggregation. A person browsing a case management system sees one record at a time and gets bored. That inconvenience was the real enforcement of need-to-know, and it is the thing permission-aware retrieval cannot restore: a correctly-filtered index still returns everything this person may see, and the agent's whole value is synthesising across it.
So the honest statement of the exposure is not "the agent has too much access". It is that the union of what an employee may see, which was previously unreachable in practice, is now reachable in one prompt. That is the same arithmetic ambient authority describes, with a person rather than an injection doing the asking — and the mitigation is the same one, applied per task instead of per session.
Test your own exposure with one question per role: if this person's agent ran flat out for one hour with their credentials, what could it assemble? Not "what are they entitled to", which is a list nobody reads — what is the most damaging document that list can be turned into. That is the number your risk register should carry.
Detect on volume and purpose, because permission has nothing left to say.
Every signal in an access-control system is binary and every answer here is "yes". The signals that survive are quantitative and they run on the same telemetry detecting agent compromise already asks you to collect — the difference is that the baseline is per role and the anomaly is a person, not an injection.
- Count records returned, not queries issued. One prompt can be a hundred tool calls and fifty thousand rows. Query counts flatter the abuser; rows and distinct subjects touched do not.
- Count distinct data subjects per identity per day. A support agent who touched eleven customers looks like their job. The same identity touching nine hundred is either a new workflow you should know about or an incident.
- Watch the exports and the renders. The agent's output surface is the exfiltration surface. A synthesis rendered into chat and copied out is invisible to a file-based DLP rule, so the control point is the response, and it belongs in the exfiltration channel inventory.
- Bind requests to a purpose. The single highest-value change available: require a case, ticket or account id on retrieval tasks, and log it. Purpose binding turns an unanswerable question ("was this read legitimate?") into a checkable one ("was there an open case?"), and it is the same primitive regulated industries have used for decades.
- Baseline per role, never globally. A fraud analyst is supposed to look broad and fast; a recruiter is not. One global rule produces noise from the teams whose job is breadth and silence from everyone else.
Log the prompt, or you have built a deniability machine.
This is the control most teams have not shipped, and its absence is worse than a missing detection. If your audit record contains the tool calls but not the instruction that produced them, then "the agent did that on its own, I only asked a general question" is an assertion your logs actively support. You have automated the retrieval and destroyed the intent evidence in one move.
- Bind the human to the run. The user identity, the verbatim prompt, the resolved plan, every tool call with its arguments, and the response, joined by one run id. Anything less and the trail stops at a service account.
- Do not let the service account own the reads. If the agent queries downstream systems as itself, the downstream audit logs record the agent for every user in the company, and attribution has to be reconstructed from your side — badly, and only while your traces are retained. Propagate the end-user identity; scoped credentials is the mechanism.
- Retain the run record on the audit clock, not the debugging clock. Insider cases surface months later. A thirty-day trace retention chosen for cost means the evidence expires before the suspicion arrives — the tension sampling and retention exists to resolve.
Storing employees' prompts is employee monitoring, and in much of Europe it engages works-council consultation and a documented lawful basis before it engages your SIEM. Decide the scope deliberately — who can query the prompt store, under what trigger, with what second approval — and write it down. A monitoring capability with no access rule around it becomes the insider problem it was built to detect.
The leaver window is where this actually shows up.
Classic insider-risk practice concentrates on the notice period, because that is when collection happens. The agent compresses that window from weeks of quiet copying into a single session, and it does so through an interface that produces no unusual file activity at all.
- Put resignations on the agent's risk feed. The same population your programme already monitors more closely should get tighter volumetric thresholds and purpose binding on agent tasks, not just on file shares.
- Revoke the agent's delegated tokens on the same clock as the badge. Long-lived delegated grants, background schedules and saved agent workflows routinely survive an offboarding that revoked SSO — a gap the agent registry exists to close.
- Check the scheduled jobs. An agent task that runs weekly and emails a report is a persistence mechanism, and it does not care that its author left.
- Include agent runs in the exit review. If you already review a departing employee's file access, review their agent transcripts by the same standard. Most exit processes have no such step because the artefact did not exist two years ago.
Do not fix this by making the agent useless.
The instinctive response — cap the result set, ban bulk retrieval, require approval for anything broad — is available, and it converts your agent back into the search box it replaced. Worse, it does not work: an employee blocked from the sanctioned agent moves to an unsanctioned one, and you have turned a monitored population into an invisible one, which is exactly the shadow-AI problem the surveys in Step 1 were measuring.
- Prefer purpose binding to hard caps. A high-volume read attached to an open case is fine; the same read with no case is the thing you wanted to catch. Caps punish the legitimate worker and barely inconvenience the patient one.
- Use break-glass for the genuinely broad tasks. Named approver, stated reason, time-boxed, loudly logged. Ordinary work should never touch it, which is how you know the threshold is set right.
- Reserve blocking for irreversible actions. Reads want detection and attribution; writes, payments and deletions want a stop — the same asymmetry that governs autonomy everywhere else.
- Say who owns this. Insider risk lives with HR, legal and security; agent telemetry lives with the platform team; neither can act alone. If nobody is named, the detection you build will fire into an unowned queue.
Ship these two first, in this order. One: put the end user's identity and verbatim prompt on every agent run record, joined by a run id, retained on your audit clock — without it, every later control is unattributable. Two: pick your highest-sensitivity retrieval tool and require a case or ticket id on the call, then report weekly on how many requests arrived without one. That report is your insider-risk programme for agents, and it takes a sprint.
Related: attacker-operated agents for when the person driving is not an employee, audit trails for the record this all depends on, and data governance for the classification that makes a volumetric threshold mean something.