Ask a CISO who owns the service account running last night’s batch job, and you’ll often get a shrug. That gap is the story of non-human identity. A non-human identity (NHI) is a digital identity assigned to software, from the service account behind a batch job to the AI agent running a workflow on its own. These identities authenticate, reach into sensitive data, and take action without a person ever signing in.
Every new service account or workload adds another identity to govern, and agents multiply the count fast. Autonomous AI agents inherit privileged access and act at machine speed, which means a leaked credential or an overstepping agent can move faster than the humans watching it.
Documented ownership is what lets teams respond, yet many NHIs have no owner on record. Because most can’t complete an MFA challenge, scoped credentials and audit trails that name a person carry most of the weight. This article walks through what counts as a non-human identity, what regulators now expect, and the five lifecycle controls that bring NHIs and AI agents under a single AI risk management model.
Key takeaways
- Non-human identities let software authenticate and act, but their limited MFA support and weak lifecycle triggers make named ownership, scoped access, and traceable actions essential.
- AI agents amplify NHI risk by inheriting privileged access, operating at machine speed, spawning sub-agents, and invoking external tools between periodic reviews.
- Effective compliance depends on retaining automated system audit trails and linking consequential actions and decisions to accountable people, with appropriate oversight.
- Strong NHI governance follows five lifecycle stages: discovery, human ownership, privilege right-sizing, runtime policy enforcement, and scheduled decommissioning.
Defining non-human identity
A non-human identity is a digital identity assigned to software, not to a person. It’s how a workload, application, script, or AI agent proves its identity when it calls an API, reads from a database, or writes to another system. Where a human identity is tied to an employee record and a login session, an NHI is tied to a credential, a workload, or a piece of code that runs on its own schedule.
The category is broader than “service account.” It covers anything that authenticates without a person at the keyboard: the token a SaaS integration uses to sync data, the certificate that lets one microservice trust another, the IAM role a Lambda function assumes for three seconds, the OAuth grant a marketing tool holds against your CRM, and the AI agent that reads a ticket, drafts a response, and updates a record. Some are long-lived and static; others are ephemeral and rotate every few minutes, but all of them can take action within your environment.
Two properties define the governance problem. First, NHIs don’t experience the human lifecycle events (hire, transfer, termination) that trigger access reviews, so they tend to accumulate and drift. Second, most can’t complete an MFA challenge or answer a security question, which means the compensating controls built for human accounts don’t apply. Governance has to come from somewhere else: a named human owner, a scoped credential, an audit trail that ties actions back to a person, and a scheduled decommissioning date.
You Can’t Secure What You Can’t See
WitnessAI gives you network-level visibility into every AI interaction across employees, models, apps, and agents. One platform. No blind spots.
Explore the PlatformTypes of non-human identities and how they authenticate
NHIs don’t authenticate in one uniform way. The credential type depends on where the identity lives and what it needs to reach, and each type carries its own leakage patterns, rotation demands, and human accountability gaps. The categories below cover the ones you’ll find in most enterprise environments:
- Service accounts: Directory-managed accounts (Active Directory, Entra ID, LDAP) that batch jobs, background services, and scheduled tasks use to log in and access shared resources. They often carry broad, standing privileges and long-lived passwords, which is why they show up so often in breach post-mortems.
- API keys and bearer tokens: Static strings that applications present to authenticate against external services and SaaS platforms. They’re easy to generate, embed in code or config files, and leak into repositories, logs, and screenshots.
- OAuth access and refresh tokens: Delegated credentials that grant application-scoped access to another system on a user’s behalf, common across Google Workspace, Salesforce, Slack, and marketing tools. The compromise of these tokens is what caused the Salesloft Drift breach to spread across so many downstream tenants.
- Machine identities (TLS certificates and SSH keys): Cryptographic credentials issued to servers, load balancers, and services to prove identity in machine-to-machine communication. Expired certificates cause outages; unmanaged SSH keys create quiet lateral-movement paths.
- Workload identities: Cloud IAM roles, Kubernetes service accounts, and container identities that let short-lived compute assume permissions without a stored secret. Powerful when scoped tightly, dangerous when a single role is reused across dozens of workloads.
- CI/CD pipeline identities: Build-system and deployment credentials that push code, pull artifacts, and touch production. They typically hold some of the most sensitive access in the environment and often live in pipeline variables rather than a vault.
- AI agents: Autonomous or semi-autonomous software that reasons, plans, and calls tools on behalf of a user or a system. Agents may inherit credentials or permissions from the humans or systems that invoke them, may delegate work to other agents, and can reach external services through tools and MCP servers.
A few traits cut across all of these categories and explain why traditional IAM struggles. NHIs typically can’t complete MFA and may lack a behavioral baseline that would let anomaly detection flag misuse. Their audit trails also rarely name a person. They rarely see the hiring, role changes or terminations that trigger reviews of human accounts, so drift accumulates.
Central IT governance can bring developer-created identities into a consistent process, including the ad hoc ones issued with long-lived credentials or permissions beyond their functional need.
OWASP now maintains a Non-Human Identities Top 10, which it describes as a list of the most pressing security risks and vulnerabilities that non-human identities present to organizations. Its 2025 Top 10 edition ranks risks such as improper offboarding and secret leakage using real-world breach data, and covers misuse of machine credentials alongside other NHI risks. The list is a useful scoping reference when you’re deciding which categories above deserve the most immediate governance attention.
Why AI agents turn NHI sprawl into an AI risk management problem
Agents don’t behave like traditional workloads. They make runtime decisions, choose which tools to call, and can delegate work to other agents mid-task, expanding the set of permissions, tools, and identities an organization may need to govern. The result is an identity population that expands and contracts as the workflow runs, not one you can inventory once and leave alone.
The behavior also isn’t as deterministic as a scheduled job. Two instances of the same agent, given the same prompt, may reach for different tools, follow different reasoning paths, and touch different systems. Governance built for predictable machine-to-machine calls has to stretch to cover that variability, which is why agent access is better framed by intent and least-privilege than by static role assignments.
When an agent acts under a shared credential, the audit trail names the credential and may omit the person. Compliance and legal teams may then struggle to show who authorized the action. A customer-facing agent may also lack a named person who stands behind what they told the customer.
OWASP’s agentic risk scoring framework describes agents as ephemeral proxies that temporarily assume the roles and permissions of the users or systems that trigger them.
Each agent deployment can expand the number of integration credentials an organization must govern. In the Salesloft Drift breach of August 2025, attackers used OAuth token theft to impersonate Drift across Salesforce and Google Workspace integrations. Slack integrations were also affected. The breach reached more than 700 organizations. The compromised credentials were integration tokens.
The expansion of agent deployments also increases machine-to-machine activity that rarely touches a browser. Agents reach external systems through MCP server connections. Agentic AI systems “introduce novel and systemic risks that established cyber defense strategies do not adequately address,” per the NSA’s May 2026 advisory. It names dynamic tool invocation and implicit trust between agents. In many organizations, governance is running behind deployment.
Blocking AI Isn’t a Strategy. Governing It Is.
WitnessAI enforces intent-based policies, routes prompts to the right models, and redacts sensitive data in real time so your teams keep moving while your data stays protected.
Explore ControlFive lifecycle controls for non-human identities
These five stages apply to service accounts and AI agents alike, though agents benefit from tighter runtime controls. Discovery and runtime enforcement are where agent-specific requirements are clearest.
1. Discover and inventory non-human identities
An identity without an inventory entry is less likely to receive an owner. Shadow AI can introduce applications, agents, identities, and credentials outside established governance workflows, making discovery a prerequisite for effective lifecycle control.
Start by scanning the environment rather than relying on the identities teams remember to declare. A useful inventory spans application installs, OAuth grants, API keys, agent frameworks, and MCP server connections, since each of these surfaces exposes credentials that rarely reside in a single system of record.
The goal is a single view of what’s actually authenticating in production, which then serves as the baseline for ownership, right-sizing, and downstream decommissioning.
2. Assign a human owner to each identity
Each discovered identity benefits from a named business or technical owner. That owner can explain the workload, its dependencies and the impact of changes. Some agents lose their ownership link in the HR record when their creator departs, which is how orphaned credentials survive.
Apply joiner-mover-leaver logic to agents as well. When an agent’s scope or model changes, its credentials and access should change with it. Tool changes should trigger the same review.
3. Right-size privileges based on autonomy
Over-permissioning is one of the most common failure modes across NHIs, and it’s rarely the result of a bad decision at any single step. Credentials get provisioned with broad access to unblock a deadline, the workload ships, and the scope never gets trimmed back. When a compromise eventually happens, the blast radius reflects what the identity could reach, not what it actually needed.
Agents make this worse because they don’t sit still. An agent’s real privilege surface is the union of every tool it can call, every system those tools can reach, and every sub-agent it can spawn along the way. Treating a low-autonomy assistant that summarizes documents the same way as an agent that can write to production isn’t just inefficient; it flattens risk in a way that makes both cases harder to defend.
Control intensity should scale with the agent’s autonomy: light guardrails for read-only assistants, stricter scoping and approval gates as the agent’s ability to act on its own grows.
4. Enforce policy at runtime
Periodic access reviews move at human speed, while agents act between reviews. Use pre-execution inspection to read prompts and tool calls before they run, and stop those that break policy.
Use response inspection to check outputs before they move downstream into tickets and records or into another agent’s context. Above a defined impact threshold, require an approval step to keep a human in the loop before the action proceeds.
5. Decommission identities on schedule
OWASP ranks Improper Offboarding first among NHI risks. Scheduled decommissioning closes live credentials when deprecated services reach the end of their use. Treat decommissioning as a planned lifecycle event with automated revocation.
What Does AI Compliance Look Like?
WitnessAI automatically logs every AI interaction, masks sensitive data in real time, and enforces regulatory policies across every region and business line. Audit-ready from day one.
See WitnessAI For ComplianceBringing non-human identities under AI risk management
Non-human identities accumulated quietly, one service account and API key at a time. Agentic AI removed the quiet. Agents typically inherit privileged access and often act between reviews. Their numbers can also grow faster than joiner-mover-leaver processes were designed to handle. Organizations adopting AI with confidence can identify which agents are live and what those agents can reach. They can also name the human who answers for each one.
Organizations that can name the human behind each agent can more clearly demonstrate accountability as agents move from pilot to production. That accountability can also make it easier to move agentic AI from pilot to production without governance questions becoming a late-stage blocker.
If your answer today lives in a spreadsheet, schedule a demo. See how WitnessAI combines network-level visibility and intent-based controls for human and agentic workforce governance with bidirectional runtime protection for models, applications, and agents. Runtime protection can be deployed through network integration or lightweight APIs.