Ninety-five percent of 600 CISOs surveyed had an insider incident in the past twelve months involving an AI or autonomous system, and 78% have already rewritten their definition of insider risk to include agents. The same research puts detection and response for an insider incident at around fifteen hours. An agent that has been talked into reading a customer table and posting it somewhere is finished well inside the first of those hours — so what most organisations just extended to cover agents is a programme whose central control runs on a clock the agent does not use.
At a glance
Trellix published Mind of the CISO: The New Insider around 13 October 2026. Vanson Bourne polled 600 CISOs during August and September 2026; the incident breakdown below covers the 587 organisations that reported an incident. Figures are as reported.
| Finding | Figure | What it establishes |
|---|---|---|
| Had an insider incident linked to an AI or autonomous system, past 12 months | 95% | This is now the common case, not the frontier case. |
| Include AI agents, autonomous systems and machine identities in the definition of insider risk | 78% | The category has already been extended on paper. |
| Share of insider-related incidents attributed to AI actions, on average | 28% | Roughly the same share as deliberate human misuse (29%). |
| Average cost of an insider risk incident | $2.4M | Enough to fund controls, if anyone can say which ones. |
| Time to detect and respond to an insider-related incident | ~15 hours | About seven to detect, eight to respond. |
Two governance numbers sit underneath those: 52% of respondents have no fully implemented insider-risk strategy, and 68% say their existing policies do not adequately address AI-related risk. Meanwhile 92% report increased personal accountability for insider incidents this year and 69% are worried about personal liability. That combination — the category is extended, the policy is not, and the person signing is exposed — is the actual state of play.
Two clocks, and only one of them moved
Fifteen hours is not a scandal. For a human insider it is defensible: the signal is slow because the behaviour is slow — a person copies files over days, emails a competitor, prints something on a Friday. Seven hours to notice and eight to act sits inside the window in which the damage is still accumulating, which is what makes detection a control rather than a postmortem.
An agent's incident has a different shape. The window from "the agent reads attacker-controlled text" to "the agent has used its legitimate credentials on every system that text asked for" is bounded by tool latency, not by human nerve. Pick your own number from your traces: a retrieval, a summarisation and four tool calls is a minute or two. For an externally measured one, Booz Allen's industrial-control lab recorded just over sixteen minutes from initial network compromise to action inside the control environment — and that run included a human approving each exploit, which is to say sixteen minutes was the slowed-down version. We read that result separately in the interlock held, the network did not.
Put the two side by side and the uncomfortable conclusion is arithmetic rather than opinion. If your mean time to detect is seven hours and the incident completes in two minutes, your detector is not a control in the loop; it is a reporting function with a good story about why it exists. It still has value — you need it for scope, for notification, for the regulator, for knowing whether it is happening again — but every sentence in your programme that says "we would catch that" needs rewriting to "we would learn about that".
What transfers from an insider-risk programme, and what quietly does not
Extending the category is the right instinct; the mistake is assuming the machinery comes with it. Three parts of a mature insider-risk programme transfer almost unchanged, and two of the most expensive parts do not transfer at all.
Transfers: the identity lifecycle
Joiner-mover-leaver is the single most portable thing in the discipline, and it maps onto agents better than it maps onto contractors. An agent is provisioned, its scope changes when someone adds a tool, and it should be revoked when the project ends. Most organisations cannot currently answer how many agent identities exist, which is the same gap an identity programme closes for humans — see agent inventory and registry and access reviews for agent credentials. The leaver case is the one that bites: a departed engineer's agent, still holding a service token, is the cleanest version of this failure anyone has shipped.
Transfers: the damage taxonomy and the notification path
What was taken, whose data it was, which regulator gets told, what the customer is owed — none of that cares whether a human or a loop did it. If you have this, keep it, and add the agent's run id as a first-class field so an incident can be reconstructed from the trajectory rather than from interviews.
Does not transfer: motive-based triage
Insider programmes sort incidents by intent — accidental, negligent, malicious — because intent predicts what you do next: training, discipline, legal. The Trellix split does this honestly, putting 43% on accidental actions by trusted users and 29% on deliberate human misuse. The 28% has no intent to sort. An injected agent is not disgruntled and was not careless; it did exactly what the text in its context window asked, with permissions you granted. Running it through a motive triage produces the answer "accidental", which routes it to awareness training for a system that cannot attend.
Does not transfer: behavioural baselining
User-behaviour analytics works because people are boringly consistent, so a deviation means something. An agent is anomalous by design: it reads a thousand files, touches hosts no human would, and works at 3am. Its baseline is the deviation, and generic analytics on an agent fleet produces a queue of noise that gets muted within a month — the base-rate argument in detecting agent compromise. The signals that do discriminate are narrower and have to be built: a tool called that no task should reach, a destination outside the egress policy, a volume spike against a fixed per-run budget.
If detection cannot be the control, the decision has to move
This is not a call for a new product category. Almost every control an insider programme would reach for already exists for agents; it just has to be evaluated before the action instead of after the log line. Four moves, cheapest first.
- Make the envelope machine-checkable before the run. Which systems, which operations, which volumes, which destinations. A sentence in a system prompt is not an envelope; a list the executor enforces is. This is the structural point in policy as code for agents, and it is what converts "we would notice" into "it cannot".
- Scope the credential to the errand, not to the agent. An insider programme's hardest problem is that privilege is granted once and used for years. Agents make the fix easier, not harder: the token can be minted per run, for one scope, for minutes. See scoped credentials for agents and credential lifetime.
- Put the irreversible actions behind a different authority. Not an approval prompt on every step — that gets click-fatigued inside a week — but a hard separation for the handful of operations that cannot be undone, as in separation of duties for agents. The test: name the operations in your stack where fifteen hours of latency is actually fatal, and check whether any of them can be reached by one trajectory.
- Trip on budget, not on behaviour. A per-run ceiling on tool calls, egress bytes and spend is a detector that fires in seconds because it needs no model of normal. It is also the only one of these four that catches the case nobody predicted.
Keep the detectors. Just stop financing them as if they were prevention, and be precise in the board deck about which of your controls act in milliseconds and which act in hours.
The liability finding is the one that will actually move budgets
92% of these CISOs report increased accountability for insider incidents and 69% are concerned about personal liability — and this is the finding most likely to change behaviour, because it is the one with a name attached. The problem is that personal accountability requires an artifact you can point at, and for agents that artifact mostly does not exist yet.
For a human insider the record is legible: an employment contract, an access request with an approver, a policy acknowledgement, a joiner ticket. For an agent, ask the equivalent questions and most organisations cannot answer them from a system. Who authorised this agent to act on this system? Under whose authority did it hold that token at 02:14? Which human owns the consequences of its run? That gap is the subject of accountability and roles, and the reason it matters now rather than at audit time is that liability without an authority record resolves, by default, onto whoever signed the deployment.
The pragmatic version is unglamorous and takes a week: for every agent in production, a named human owner, an explicit statement of the systems it may touch, the credential it holds and its expiry, and a link from each run to that record. That is roughly what decision receipts and audit describes at the per-action level, and it is the evidence both the insurer and the regulator will ask for — see insurance and liability for agent actions.
FAQ
Is calling an AI agent an "insider" useful at all, or just a category error?
It is useful for one specific reason: it correctly locates the problem inside the trust boundary. The agent is not an intruder who got in; it holds credentials you issued for work you wanted done, which is exactly what makes an insider hard. The error is importing the response machinery along with the label, because that machinery assumes a human timescale and a human motive.
Does the 28% figure mean agents are a bigger risk than malicious employees?
No. It means agent actions account for a similar share of insider-related incidents today, and the comparison hides a severity difference in both directions: a single determined human insider can do far more targeted damage, while an agent can do broad damage far faster and with no intent required. Use the figure to argue that the category is material, not to rank it.
Our agents only have read access, so is fifteen hours fine?
Read access is the exfiltration path, and exfiltration is the one insider harm that completes instantly and cannot be undone by any later response. Fifteen hours of latency against a read-only agent means fifteen hours in which the data is already gone. Read-only changes which controls matter — egress policy over approval gates — not whether the clock matters.
What single number should we measure to know where we stand?
The share of your agents' irreversible or externally visible actions that pass a synchronous policy check before executing. It is an awkward number to produce the first time and it maps directly onto the gap this research describes. Mean time to detect is worth tracking too, but as a measure of your reporting, not your defence.
Is the survey measuring real incidents or scary definitions?
Partly the definitions — 78% of respondents having widened the category means some of the 95% is reclassification of things that were already happening under another label. That cuts both ways: the reclassification is itself the finding, because budgets and reporting lines follow the category an incident is filed under.
Further reading
On this wiki:
- Insider Misuse of Agents — the other direction: a human using an agent to exceed their own access.
- Detecting Agent Compromise — the five signals that discriminate when baselines cannot.
- Credential Lifetime — why a per-errand token is the cheapest control on this list.
- Accountability & Roles — building the authority record liability will demand.
- Incident Response for Agents — what to do in the hours after the fast part is over.