Non-human identity for AI agents, explained

by Sujay ChoubeyOct 9, 202615 min read
MCP Gateway

TL;DR: Non-human identity (NHI) for AI agents is a distinct identity class that requires runtime attestation, policy-as-code enforcement, and lifecycle automation mapped to NIST RMF and ISO 27001. Unlike static service accounts, AI agent identities can request permissions dynamically and act autonomously. A defensible NHI program enforces controls at the infrastructure layer, not the prompt layer, and maintains comprehensive audit trails. Composio provides action infrastructure for knowledge work agents with 1,500+ business systems, 50,000+ agent-ready tools, 1 million+ connected accounts, and 1B+ tool calls, operationalizing these controls through credential isolation, policy-as-code enforcement, and centralized audit logging.

Your IAM program governs the identities you can see. The problem is that AI agents create identities faster than your access review cycle can inventory them.

In cloud-native environments, reported ratios of non-human identities to human users range from 82:1 to 144:1 (CyberArk, Entro Labs). For AI agents, that ratio compounds daily because each agent can mint new credentials at runtime. Traditional IAM models, designed for static human users with quarterly access reviews, cannot govern credentials that acquire permissions dynamically and act without human review.

This article defines non-human identity for AI agents, maps it to NIST RMF and ISO 27001 control families, and provides operational workflows that produce audit-ready evidence.

Defining non-human identity for AI governance

Non-human identity (NHI) refers to any digital identity that authenticates to systems and acts on them without a human operator. This includes service accounts, API keys, OAuth tokens, machine certificates, and the credentials wielded by AI agents.

AI agent identity is a distinct sub-category of NHI. Unlike static service accounts (which hold fixed permissions and execute predefined tasks), agentic identities are:

  1. Issued at runtime: The platform mints credentials dynamically when the agent executes, rather than provisioning them in advance.

  2. Permission-acquiring: The agent requests scopes and access rights based on the task, not a fixed role definition.

  3. Acting without human review: The agent determines what action to take based on model reasoning, not a human approval workflow.

These three characteristics break the assumptions baked into traditional IAM. Static service accounts can be inventoried, reviewed quarterly, and deprovisioned on a schedule. Agentic identities operate at a velocity that outpaces human access review cycles.

Comparing human and machine access

Human IAM assumes a discrete identity (an employee), a fixed role (a job function), and a review cycle (quarterly access recertification). Machine identity, and specifically agentic NHI, violates all three assumptions. Agentic identities are ephemeral, roles are dynamic, and review cycles cannot keep pace with credential issuance. Of 420 CISOs surveyed, only 53% could enumerate fewer than half of the machine identities in their environments with confidence.

Reducing risk through identity governance

The blast radius of a compromised agentic NHI is larger than a static service account because the agent can acquire new permissions at runtime. A static service account with read-only access to a database cannot suddenly gain write access, but an AI agent with dynamic scope acquisition can request elevated permissions if the policy layer allows it.

According to CSA and Astrix survey data, only 20% of organizations have a formal process for offboarding and revoking API keys. Former employee integrations or forgotten service accounts persist undetected with no one monitoring them.

Zero Standing Privilege (ZSP) for AI agents means no persistent, always-on privileged access rights are provisioned to the agent identity. Privileged access is granted only when required, for a limited time and specific scope, and is automatically revoked after use. ZSP is a stricter privilege model than Just-in-Time (JIT) access because it removes standing entitlement entirely until access is explicitly requested and approved.

Beyond human access: Governing machine identities

Traditional IAM models fail for agentic NHIs in four specific ways:

  1. Access review velocity mismatch: Quarterly access reviews cannot keep pace with credentials issued hourly or daily.

  2. Lack of formal lifecycle management: Most organizations have no structured process for rotating or revoking agent-issued credentials.

  3. Static credential assumption: Industry research shows 71% of machine identities are never rotated within recommended timeframes.

  4. Over-privileged machine accounts: Research indicates 42% of machine identities carry privileged or sensitive access, showing that role-based access control models designed for discrete human users do not naturally constrain machine identity permissions.

Lifecycle velocity for AI identities

AI agents can mint credentials, use them to call external APIs, and discard them rapidly. If your access review cycle is quarterly, you are always 90 days behind the actual state of your NHI inventory.

Secure storage for machine identities

Store credentials for AI agents in a centralized vault with AES-256-GCM encryption at rest and isolate them from both the application code and the LLM context. The agent calls a tool, the platform resolves which connected account to use, decrypts the credential inside an isolated runtime, injects it into the outbound HTTP request, and returns the response. The credential never reaches the model or appears in your application layer.

Composio's token custody architecture documents this isolation model. Tokens are stored with AES-256-GCM encryption at rest, isolated from application code and the LLM context window. Composio's action infrastructure handles 1B+ tool calls across 1,500+ business systems, with credentials that never reach the model or appear in the application layer.

Automating machine identity lifecycle

Manual lifecycle management does not scale for agentic NHIs. Automate the lifecycle:

  1. Issuance: The platform mints credentials at runtime with scoped permissions.

  2. Attestation: The platform cryptographically verifies the agent's runtime environment before granting access.

  3. Revocation: The platform revokes credentials automatically when the task completes or the session ends.

  4. Rotation: The platform rotates long-lived credentials on a schedule rather than leaving them static.

Evidence mapping for AI agent activity

Log every tool call with user, team, tool, action, and outcome, including denied calls. The log must answer: who (which identity) initiated each session, what command or query was issued, and what the outcome was. If a service account writes its own access log, that log is a claim, not evidence. The record must be produced and stored by something the non-human identity does not control.

Automating identity issuance for autonomous agents

Identity issuance for AI agents happens at runtime, not during a provisioning workflow. The agent requests a credential, the platform validates the request against policy, and the credential is issued with scoped permissions.

Validating agent identity at runtime

Runtime validation requires more than checking a bearer token. The platform must verify that the request came from the expected workload, the approved binary, or the attested runtime environment. A token may say access should be allowed, but attestation asks whether the caller is the approved agent runtime that policy expects.

Automating agent identity governance

Automated governance means policy-as-code enforcement evaluates access restrictions in the request path before any model interaction. An admin disables the "delete" action for a Slack integration. The agent cannot delete, regardless of what the prompt says, what the model reasons, or what a user tries to inject. This is enforced in the request path before the call is ever made, not a soft guardrail.

Managing agent credentials per NIST RMF

NIST SP 800-53 maps credential management to the Identification and Authentication (IA) control family. Specific controls include:

  • IA-9 (Service Identification and Authentication): Organizations apply this control to uniquely identify and authenticate non-human identities, including AI agents, service accounts, and API-based integrations, before access is granted.

  • IA-5 (Authenticator Management): Organizations apply this control to manage authenticators, verify identity before issuance, establish administrative procedures, change defaults, and protect content.

Mapping issuance to NIST controls

The Access Control (AC) family governs who has access to which assets. Specific controls for agentic NHI issuance include:

  • AC-2 (Account Management): Organizations typically implement automated provisioning and deprovisioning of agent identities under this control.

  • AC-3 (Access Enforcement): Organizations apply policy-as-code enforcement in the request path under this control.

  • AC-6 (Least Privilege): Organizations implement scoped permissions granted at runtime and revoked on task completion under this control.

Verifying agent integrity with trust anchors

Attestation is the process of cryptographically proving that a request came from the expected system or workload. For AI agents, attestation adds evidence to machine-to-machine access decisions, which is especially valuable when bearer tokens alone cannot distinguish a real integration from an attacker replaying credentials.

Securing AI identity with attestation

Runtime attestation is a verification step that proves a workload, agent, or service is actually executing in the expected state at the moment it requests access. Runtime attestation reduces blind trust in credentials alone. A token may say access should be allowed, but attestation asks whether the caller is the approved binary, image, enclave, or agent runtime that policy expects.

Runtime vs. build-time attestation

Build-time attestation verifies software release integrity (provenance attestation, SLSA, SBOM), while runtime attestation verifies the agent's execution environment at the moment of access. Both are required: build-time attestation proves the agent was built from approved code, and runtime attestation proves the agent is running in an approved environment.

Establishing NIST-aligned trust anchors

NIST SP 800-207 (Zero Trust Architecture) requires explicit verification of every access request, regardless of network location. For agentic NHIs, trust anchors include:

  • Workload identity: SPIFFE or similar workload identity frameworks.

  • Hardware attestation: RATS/EAT for hardware root-of-trust.

  • Policy enforcement point: The infrastructure layer where policy-as-code is evaluated before the request reaches the model.

Standardizing machine identity revocation workflows

Revocation is the most frequently neglected phase of the NHI lifecycle. Orphaned accounts, deprecated integrations, and forgotten service accounts retain access long after they should have been deprovisioned.

Linking AI identities to state data

Every agent identity must be linked to the task, session, or workflow that created it. When the task completes, the identity is revoked. When the session ends, the credential is invalidated. When the workflow terminates, all associated credentials are deprovisioned.

Automating machine identity revocation

Automated revocation requires a policy engine that can evaluate revocation triggers in real time. Triggers include:

  1. Task completion: The agent's task is done, revoke the credential.

  2. Session expiration: The session token expires, revoke the associated credentials.

  3. Policy violation: The agent attempts an action outside its approved scope, revoke immediately.

Closing security gaps in orphaned accounts

Orphaned accounts are credentials that persist after the employee, contractor, or integration that created them has departed. These accounts are invisible to traditional IAM because they were not provisioned through the standard employee lifecycle. Closing this gap requires a centralized inventory of all non-human identities, including OAuth tokens granted by individual employees and integrations onboarded without a formal security review.

Automating machine identity rotation

Credential rotation for agentic NHIs must be automated. Manual rotation does not scale when credentials are issued hourly. The rotation policy must define:

  • Rotation frequency: How often long-lived credentials are rotated (if any).

  • Revocation on rotation: The platform revokes old credentials immediately when it issues new ones.

  • Audit trail: The platform logs every rotation event with timestamp, identity, and outcome.

Mapping NHI controls to NIST RMF and ISO 27001

A defensible NHI program maps to NIST RMF and ISO 27001 control families and produces audit-ready evidence. The table below maps specific risks to NIST and ISO controls.

Risk

NIST Control

ISO 27001 Control

Unauthorized access

AC-3, AC-6

A.5.15, A.5.16

Credential theft

IA-9, IA-5

A.5.17, A.8.2

Lack of audit trail

AU-2, AU-3, AU-6

A.8.15, A.8.16

Orphaned accounts

AC-2

A.5.18

Over-privileged access

AC-6

A.8.2

Runtime integrity

SI-7

A.8.9

Mapping NIST RMF to AI agent identities

NIST SP 800-37 describes the Risk Management Framework (RMF) as a structured process for managing security and privacy risk. For agentic NHIs, the relevant control families are:

  • AC (Access Control): Governs who has access to which assets and under what conditions.

  • IA (Identification and Authentication): Ensures that identities are uniquely identified and authenticated before access is granted.

  • AU (Audit and Accountability): Logs events to document activities across the IT environment.

  • CA (Assessment, Authorization, and Monitoring): Continuously monitors the effectiveness of security controls.

  • CM (Configuration Management): Tracks and controls changes to the system configuration.

  • SA (System and Services Acquisition): Ensures that third-party services meet security requirements.

ISO 27001 controls for AI identities

ISO/IEC 27001:2022 Annex A includes specific controls for identity management and access governance:

  • A.5.15 (Access Control): Specifies the organization's rules regarding access to digital files and systems.

  • A.5.16 (Identity Management): The 2022 version widened this control deliberately. An identity can belong to a system, a service, a device, or a script just as easily as a person.

  • A.5.17 (Authentication Information): Governs the lifecycle of authentication credentials.

  • A.8.2 (Privileged Access Rights): Governs which non-human identities hold elevated permissions and how they are managed.

Generating audit-ready NHI logs

Audit-ready logs for NHI must include:

  1. Identity attribution: Who (which identity) initiated each session.

  2. Action logging: Every command or query issued during the session.

  3. Outcome recording: Success, failure, or denial for each action.

  4. Timestamp and duration: When the action occurred and how long it took.

  5. Immutable storage: The log is stored by something the non-human identity does not control.

Composio's audit log stores these records outside the non-human identity's control and includes denied calls alongside successful ones, giving IT teams a complete chain of custody to produce during an audit rather than reconstructing it after the request arrives.

Quantifying NHI security effectiveness

To justify NHI security investment to the CFO or board, quantify risk reduction in financial terms:

  1. Baseline risk exposure: Calculate expected loss from a compromised agentic NHI (blast radius, data sensitivity, regulatory fines).

  2. Control effectiveness: Measure the reduction in expected loss after implementing NHI controls.

  3. Cost of controls: Compare the cost of implementing NHI controls to the reduction in expected loss.

Securing AI agents: A compliance roadmap

Building a defensible NHI program for AI agents requires five operational steps:

Building a machine identity inventory

The first step is to inventory all existing non-human identities, including service accounts, API keys, OAuth tokens, and agent-issued credentials. This inventory must include:

  • Identity type: Service account, API key, OAuth token, agent credential.

  • Owner: The employee, team, or integration that created the identity.

  • Permissions: What scopes, roles, or access rights the identity holds.

  • Last used: When the identity was last active.

  • Review status: When the identity was last reviewed and by whom.

Enforcing least privilege for AI agents

Least privilege for AI agents means granting the minimum scopes and permissions required for the task, no more. This requires:

  • Scoped credentials: Credentials are issued with specific scopes, not broad roles.

  • Runtime policy enforcement: Policy-as-code evaluates access restrictions in the request path before the model is involved.

  • Zero Standing Privilege: No persistent, always-on privileged access rights are provisioned to the agent identity.

Audit logging for AI agent activity

Every tool call must be logged with user, team, tool, action, and outcome, including denied calls. The log must be immutable, queryable, and retained for the duration required by your compliance framework.

Optimizing machine identity review frequency

Quarterly access reviews do not scale for agentic NHIs. Organizations implementing NHI governance often match review frequency to credential velocity:

  • High-velocity credentials: Reviewed daily or in real time.

  • Medium-velocity credentials: Reviewed weekly.

  • Low-velocity credentials: Reviewed monthly.

Detecting non-human identity breaches

Breach detection for NHI requires monitoring for:

  • Anomalous access patterns: The agent requests permissions outside its normal scope.

  • Credential replay: The same credential is used from multiple locations or contexts.

  • Orphaned account activity: A credential that should have been revoked is still active.

Real-world examples of NHI breaches include the CircleCI 2023 security incident in January 2023, where threat actors compromised an employee's laptop and stole customer environment variables, tokens, and keys. Another example is the Codecov Bash Uploader supply chain attack in 2021, where attackers exfiltrated sensitive credentials from Codecov customers' CI environments.

A more recent example is the Azure Storage deletion incident disclosed in September 2026 (activity occurred in June 2026), where an Azure service principal credential was leaked in a public GitHub issue, stayed valid, and allowed an attacker to wipe Azure Storage.

When your next enterprise prospect asks where credentials are stored and how access is governed, Composio's centralized vault with AES-256-GCM encryption at rest and its SOC 2 Type II and ISO/IEC 27001:2022 certifications provide a documented answer before the question arrives in a formal security review.

Book a call to walk through your security requirements before the next enterprise review.

FAQs

How do I inventory existing non-human identities?

Start with your cloud provider's IAM console, your CI/CD pipeline's secret store, and your SaaS integrations' OAuth token lists. Industry research indicates many CISOs cannot enumerate all of their machine identities, so expect gaps.

What credential storage model scales for AI agents?

A centralized vault with AES-256-GCM encryption at rest, isolated from application code and the LLM context. The agent calls a tool, the platform resolves the credential inside an isolated runtime, and the credential never reaches the model or your application layer.

How often should agent credentials rotate?

High-velocity credentials (issued hourly or daily) should be revoked on task completion, not rotated. Long-lived credentials (if any) should rotate on a schedule defined by your risk tolerance, typically every 90 days or less.

Can non-human identity management integrate with existing IAM?

Yes, but traditional IAM models designed for static human users cannot govern agentic NHIs without additional controls. You need runtime attestation, policy-as-code enforcement, and automated lifecycle management layered on top of your existing IAM.

What audit evidence do regulators expect for NHI?

SOC 2 Type II and ISO 27001 auditors expect identity attribution, immutable audit trails, access approval and privilege justification, and evidence that controls are operating effectively over time. Auditors will flag findings when AI actions aren't attributable or when detection and response to security events aren't logged.

Key terms glossary

Non-Human Identity (NHI): Any digital identity that authenticates to systems and acts on them without a human operator, including service accounts, API keys, OAuth tokens, and AI agent credentials.

Agentic Identity: A sub-category of NHI issued at runtime, acquiring permissions dynamically, and acting without human review.

Policy-as-Code: Access restrictions evaluated in the request path as code, before the model is involved, not through prompt instructions the model can reason around.

Rotation: The process of replacing a long-lived credential with a new one on a defined schedule.

Audit Trail: A complete, immutable record of who did what, when, and with what outcome, including denied calls.

Get started

Your agents can
do more

Connect your agents to 1,500+ apps. Start for free, no credit card needed.

Are you an AI agent? See setup options

Share