What Is Machine Identity? Management, Risks, and AI Agents

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.

Industry estimates put machine identities somewhere between 25 and 50 times the number of human identities in a typical enterprise, and the direction of travel is one way.

Three forces drive it. Microservice architectures replaced one application holding one credential with dozens of services each holding their own. Cloud infrastructure made identities free and instantaneous to create, so they get created for every function, container, and pipeline. And SaaS integration means every connected application holds a token that acts inside another application.

AI agents are the fourth force, and they compound differently from the others. A microservice is created by a platform team through a pipeline, with some review attached. An AI agent is created by an employee in a web interface in about ninety seconds, and the credential it holds is usually that employee's own.

The consequence is a population problem. Human identity lifecycle is anchored to HR events: someone is hired, changes role, or leaves, and each event triggers a provisioning action. Machine identities have creation events but no natural termination events. Nothing tells you a service account's job was decommissioned six months ago. The credential simply keeps working.

A complete program addresses five stages. Most organizations are strong at the first and weak at the last two, which is precisely the wrong distribution.

Issuance. How credentials are created, by whom, and with what approval. This is the stage most programs handle well, because it is the one with an obvious workflow attached.

Inventory. Knowing which machine identities exist, what each is for, and who owns it. This is where programs start to degrade, because identities are created across many systems and no single console holds them all.

Scoping. Ensuring each identity's permissions match what its workload actually requires. Scoping is usually done once at creation and rarely revisited, so it decays continuously as new permissions are added and old ones are never removed.

Rotation. Replacing credentials on a schedule so a leaked secret has a bounded useful life. Certificates are usually rotated because expiry forces the issue. API keys and service account credentials frequently are not, because nothing forces it.

Retirement. Removing identities whose purpose has ended. This is the weakest stage almost everywhere, because retiring a credential carries the risk of breaking something unknown, and leaving it costs nothing visible. The rational local decision is to leave it, which is how orphaned credentials accumulate.

Ownership runs underneath all five. An identity nobody owns cannot be scoped correctly, because no one can say what it needs, and cannot be retired safely, because no one can say what breaks. Ownership gaps are the root cause behind most of what looks like a rotation or retirement problem.

An AI agent's credential is a machine identity like any other. What makes agents different is the relationship between the credential and the behavior.

Every other machine identity is deterministic. A service account runs the same job the same way every night. Its permissions describe its behavior almost perfectly, which is what makes traditional IAM review meaningful: read the grants and you know what the identity does.

An AI agent chooses. It receives a goal, decides which actions to take, and composes them in sequences nobody wrote in advance. Its permissions describe what it could do, and the gap between that and what it will do is not knowable from the grant list. Reviewing an agent's permissions tells you the outer boundary of its behavior, not its behavior.

Three properties follow.

Agents inherit rather than get provisioned. Most agents run on their creator's credentials, so the agent's reach equals a person's reach. That person was granted access over years, for reasons unrelated to this agent's task. Nobody decided the agent should have all of it.

Anyone who can prompt the agent borrows its access. A person with no access to a system can ask an agent that does have access, and the data comes back. No permission was bypassed, so no control fires. This is the machine insider pattern, and it is invisible to access reviews, which examine who holds permissions rather than who can reach someone who does.

Reach compounds across connections. An agent's authority is the union of everything it can reach in a session, including every MCP server and integration attached to it. Two individually reasonable connections combine into a capability neither one granted.

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.

Continuous Inventory Across Platforms

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.

Named Ownership for Every Machine Identity

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.

Lifecycle Tied to Identity Events

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.

Runtime Monitoring for Actual Behavior

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

Five steps, ordered so each one enables the next.

Build a real inventory, continuously. Cover service accounts, tokens, certificates, workload identities, and agent credentials in one place. Point-in-time collection produces a number that was true on the day it ran, which is not useful for a population that grows daily.

Assign an owner to every identity. Every credential needs a named person accountable for whether it should still exist. Identities without owners are the ones that survive indefinitely, and establishing ownership is the prerequisite for scoping and retirement both.

Resolve effective access, not declared permissions. For each identity, establish what it can actually reach inside the connected system today. This is the step that surfaces the real exposure, and it is the one most programs skip because the grant list is easier to read.

Score combinations rather than individual grants. Risk concentrates where capabilities stack. An identity that can read sensitive data and separately send data outward has a path that neither permission created on its own. Evaluate what one identity can reach across everything available to it.

Treat agents as their own class. Agent credentials need what other machine identities need, plus two things: creator visibility, since agents are made by individuals rather than platform teams, and runtime observation, since their permissions do not predict their behavior.

Obsidian applies this to the agent category specifically, building an inventory of AI agents and their connections across connected platforms from runtime activity, surfacing who created each one, resolving the effective access each holds inside your SaaS applications rather than what its configuration claims, and scoring the combinations that widen blast radius. Runtime enforcement is available today for Claude and Microsoft Copilot; other platforms are covered for discovery and governance.