AI agents are the new insider threat. Learn how to extend IRM to machine identities with runtime visibility, agent inventory, and deterministic guardrails.
Security teams define an insider threat by access, not by employment status. An insider is anyone operating inside the trust boundary with legitimate credentials, who can cause harm through misuse, misconfiguration, or abuse of those credentials. By that definition, AI agents are insiders.
AI agents hold OAuth tokens and embedded service account credentials. They access CRM records, financial systems, HR data, and source code repositories. They take multi-step actions across SaaS platforms without human review of each step. And they do all of this at a speed and scale no human insider can match. AI agents move 16 times more data than human users, and 90% of deployed agents carry excessive permissions relative to what their actual workflows require.
The machine insider risk is not theoretical. Consider the maker mode scenario: a user without Salesforce access invokes a Copilot Studio agent built by a Salesforce administrator. The agent runs on the administrator's embedded credentials. The user extracts CRM records they were never provisioned to see. No rule was broken at the IAM layer. The agent performed exactly as configured. Your access controls were bypassed because the agent's effective authority was never mapped against the invoker's actual entitlements.
This is what separates machine insider risk from human insider risk. A human insider requires intent or negligence. A machine insider can cause the same damage through a theoretical configuration that looked fine on paper but resolved to admin-level access at runtime. The agent did nothing wrong. Your visibility gap did.
Industry research increasingly frames AI as a new insider class precisely because agents inherit the trust of whoever provisioned them, operate continuously without typical behavioral patterns, and bypass the multi-factor authentication checkpoints that human identity programs depend on. Non-human identities already outnumber human identities by 25 to 50 times in modern enterprises (SailPoint). Every new agent deployment widens that ratio further.
UEBA and SIEM platforms are not broken. They are scoped to the problem they were built to solve: detecting anomalous human behavior by comparing current activity against a historical behavioral baseline. That model works well for humans. It has no mechanism for agents.
An agent has no behavioral history when it is first deployed. It has no employment record, no peer group, no typical login time, and no prior access pattern to baseline against. UEBA tools cannot flag privilege escalation in a maker mode agent because the agent's elevated access was never anomalous relative to its own history. The agent always had those credentials. SIEM tools can ingest the logs that AI platforms produce, but those logs are siloed per platform, require manual correlation across tenants, and do not surface the relationship between the agent's configuration and what it can actually execute inside each connected SaaS application.
The coverage gap is a scope gap, not a capability gap.
Signal TypeHuman Insider Detection (UEBA/SIEM)Machine Insider Detection (AI IRM)Identity recordEmployee directory, HR systemAgent inventory across platformsBehavioral baselineHistorical login, access, and data patternsAgent-to-invoker correlation at runtimeCredential typePassword, MFA, SSO tokenOAuth token, embedded service account, maker mode credentialPrivilege escalation signalUnusual role assignment or access spikeInvoker without entitlement accessing data via agentOrphaned account detectionDisabled employee with active sessionsOrphaned agent running on disabled creator's credentialsScope of actionSingle-user actionsAction chaining across multiple SaaS platformsSpeed of data movementHuman-pace access patternsMachine-speed bulk data movementCoverage by existing toolsYesNo, without purpose-built AI IRM
The machine insider risk category exists precisely because no existing tool was designed to populate the right column of that table. Extending IRM to cover it requires a different acquisition mechanism, a different identity model, and a different risk scoring framework.
Security teams asking "how do we detect insider threats from AI agents" are really asking five distinct questions. Each requires a different capability.
Agent inventory across platforms: you cannot govern what you cannot see. One enterprise discovered 377 Copilot agents through an assessment they did not know existed. Another had 2,500 agents created before any inventory existed. The starting point for AI insider threat detection is a complete, centralized record of every agent: who built it, which platform it runs on, what connectors it holds, and whether it is sanctioned or unsanctioned. Orphaned and unsanctioned AI agents represent a particularly acute risk because they continue operating on inherited credentials after their creator's account is disabled.
Effective authority mapping: configuration is not reality. An agent may appear to have read-only access based on its configuration. Its actual effective authority inside a connected SaaS application may include write, delete, and export capabilities depending on how the underlying connector was provisioned. AI insider threat detection requires mapping what the agent can actually do, not what the configuration says it should do.
Runtime monitoring: posture signals tell you what could happen. Runtime monitoring tells you what did happen. Security teams describe the posture-only experience as ghost chasing: reviewing theoretical risks with no evidence of actual agent behavior. Runtime truth requires hooking into AI platforms via native APIs and webhooks to capture what agents actually executed, what data they accessed, and whether the invoker had the right to trigger that action.
Invoker-identity correlation: the maker mode scenario is only detectable if you can correlate the runner's identity with the agent's inherited credentials. This requires knowing both who invoked the agent and what authority the agent carried into the SaaS application on that invocation. Without that correlation, the action looks like normal agent activity.
Toxic combination detection: individual risk factors are often medium severity in isolation. An agent that is org-wide accessible is a medium risk. An agent running on a disabled creator's credentials is a medium risk. An agent with a connector to an unsanctioned external domain is a medium risk. When all three conditions exist on the same agent simultaneously, the combined blast radius is critical. Toxic combinations require a risk scoring model that evaluates compounding factors, not individual flags.
Obsidian Security was built to answer the five questions above without requiring a SaaS connector for every application in your stack. The platform functions as the runtime truth layer for machine identities, sitting between agent configuration and actual SaaS entitlements.
Agent inventory across 8 platforms: Obsidian provides a single pane of glass covering Salesforce Agentforce, Microsoft Copilot Studio, Amazon Bedrock, Google Vertex AI, Azure AI Foundry, ChatGPT Enterprise, n8n, and others. Every agent in scope is surfaced with its author, creation date, access scope, connected MCP server paths, and current risk posture. Security teams can answer "what agents exist and who owns them" without manual platform-by-platform review.
Knowledge graph correlation: the knowledge graph is the mechanism behind effective authority mapping. It correlates agent configuration data with entitlements from connected SaaS applications, identity provider records, and cross-platform access paths. The result is a living map that shows not what the agent is configured to do, but what it can actually execute inside each application it touches. This is the capability that closes the agent identity management gap that no IAM tool currently fills.
Runtime visibility and deterministic guardrails: Obsidian hooks directly into AI platforms via native APIs and webhooks. This is not an inline proxy. It does not sit between the agent and the network. It captures what agents actually do at runtime, correlates invoker identity with agent authority, and flags privilege escalation events as they occur. Deterministic guardrails enforce fixed, predictable rules on probabilistic agents: if an invoker lacks the entitlement to access a data set, the agent's action is flagged regardless of how the agent was prompted.
Complementing, not replacing, existing IRM and UEBA: Obsidian does not replicate what UEBA and SIEM platforms do for human insiders. It covers the machine identity class those tools do not reach. The output feeds into existing incident response workflows, ticketing systems, and SLA frameworks that security teams already operate. Security teams at enterprises with mature IRM programs use Obsidian to extend their existing program scope rather than rebuild it.
See your machine insider exposure now. Obsidian's AI agent risk assessment maps every agent, its authority, and every toxic combination active in your environment today. Request an assessment
The inventory-first sequence is the only practical starting point. Security teams that attempt to enforce guardrails or build detection rules before they have a complete agent inventory end up with partial coverage and false confidence. The sequence matters.
Step 1: Build the agent inventory. Deploy across supported platforms and run the initial inventory sweep. The output is a complete list of every agent, its creator, its access scope, and its current risk posture. Many teams discover agents they did not know existed. That number is your actual attack surface, not the number of agents IT approved.
Step 2: Map effective authority for high-risk agents. Prioritize agents with maker mode connectors, org-wide accessibility, or disabled creator accounts. For each, the knowledge graph surfaces the gap between theoretical configuration and effective authority inside connected SaaS applications. Overpermissioned AI agents are the highest-priority remediation targets because their blast radius extends far beyond what the configuration review would suggest.
Step 3: Integrate with the existing IRM program. Map Obsidian alert categories to your existing IRM risk taxonomy. Orphaned agent alerts map to stale credential workflows. Maker mode privilege escalation alerts map to unauthorized access investigation workflows. Toxic combination alerts map to critical-severity incident response tracks. The goal is to extend your IRM program's scope to machine identities without creating a parallel, disconnected process.
Step 4: Measure blast radius reduction. Track the number of agents with critical toxic combinations before and after remediation. Track the percentage of agents operating within least-privilege boundaries. Track the time from agent deployment to security team awareness. These metrics translate directly into board-level reporting on AI risk posture.