Insider threat programmes were built around people: the disgruntled employee, the departing salesperson with the customer list, the administrator with more access than their role required. The controls that followed — least privilege, separation of duties, behavioural monitoring, access reviews — assume a human behind every action, operating at human speed, with a human's sense of what is and is not appropriate.
The fastest-growing population of insiders in most organisations today has none of those properties.
Agents are insiders
An AI agent deployed with the credentials of the engineer who built it, or with a service account created years ago for an integration, is an insider in every sense that matters. It has standing access. It operates inside the perimeter. It can read, change, send and spend. And it has three characteristics no human insider has.
It acts at machine speed, so a single bad decision becomes thousands of actions before anyone notices. It has no instinct for appropriateness; it will do what its instructions and its tools allow. And it can be turned by the content it reads — a crafted email, a poisoned document, a web page — through prompt injection, so that an attacker who never touches your network can direct an insider who is already inside it.
This is the insider threat model inside the AI environment, and most organisations have not written it down.
Identity is the hard part
The reason this is tricky is that identity, for agents, does not map cleanly onto the identity systems you already run. A human has one identity, one set of entitlements, and a manager who can be asked whether access is still needed. An agent might act on behalf of a person, under delegated authority, for a bounded purpose, with a time limit — and might spawn other agents that inherit some of that authority. Corporate policy written for people has no vocabulary for this.
Monolith models human identity and machine identity as one problem. Every agent is attributed to a named identity and a responsible owner. Its authority is stated explicitly — which tools, which resources, which actions, for how long — rather than inherited from whoever provisioned it. Delegation is capped at the authority of the parent task. And a human who approves an action is bound to that specific action, so a changed or replayed action requires approval again.
What is normal is not normal
Conventional anomaly detection assumes a stable baseline. In an AI environment there is no such thing. New agents come online weekly. New data sources are onboarded. New tools are connected. An agent that behaved one way in March behaves differently in April because its instructions changed, not because it was compromised. Correlating abnormal behaviour against a baseline that is itself in constant motion is extremely difficult, and it is exactly where static rule sets fail.
Monolith re-baselines continuously, per agent, as the environment changes — and it correlates against purpose, not just history. The question is not only "is this different from last week" but "is this consistent with what this agent is authorised to do". That second question still has an answer when the first one does not.
Detecting the agent that steps outside its authority
An over-permissioned agent is not visible to conventional monitoring, because its actions are authorised. The service account is allowed to call that endpoint. The access log shows nothing wrong. What is wrong is that the agent's behaviour has diverged from its purpose — and that is what Monolith watches for.
An agent that begins enumerating a directory it has never queried, exporting at ten times its usual volume, or reaching an endpoint outside its task is detected as an insider acting outside authority — and contained, in the same way a compromised workstation would be.
Enforcing policy where the agent cannot override it
The instinctive response is to instruct the agent to behave. That does not work, because an agent whose context has been poisoned will follow the poison. Monolith enforces corporate policy at the execution boundary — outside the model, where the model cannot reach it. Every consequential action is checked against identity, scope, resource and current policy before it executes. Untrusted content cannot authorise an action. If the policy service is unavailable, privileged execution stops rather than proceeding unchecked.
Guardian's core: identity on both sides of the screen
This is not a feature Guardian added to Monolith. It is what the company is built around. ScreenComply establishes that the human on the other side of a screen is who they claim to be and is acting unassisted. Monolith establishes that the machine acting on your network is who it claims to be and is acting within its authority. The Controlled Autonomy Standard publishes the requirements both are built to meet. Identity, bounded action and evidence — human and machine — is the whole discipline.
Frequently asked questions
Why is an AI agent considered an insider threat?
Because it has the defining properties of one: standing access inside the perimeter, the ability to take consequential actions, and credentials that are valid. It differs from a human insider in that it acts at machine speed, has no judgement about appropriateness, and can be directed by an external attacker through the content it processes.
How does Monolith identify agents on the network?
Every agent is attributed to a named identity and a responsible owner, with its authority stated explicitly rather than inherited. Agents operating under shared or inherited credentials are flagged, and their behaviour is baselined so that divergence from purpose is detectable.
Can existing IAM handle machine identity?
Partly. Existing identity systems authenticate and coarsely authorise. They do not model delegated authority, purpose limitation, time-bound access, or delegation caps for agents that spawn other agents. Monolith adds that layer and enforces it at the point of action.
What happens when an agent acts outside its authority?
The action is blocked at the execution boundary, the agent is contained — credentials revoked, egress blocked, workspace frozen — and the event is written to the tamper-evident record with the full chain of evidence. You are notified of the outcome.
How does this relate to ScreenComply?
ScreenComply verifies the human: that the person on the other side of the screen is who they claim and is acting unassisted. Monolith verifies the machine: that the agent acting on the network is who it claims and is acting within authority. Both are Guardian's core discipline of identity and bounded action.