Machine identities outnumber humans 25-50x. Learn what machine identity management is, why AI agents are the riskiest NHI category, and how to govern them at runtime.
Most security teams can name every human identity in their directory. They cannot name every machine identity in their environment. That gap is where the risk lives.
A machine identity is a digital credential that authenticates a non-human entity to a system, service, or application. Where a human identity typically consists of a username and password backed by MFA, a machine identity takes a different form depending on what it is authenticating and where. The credential proves the machine's right to act, access data, or call an API, with no human in the loop at authentication time.
Machine identities span a wide range of credential types. Understanding the distinctions between them matters because each type carries different risk characteristics, different lifecycle requirements, and different governance gaps.
NHI TypeWhat It AuthenticatesPrimary RiskTypical LifecycleService AccountBackground processes, scheduled jobs, internal servicesOver-permissioned, rarely reviewed, long-livedOften indefiniteAPI KeyApplication-to-application calls, third-party integrationsHardcoded in code or config, leaked in repositoriesRarely rotatedOAuth TokenDelegated user access granted to third-party appsInherited user permissions, persists after user offboardingVaries; often indefiniteTLS/SSL CertificateEncrypted machine-to-machine communicationExpiry gaps, misconfiguration, weak signing90 days to multi-yearAI Agent IdentityAutonomous agent acting on behalf of users or workflowsEmbedded credentials, probabilistic behavior, action chainingUndefined; no standard lifecycle
Each of these credential types represents a machine identity. Each one can be compromised, misconfigured, or abused. The last row on that table is the one most security programs have not yet addressed.
For a deeper look at how credential exposure works across these identity types, the analysis of AI agent OAuth token and credential exposure covers the technical attack surface in detail.
Security teams managing service accounts understand the risk profile: a long-lived credential with broad permissions that nobody reviews. AI agents carry that same risk, and then add several new dimensions that make them categorically more dangerous.
Traditional NHIs are passive. An API key sits in a configuration file and waits to be called. A service account runs a scheduled job on a fixed schedule. A certificate validates a TLS handshake. None of these entities decide what to do next. They execute a defined function and stop.
AI agents are active. An AI agent receives a goal, decides how to achieve it, selects tools to call, sequences those calls across multiple systems, and adapts its approach based on what it encounters. This is the difference between a passive credential and a probabilistic agent. The agent is not executing a script. It is making decisions.
That distinction has direct security consequences.
Action chaining: an agent can take one action that unlocks a second action, which unlocks a third. Each step expands the blast radius. A human reviewing the agent's configuration cannot predict this sequence in advance because the agent determines it at runtime.
Maker mode credential inheritance: many agents are built using the creator's credentials as the fixed authentication mechanism. Any user who invokes that agent executes with the creator's privilege level, regardless of what access that user was actually granted. A user without Salesforce access can invoke a Copilot Studio agent built by a Salesforce administrator and extract CRM data they were never authorized to see. The agent did exactly what it was designed to do. Your IAM controls were bypassed by design.
Confused deputy risk: an agent with elevated permissions can be manipulated into performing actions for an unauthorized user. The agent is not compromised. It is simply doing what it was asked, using credentials it legitimately holds, on behalf of someone who should not have that access.
These are not theoretical attack vectors. They are the operational reality of how agents work today. The question is not whether your agents carry this risk. It is whether you can see it.
Understanding over-permissioned agents is a prerequisite for addressing this risk. The full breakdown of overpermissioned AI agents and excessive access risk explains the specific permission patterns that create the widest blast radius.
The 25 to 50 times ratio between machine identities and human identities is an enterprise average (SailPoint). In some sectors, the ratio reaches 500 to 1. That number is growing, and AI agents are the primary accelerant.
Enterprises are now deploying thousands of AI agents per week. Low-code and no-code platforms like Microsoft Copilot Studio, Salesforce Agentforce, and n8n allow business users to build and deploy agents without involving security or IT. One enterprise discovered 2,500 agents already running before any inventory existed. Another found 377 Copilot agents through an assessment they had not planned to run. These are not outliers. They are the baseline for organizations that have adopted AI platforms without a parallel security program.
Several forces drive this proliferation simultaneously.
Low-code agent builders: when building an agent requires no engineering skill, the population of people who can create machine identities expands from a small developer team to every business unit in the organization. Each new agent is a new machine identity with embedded credentials, access to SaaS data, and no security review.
Agent-to-agent communication: agents increasingly invoke other agents as sub-tasks. When Agent A calls Agent B, Agent B's permissions become accessible through the interaction, even if Agent A was never granted those permissions directly. This creates machine identity chains that no single-platform tool can map.
Orphaned agents: when the creator of an agent leaves the organization or has their account disabled, the agent continues running with the inherited credentials. These orphaned agents represent active machine identities with no owner, no review, and no path to remediation under current processes. The security risks of orphaned and unsanctioned AI agents covers this specific failure pattern in depth.
The result is a machine identity surface that grows faster than any manual process can track. You cannot govern what you cannot see.
IAM programs were designed around a set of assumptions that do not hold for machine identities. Recognizing the architectural mismatch is the first step toward closing it.
The human lifecycle assumption: traditional IAM triggers access reviews when a human joins, moves, or leaves the organization. Managers certify access quarterly. Offboarding processes revoke credentials. Every one of these triggers assumes a human lifecycle event. Machine identities do not have lifecycle events in the same sense. An API key does not get promoted. An OAuth token does not change departments. An AI agent does not submit a resignation. Without lifecycle triggers, machine identity access accumulates indefinitely.
The interactive authentication assumption: IAM controls like MFA assume a human is present at authentication time. Machine identities authenticate programmatically. They cannot receive an MFA prompt. They operate continuously, often around the clock, without the behavior patterns that human-focused monitoring uses to establish a baseline. An agent running at 2 AM on a Sunday looks identical to an agent running at 2 PM on a Tuesday.
The monitoring gap: insider risk programs monitor human behavior for anomalies: unusual login times, bulk data downloads, access to sensitive files outside normal patterns. AI agents move 16 times more data than human users. They access systems across multiple platforms in a single workflow. Their behavior is inherently high-volume and cross-system by design. Applying human behavioral baselines to machine activity produces noise, not signal.
The permission review gap: access certification processes ask managers to confirm whether a human employee still needs a specific permission. No equivalent process exists for machine identities. Nobody reviews whether an AI agent still needs the OAuth scopes it was granted six months ago. Nobody asks whether the agent's blast radius has grown as new connectors were added. The account bloat and identity sprawl problem that plagues human identities is an order of magnitude worse for machine identities, with none of the existing governance mechanisms to address it.
Zero trust strategies face the same failure mode. When human access controls improve, attackers target service accounts, workloads, and API credentials instead. Without unified governance of machine and human identities, the "never trust, always verify" principle breaks down at the machine layer where static keys and long-lived credentials still dominate.
Security teams asking how to govern AI agent machine identities are asking the right question. The answer requires four capabilities that most programs do not yet have in place.
Inventory is the prerequisite for every other security conversation. A spreadsheet of known agents is not an inventory. An inventory is a continuously updated, authoritative record of every agent that exists, what platforms it runs on, what credentials it holds, what SaaS applications it connects to, and what actions it has taken.
This requires visibility across Copilot Studio, Agentforce, Amazon Bedrock, Google Vertex AI, n8n, ChatGPT Enterprise, and every other platform where agents are being built. A single pane of glass across all of these platforms is the starting point. Without it, security teams are ghost chasing: reviewing theoretical configuration signals with no evidence of what agents are actually doing.
Every machine identity needs a named owner who is accountable for its access, its behavior, and its lifecycle. This is not a new concept for human identities. It is almost entirely absent for machine identities today.
Named ownership enables two critical governance functions. First, it creates a path for remediation when a risk is identified. Second, it creates a trigger for review when the owner's status changes. An agent whose owner account is disabled is an orphaned agent running with inherited credentials and no accountability. Named ownership, tied to identity events, closes that gap.
Machine identity lifecycle management cannot depend on manual review cycles. It needs to be event-driven. When an agent creator's account is disabled, the agent's credentials should be flagged for review automatically. When a connector's OAuth grant is expanded, that change should trigger a permission review. When an agent is connected to new data sources, that connection should be logged and assessed against policy.
This is effective authority management: knowing not just what the agent is configured to do, but what it can actually do at any given moment, and ensuring that picture updates in real time as the environment changes.
Configuration tells you what an agent is set up to do. Runtime monitoring tells you what it actually did. These are not the same thing, and the gap between them is where machine insider risk lives.
Runtime monitoring for AI agent machine identities means capturing what tools an agent called, what data it accessed, who invoked it, and whether the invoker's identity was consistent with the agent's intended use. It means correlating the runner's identity with the maker's permissions and flagging cases where a user accessed data through an agent that they could not have accessed directly.
Deterministic guardrails applied at runtime enforce fixed rules on probabilistic agents. The agent may decide dynamically what actions to take. The guardrails determine which of those actions are permitted. This is the control architecture that machine identity management requires for the agentic era.
See your machine identity exposure today. Obsidian's AI agent risk assessment surfaces every agent in your environment, maps effective authority, and flags toxic combinations across your entire SaaS fabric. Start your assessment