What breaks when insider-risk programmes only monitor people and not AI agents?

Why This Matters for Security Teams

Insider-risk programmes are usually built to observe human intent, human access patterns, and human accountability. That model starts to fail when an AI agent can search repositories, move data, open tickets, send messages, or invoke APIs with delegated authority. The risk is not only that the agent is powerful, but that it may operate under a user’s identity while remaining invisible as a distinct actor. Current guidance suggests this should be treated as an identity and control design problem, not just a monitoring problem, consistent with the NIST AI Risk Management Framework.

That matters because traditional insider-risk workflows depend on alerts tied to a named employee, a known device, or an abnormal login. An AI agent can fragment those signals across multiple tools and sessions, making the act look ordinary until the outcome is reviewed. Once an agent can chain actions, the programme also needs to understand whether the failure was misuse, poor delegation, weak permissioning, or missing containment. In practice, many security teams encounter this only after an agent has already copied data, modified records, or triggered workflows that were never meant to be autonomous.

How It Works in Practice

A workable programme treats the AI agent as an operational subject with its own governance record, rather than as a hidden extension of the user. That means the organisation needs to know which agent exists, what it can access, which prompts or policy instructions shape its behaviour, and where its actions are logged. The same principle appears in the OWASP Top 10 for Agentic Applications 2026 and the broader OWASP Agentic AI Top 10, where uncontrolled autonomy, tool abuse, and insufficient oversight are recurring themes.

Practically, security teams should extend insider-risk controls across identity, privilege, and telemetry layers:

• Register each agent, workflow, and tool connector as a governed entity with an owner and purpose.
• Separate the human user’s identity from the agent’s operational permissions where possible.
• Log prompts, tool calls, approvals, data access, and downstream actions in a reviewable format.
• Apply least privilege and short-lived access for any agent that can reach sensitive systems.
• Correlate behaviour in SIEM and case management with agent-specific context, not just user context.

Threat modelling should also include adversarial patterns such as prompt injection, tool hijacking, and data exfiltration through trusted workflows, which are well represented in the MITRE ATLAS adversarial AI threat matrix and the CSA MAESTRO agentic AI threat modeling framework. These controls tend to break down in highly integrated environments where agents can act through shared service accounts and legacy orchestration platforms because action trails are hard to separate after the fact.

Common Variations and Edge Cases

Tighter monitoring often increases operational overhead, requiring organisations to balance visibility against developer velocity and automation quality. Not every assistant needs the same level of scrutiny, and current guidance is still evolving on where the threshold sits for logging, approval, and human-in-the-loop review. The key is to scale controls to the agent’s reach: an internal summarisation bot is not the same risk as an agent that can approve payments, change entitlements, or manipulate source code.

Edge cases appear when agents inherit broad human permissions, operate across multiple tenants, or use external tools that do not preserve a reliable audit trail. In those environments, insider-risk teams should assume that a human-centric dashboard will undercount exposure. That is especially true when an agent’s output is merged into a user’s normal workflow, because malicious activity can look like routine productivity unless the programme records which actions were human-authored and which were machine-executed. Where the environment lacks stable identity binding for agents, detection becomes partial at best and containment becomes reactive.

For organisations aligning policy to broader governance, the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls provide a useful control language for auditability, access restriction, and response, but there is no universal standard yet for how to classify every agent in insider-risk programmes.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents create new risk in non-human identity management?
• Why are shadow AI agents a risk for enterprises?
• Why do AI agents create more risk when they reuse existing credentials?