Non-human identities: securing service accounts, workload identities, and AI agents

what non-human identities are

Non-human identities are credentials used by software to authenticate and access systems, APIs, or data.

Service accounts. An account tied to an operating system, directory, or application rather than to a person. They authenticate background processes: a scheduled export script, a monitoring agent, an application connecting to a database. They appear in Active Directory, Google Workspace, Entra ID, and most SaaS platforms under names like "service principals" or "technical users."

API keys and tokens. Credentials that authorize programmatic access to an API or service. Often static, rarely rotated, and stored in places that are difficult to inventory: environment variables, configuration files, secrets managers, and sometimes directly in source code repositories.

Workload identities. Credentials assigned to specific compute workloads: containers, virtual machines, serverless functions, CI/CD pipelines. In cloud environments they are provisioned through the provider's IAM layer (AWS IAM roles, Azure managed identities, Google service accounts) and may exist at scale and with significant access.

OAuth grants and service connections. When a SaaS application is authorized to access another, the resulting OAuth grant is a form of non-human identity. The integration has permissions that persist independently of the person who granted them. If that person leaves, the grant remains.

Bots and automation accounts. Accounts used by RPA tools, test frameworks, and workflow automation platforms. These often hold the same access level as the person who set them up, including read and write access to production systems.

AI agents. Software that operates autonomously to complete tasks, typically by calling tools and APIs on behalf of a user or system. The identity question is not just what credentials the agent holds, but what permissions it acts with when it executes a task. This is covered in its own section below.

why they outnumber human identities and keep growing

The ratio of non-human to human identities has shifted significantly as organizations adopted more SaaS tools, built more automation, and moved more workloads to cloud infrastructure. Every new application integration creates at least one NHI. Every cloud workload that calls an API requires a credential.

The Verizon 2024 Data Breach Investigations Report found that credentials are involved in the majority of breaches, and the scope of valid credentials being misused has expanded to include non-human credentials. Where a decade ago the primary credential risk was compromised user passwords, today it includes API keys committed to public repositories, leaked OAuth tokens, and over-privileged service accounts with no rotation history.

The growth is structural. APIs are the integration pattern for modern software. AI agent architectures multiply the number of autonomous software processes that require access. The number of NHIs tends to increase faster than the team's capacity to govern them, because creating a service account or API key is a routine developer operation and governance has no equivalent routine removal process.

why they are hard to govern

No joiner-mover-leaver trigger. NHIs are not people. There is no HR record, no employment event, no offboarding workflow. When the application an NHI served is decommissioned, there is no automatic trigger that removes it. The account persists until someone explicitly removes it, and that someone has to know it exists.

No assigned owner by default. Service accounts and API keys are typically created by whoever needs them at that moment. The creator is not necessarily the long-term owner, and ownership is rarely documented. When the creator leaves, the account becomes genuinely unowned.

Broad standing privileges. Permissions are almost always set at creation for whatever was needed to make the integration work. Narrowing them requires testing that the integration still functions with reduced access, which takes time the creator did not have. The result is standing privilege: broad access that exists continuously, whether or not the workload is running.

Long-lived or never-rotated credentials. Non-human credential rotation is a manual, application-aware process: rotating an API key requires updating every place it is used. Without a rotation schedule and automation, credentials persist indefinitely.

Absence from access reviews. Standard reviews pull user lists from directories and ask resource owners to confirm access. NHIs typically do not appear in these lists. The result is review programs that meet compliance requirements for human accounts while leaving non-human identities entirely unreviewed.

Invisible in SaaS environments. Each SaaS application manages its own API keys, service connections, and OAuth grants independently. An organization might have hundreds of OAuth grants across its SaaS stack and no single place to enumerate them.

the specific risks

Orphaned service accounts. A service account whose purpose has ended but whose credentials remain active. If those credentials are exposed, the access they carry is live. An attacker who obtains them does not need to know what the account was for; they only need to know what it can reach.

Over-privileged workloads. A container, function, or pipeline holding more access than its current function requires: admin access granted during development never narrowed for production, a data pipeline with write access to a database it only reads. Broad permissions at creation with no review is the default pattern in most environments.

Leaked secrets. API keys and credentials committed to repositories, exposed in configuration files, or logged in plain text. The GitHub advisory database consistently identifies exposed credentials as one of the most common categories of secret exposure. A leaked secret cannot be considered revoked until it is rotated, and rotation requires knowing the leak occurred.

AI agents acting with delegated permissions. When a user authorizes an AI agent to act on their behalf, the agent may receive the user's permissions across email, calendar, file storage, and more. If the agent is compromised, misconfigured, or manipulated through prompt injection, it can perform actions with the user's full access level.

Lateral movement via service credentials. A compromised service account credential does not trigger the same alerting as a compromised user account, because service accounts are expected to authenticate from processes. Lateral movement using service credentials can go undetected longer. The MITRE ATT&CK framework documents valid account credentials, including service accounts, as a primary technique for persistence and lateral movement.

AI agents as an emerging NHI class

AI agents are autonomous software processes that use tools and APIs to complete tasks. A user might authorize an agent to read email, create calendar events, query a database, and call an external API within a single workflow. The agent executes these using credentials it holds directly or that were delegated to it.

Delegation chains. An agent's permissions may be derived from the user's at the time of authorization, scoped down or not, and may persist beyond the original session. Understanding what an agent can access requires understanding the authorization scope it inherited.

Chained actions. A single instruction may trigger a sequence of API calls across multiple systems. The aggregate scope of what the agent can do across a workflow is often broader than any individual permission in the chain.

External service calls. Agents frequently call external APIs, including third-party AI services. Each call involves a credential and may involve sending data outside the organization, which intersects with data governance requirements.

Prompt injection as a credential attack. If an agent reads external content as part of its task, that content can contain instructions designed to manipulate its behavior. This is prompt injection, categorized in OWASP's LLM Application Security project as a primary attack vector. The relevant risk for NHI governance is that a compromised agent can act with its delegated identity in ways the user did not intend.

The practical governance requirement follows the same logic as all other NHIs: inventory them, assign an owner, scope permissions to the minimum required, define how credentials and authorization grants are reviewed and rotated, and monitor activity.

getting them under control: step by step

The process follows a consistent sequence whether the environment has a few dozen service accounts or hundreds of workload identities across multiple clouds.

Step 1: build an inventory. Pull non-human identities from every source: identity providers (service accounts, technical users, service principals), cloud platforms (roles, managed identities), SaaS applications (API keys, OAuth grants, service connections), secrets managers, source code repositories, and CI/CD platforms. Record at minimum: identity name, type, platform, what it can access, current permission level, credential type, and whether there is a recorded owner. This is the hardest step. An inventory that covers most but not all NHIs is substantially more useful than none, because it makes the gaps visible and measurable.

Step 2: assign an owner to every NHI. For each, identify a current employee who knows what it does, what it connects to, and who will handle it if it needs updating, reviewing, or disabling. Accounts without an assignable owner are the highest-priority items: an ownerless service account with access to production is an unmonitored credential with no responsible party.

Step 3: scope permissions to least privilege. Check what each NHI actually needs against what it has. Common findings: admin-level access that only needs read, broad write access on a read-only workload, access to multiple systems when the integration uses one, permissions inherited from a template. Narrowing requires testing that the reduced scope does not break the integration. Do it one high-priority account at a time, starting with the broadest access.

Step 4: establish a credential rotation schedule. Every credential should have a defined rotation interval. As a starting point: high-privilege credentials at least every 90 days, standard integration credentials at least every 180 days, and credentials whose exposure date is unknown treated as potentially exposed and rotated immediately. Automate where possible. Secrets management tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) can automate rotation for supported credential types.

Step 5: bring NHIs into access reviews. NHIs should appear in review cycles as a distinct category, not an afterthought in a human-focused review.

Step 6: monitor activity. An NHI with a clean inventory and scoped permissions is still a risk if its activity is never monitored. Log authentication and access events alongside human accounts. Set alerts for authentication outside normal patterns, access outside documented scope, use from unexpected source IPs, and authentication failures that could indicate credential stuffing.

bringing NHIs into access reviews

Cadence. High-privilege NHIs (admin-level service accounts, workload identities with write access to production, broad AI agent authorization grants) should be reviewed quarterly, matching human admin accounts. Standard integration credentials and read-only service accounts can follow the half-yearly cycle.

The review decision. For each NHI in scope, the reviewer confirms, modifies, or revokes.

Reviewer assignment. The right reviewer is the owner assigned in Step 2. Where none is assigned, the review defaults to the system or application owner.

What to check. That the identity is still actively used (last-used data where available), the function it serves still exists, permissions match the current function, the credential has been rotated within schedule, and the owner assignment is current.

Orphan detection. Any NHI with no last-used activity in the previous 90 days should be flagged automatically as a candidate for revocation. Dormant accounts hold access no longer in active use, with no natural monitoring signal.

how this maps to SOC 2, ISO 27001, NIS2, and DORA

Non-human identity governance sits within the access control and identity management requirements all four major frameworks include. Governing NHIs is how you meet those requirements, not a separate track.

SOC 2. The criteria addressing logical access (CC6.1, CC6.2, CC6.3) apply to all accounts, not only human ones. Auditors look for evidence that non-human accounts are in access review scope. Service accounts with broad permissions and no review history are a common exception.

ISO 27001. Control 5.18 covers access rights management, including review, adjustment, and revocation when no longer needed. The standard does not limit this to human users. An ISMS audit that surfaces undocumented, unowned service accounts with broad permissions will typically raise findings here.

NIS2. Article 21 requires access control policies including privileged access management. Non-human identities with admin or production access fall squarely within this scope.

DORA. Article 9 includes access control as a mandatory domain with specific attention to privileged accounts. Service accounts with access to critical financial systems are in scope, and DORA expects documented controls, defined ownership, and demonstrable review processes.

GDPR. NHIs that access systems containing personal data are subject to the technical and organizational measures required under Article 32. An unowned service account with read or write access to a personal data store is a gap in access control with direct data-protection relevance.

common failure modes

Inventory never built. Without an inventory, every other step is impossible. Organizations that have run access reviews for years but never included NHIs typically do not know what exists.

Inventory built, never maintained. A one-time discovery exercise decays rapidly as new accounts and grants accumulate. Treat NHI inventory as a live record, updated as part of provisioning rather than as a periodic project.

Rotation skipped because it is operationally complex. Rotating credentials used by running applications requires coordination and can cause outages if mishandled. Secrets management tooling exists specifically to reduce this. Start with the highest-privilege, longest-standing credentials.

NHIs excluded from reviews because they do not fit the template. The most common response is to leave them out, producing a review program that satisfies auditors on human access while leaving the fastest-growing credential category unreviewed.

No monitoring of NHI activity. Without monitoring, a compromised service account credential may operate undetected. Service accounts have predictable usage patterns, so deviations are easier to detect than in human traffic.

AI agents authorized without scoped permissions. Agent authorizations are sometimes granted with the same scope as the authorizing user's full permissions. Scoping to the minimum required is least privilege applied to a new identity class.

tooling: what to look for

NHI governance can start manually, with spreadsheets for inventory, calendar reminders for rotation, and adapted review templates. At small scale this is sufficient. As the number grows, manual processes fail for the same reasons they fail with human accounts.

The core functional requirements across the NHI management category are consistent: discovery (automated enumeration across directories, cloud, SaaS, and secrets stores), owner assignment and tracking, permission analysis (current versus required), secrets management and rotation, activity monitoring, and integration with access review workflows.

Cloud providers offer native tooling for workload identities within their platforms (AWS IAM Access Analyzer, Azure Entra Workload Identities, Google Cloud IAM Recommender), but these do not cover cross-cloud or SaaS-hosted NHIs. For SaaS stacks, OAuth grant management is a distinct gap; dedicated SSPM tools surface grants with broader coverage. For secrets management, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and comparable offerings provide the automation that makes rotation feasible at scale. The right starting point in most environments is building the inventory manually, then evaluating tooling against the specific gaps it reveals.