The insider threat model was built around people. An employee with legitimate credentials and a reason to misuse them – that is the scenario security teams have managed for decades. The controls are familiar: least-privilege access, behavioral monitoring, periodic access reviews, offboarding checklists.
None of those controls were designed for an entity that never sleeps, executes thousands of actions per hour, and has no HR file.
AI agents are now the fastest-growing population of credentialed identities in enterprise environments. They authenticate to systems, hold API keys, read sensitive files, write to databases, and call external services – all the behaviors that define privileged access – and most organizations govern them with frameworks built for humans.
The identity problem in concrete terms
When an organization deploys an AI coding agent, that agent needs credentials: repository access, command execution rights, access to internal APIs and build systems. In most deployments, those credentials are provisioned with the permissiveness of a senior developer – because the agent is doing developer-level work, and restricting it creates friction.
The result is an identity that can do nearly everything a senior developer can do, operates continuously, and is controlled by a model whose behavior can shift based on context or prompt injection. The IBM Cost of a Data Breach 2025 found that 97 percent of organizations that experienced an AI-related breach had lacked AI access controls. That is a description of an industry that has not yet applied the insider-threat model to its non-human population.
Three ways agent identities go wrong
Credential sprawl. Agents are deployed by teams, projects, and individual engineers – each creating new credentials without central visibility. Unlike human identities, which have natural lifecycle events (hiring, role changes, departure), agent identities tend to persist indefinitely once created. A security team trying to audit which agents have access to which systems often finds no one has a complete inventory.
Overly broad permissions. Because agents are often provisioned quickly, they receive permissions scoped to “what the agent might need” rather than “what the agent needs for this specific task.” An agent that only needs to read one repository directory might end up with write access to the entire codebase, production secrets, and external API access.
No behavioral baseline. Human insider threat programs work by establishing what normal looks like for a given identity and alerting on deviations. Agent behavioral baselines are almost never established. Operators often cannot describe, at a granular level, what a normal agent session looks like – making anomaly detection impossible.
What non-human identity governance requires
The NIST AI Risk Management Framework and ISO/IEC 42001 both address AI system accountability and traceability, but neither provides a prescriptive control set for agent identity management. Organizations must extend their existing IAM frameworks deliberately.
The starting point is treating each agent deployment as an identity governance event: a named identity, permissions scoped to the minimum required for the specific task, a documented owner, and a defined lifecycle. The agent should be provisioned and deprovisioned with the same rigor as a human employee.
The second requirement is runtime enforcement at the *action level*, not just at the authentication boundary. Authenticating an agent is necessary but not sufficient. An agent that has authenticated successfully can still take actions outside its intended scope. Runtime enforcement means intercepting each action, evaluating it against a least-privilege policy, and blocking or transforming actions that exceed scope.
The enforcement architecture that addresses both
Ethosure’s approach – built on the open-source `coding-ethos` project – applies deterministic policy evaluation to every agent action, not just the authentication event. The CEL-based policy engine evaluates each action against a versioned policy bundle specifying what the agent is allowed to do, in what context, with what resources. Actions that exceed scope are blocked before they execute; the attempt is recorded in the append-only evidence ledger.
The runtime sandbox layer reinforces this: Linux namespace isolation constrains what an approved process can actually touch – read-only declared directories, no unauthorized network access, enforced resource limits. The sandbox is derived from the same policy bundle that governs the rest of agent behavior, not configured separately by hand.
The combination – least-privilege enforcement at the action level, runtime sandboxing, and immutable audit trail – addresses all three failure modes. Credential sprawl becomes visible because every agent action is recorded against a named identity. Overly broad permissions surface as policy violations at runtime. Behavioral baselines emerge naturally from the evidence ledger.
The organizational ask
Non-human identity governance falls between IAM (which manages credentials) and the AI/engineering team (which deploys agents) – with neither group having full visibility. The near-term step is an inventory: what agents are running, what credentials they hold, what systems they can reach. The medium-term step is enforcing least-privilege at the action level, not just at the credential level.
The insider threat model works. It just needs to be extended to entities without a badge photo.
