AI agents are non-human identities, but a different risk class than service accounts. Learn how non-human identity management must evolve to govern probabilistic agents.
Security teams ask a reasonable question: what exactly counts as a non-human identity? The answer covers more ground than most IAM programs currently govern.
A non-human identity (NHI) is any digital credential that authenticates a machine, application, or automated process without requiring a human to log in interactively. NHIs are created by developers, business users, vendors, and increasingly by other machines. They operate continuously, often with no session timeout, no MFA requirement, and no quarterly access review. They are the identities your IAM program was not designed to handle.
The NHI umbrella includes five primary types:
The first four types have existed for years. Security teams have built governance frameworks, rotation policies, and vault strategies around them. AI agents are different. They arrived at enterprise scale faster than any previous NHI category, and they do not behave like any of the others.
The 25-to-50x ratio of NHIs to human identities (SailPoint) was already a governance challenge before AI agents entered the picture. One enterprise discovered 2,500 agents already created in their environment before any inventory existed. Another found 377 Copilot agents through an assessment they had not planned to run. AI agents are accelerating the NHI ratio at a pace that outstrips every existing tracking mechanism.
Security teams often reach for the service account mental model when they first encounter AI agents. Both hold credentials. Both operate without human interaction. The comparison stops there.
Service accounts are static and fixed-function. A service account created to run a nightly database backup does exactly that. It authenticates, executes the defined task, and stops. Its behavior is predictable because its function is predetermined. When a service account deviates from expected behavior, that deviation is detectable precisely because the expected behavior is so narrow.
AI agents are autonomous and probabilistic. An AI agent given a goal does not follow a fixed script. It reasons about which tools to call, in what sequence, and with what parameters. It makes decisions. Its behavior at runtime depends on the input it receives, the tools available to it, and the reasoning path its underlying model takes. Two identical agents given the same instruction may take different action sequences. That is not a bug. That is how probabilistic agents work.
This distinction has direct security implications. You cannot write a behavior policy for an AI agent the way you write one for a service account. Configuration is not reality. What the agent is set up to do on paper does not tell you what it will actually do at runtime.
DimensionService AccountAI AgentBehaviorFixed, scripted, deterministicAutonomous, reasoning, probabilisticFunctionSingle defined taskMulti-step goal completion across toolsLifecycleCreated by IT, tied to applicationCreated by any user, tied to a goalCredential typeUsername/password or managed identityOAuth tokens, embedded API keys, maker mode credentialsAccess scopeDefined at creation, rarely reviewedInherited at runtime, often broader than neededPrimary riskOrphaning, over-privilege, no rotationAction chaining, privilege escalation, maker mode bypassGovernance approachVault, rotation, periodic reviewRuntime monitoring, ownership tracking, effective authority mappingAudit trailApplication logsCross-platform runtime evidence required
The governance gap is ownership. Security practitioners consistently report thousands of service accounts that no one can confidently explain, with high privilege and no assigned owner. AI agents inherit that same ownership problem and add autonomous decision-making on top of it. The accounts nobody remembers creating are now the accounts that can take action.
For a detailed look at how over-permissioned agents create compounding risk, see the analysis of overpermissioned AI agents and excessive access risk.
Certificates and API keys represent the other dominant NHI category. They are passive machine-to-machine credentials. A certificate proves identity during a TLS handshake. An API key authenticates a request. Neither one decides what to do with the access it enables. The system calling the credential makes that decision.
AI agents are not passive. An AI agent holds credentials the way a human employee holds a badge. The badge does not open doors on its own. But the employee decides which doors to approach, in what sequence, and for what purpose. An AI agent does the same with its tokens and keys: it uses them as fuel for autonomous action across multiple systems.
The credential inheritance distinction is where the risk diverges sharply. An API key embedded in a configuration file has a fixed scope. It can call the endpoints it was provisioned for. It cannot decide to call additional endpoints, chain those calls into a multi-step workflow, or escalate its own access. An AI agent can do all three.
Consider the ShinyHunters exploitation of stolen bearer tokens from a Salesloft-Drift integration. Attackers accessed Salesforce environments across more than 700 organizations without triggering authentication alerts because the token traffic looked identical to legitimate integration activity. That breach used passive credentials as the entry point. Now consider what happens when the credential holder is an AI agent that can reason about what to do next, which additional systems to query, and how to chain those queries into a data extraction sequence. The passive credential becomes the ignition key for autonomous action.
AI agents also introduce a credential inheritance pattern that certificates and API keys do not. When an agent is built in maker mode, it runs using the creator's credentials. Any user who invokes that agent operates at the creator's privilege level, regardless of their own access rights. A user without Salesforce access can invoke a maker mode agent built by a Salesforce administrator and extract CRM data they were never provisioned to see. The certificate or API key did not create that risk. The agent's credential inheritance model did.
Understanding the full scope of AI agent credential exposure and OAuth token risk is essential before building any NHI governance policy that includes agents.
Four specific mechanisms make AI agents the highest-risk NHI type in most enterprise environments today. Each one is a gap that service account governance, certificate management, and API key rotation programs were not designed to address.
Action chaining: AI agents do not take single actions. They take sequences of actions across tools and systems. A human user without Salesforce access talks to an agent. The agent queries Salesforce, retrieves customer records, summarizes them in a document, and emails that document to an external address. Each individual action may appear within policy. The chain of actions constitutes a data exfiltration event. No single-system audit log captures the full sequence. Only runtime visibility across every system the agent touched can reconstruct what actually happened.
Maker mode credential inheritance: when an agent is configured using the creator's credentials, every user who invokes that agent operates at the creator's privilege level. This is not a misconfiguration in the traditional sense. It is a design pattern in platforms like Microsoft Copilot Studio. Security teams that rely on IAM controls to restrict user access have no visibility into the fact that those controls are being bypassed through the agent layer. The blast radius of a single maker mode agent with admin credentials extends to every user who can invoke it.
Effective authority versus theoretical configuration: most tools that claim to govern AI agents show security teams what the agent is configured to do. Effective authority is what the agent can actually do inside each SaaS application it connects to, after all entitlements resolve. Those two things are rarely the same. An agent configured with read-only access to a SharePoint site may have inherited credentials that provide write access to the entire tenant. Configuration review does not reveal that. Runtime truth does.
Orphaning at machine speed: when a service account owner leaves an organization, the account persists until someone notices. The same pattern applies to AI agents, but at a different scale. Agents are created by business users, not just IT administrators. When the creator's account is disabled, the agent continues running with inherited credentials. One enterprise discovered hundreds of agents whose creators no longer worked at the company. Those agents held live credentials with no owner, no review, and no expiration. This is the machine insider risk that no existing insider risk program covers.
The guide to orphaned and unsanctioned AI agents details how these agents persist and what governance steps can reduce the risk.
Non-human identity management for AI agents requires a different governance model than the one built for service accounts and certificates. The principles are the same. The mechanisms must be rebuilt for autonomous, probabilistic systems.
Unified NHI governance across the full identity spectrum: boards and security leadership often believe access is under control because reviews run on schedule. The real risk lives in lingering entitlements, especially for non-human identities that were never included in the review cycle. Effective non-human identity management treats human identities, service accounts, certificates, API keys, and AI agents as a single governance domain. Separating them creates coverage gaps that attackers exploit.
Inventory as the prerequisite for everything else: you cannot govern what you cannot see. A complete AI agent inventory answers the questions security teams currently cannot: which agents exist, which platforms they run on, who created them, what credentials they hold, and what data they can actually access. That inventory must span sanctioned and unsanctioned agents across every platform in the environment. A single pane of glass across Microsoft Copilot Studio, Salesforce Agentforce, Amazon Bedrock, Google Vertex AI, n8n, and ChatGPT Enterprise is the foundation of any NHI program that includes agents.
Named ownership tied to identity events: every agent must have a named owner. That ownership must be enforced through the identity lifecycle. When an owner's account is disabled, the agent must be flagged immediately, reviewed, and either reassigned or decommissioned. Every agent should carry its own unique identity from the moment it goes into production, and every agent action should be traceable back to a human decision.
Least privilege enforced at the agent level: agents should receive task-scoped access, not standing privileges. An agent built to summarize customer support tickets does not need write access to the CRM or read access to financial records. Enforcing least privilege for AI agents requires understanding effective authority, not just reviewing configuration.
Runtime monitoring as the control layer: configuration review tells you what agents are set up to do. Runtime monitoring tells you what they actually did, which credentials they used, which data they accessed, and whether any of that was policy-aligned. For probabilistic agents, deterministic guardrails applied at runtime are the only reliable enforcement mechanism. Reviewing logs after an agent has completed an action chain is ghost chasing. Seeing the chain as it executes is runtime truth.
Know what your agents can actually do. Obsidian's AI agent risk assessment maps effective authority across every platform in your environment and surfaces orphaned agents, maker mode configurations, and toxic combinations you cannot see with configuration review alone. Start your assessment