Non-human identities now outnumber human users in most enterprise environments by ratios of 50:1 or more, and the gap is widening. Every microservice, CI/CD pipeline, OAuth-connected SaaS app, and increasingly every AI agent receives credentials, scopes, and persistent access — usually with weaker oversight than the intern who needs read-only access to a Confluence space. The August 2025 Salesloft Drift breach, which let attackers exfiltrate Salesforce data from over 700 organizations through stolen OAuth tokens, made the cost of that asymmetry concrete. So did Microsoft’s Midnight Blizzard incident in January 2024, where a forgotten legacy OAuth application became the pivot point into corporate email.
This article lays out what an access control policy for non-human identities should actually contain in 2026 — not aspirational principles, but the specific clauses, lifecycle requirements, and enforcement mechanisms that distinguish a policy that holds up under audit from one that exists only on paper. The shape of the problem has changed: agentic AI introduces identities that reason, delegate, and chain authority across systems, which legacy service-account governance was never built to handle.
Why Service Accounts and AI Agents Need Different Rules
A non-human identity (NHI) is any digital identity that authenticates without direct human action — service accounts, IAM roles, API keys, OAuth tokens, certificates, SPIFFE SVIDs, workload identities, RPA bots, and now AI agents. The OWASP Non-Human Identities Top 10, published in 2025, formalized this category, noting that NHIs are not controlled and often not intrinsically tied to a human, their identity object and authentication often work differently to that of a human, and common human user security measures do not apply to them.
The reasons traditional IAM fails here are structural. NHIs don’t go through joiner-mover-leaver workflows. They don’t authenticate with MFA. They’re spun up dynamically through Infrastructure-as-Code by developers who may not even own the resulting identity a year later. And they accumulate privilege silently — every time someone needs the pipeline to “just work,” the path of least resistance is broader scopes.
AI agents add another layer. Where a service account is static and purpose-bound, an agent is dynamic, often ephemeral, and capable of delegating its authority to sub-agents or invoking tools across trust boundaries. Unlike static service accounts or API keys, agentic identities are dynamic, ephemeral, and autonomous — they reason, delegate, and act across domains and trust zones, which means legacy NHI models simply don’t apply. A policy that treats an AI agent like a service account will leave delegation chains unaccounted for; one that treats it like a human user will collapse under the operational tempo.
The practical consequence: a single NHI policy must cover three distinct identity classes — workload identities, service accounts, and AI agents — with shared baseline controls and class-specific overlays.
What an NHI Access Control Policy Must Cover
A defensible policy covers seven domains. Skip any one and the gap becomes the first thing an attacker finds.
Identity inventory and ownership. Every NHI has a registered human owner and a backup owner, recorded in a system of record that survives the owner’s departure. Enforce accountability by registering agents in the directory with a mandatory human owner. Orphaned identities are the most cited failure mode in real breach post-mortems, because they’re invisible to access reviews and immune to offboarding.
Provisioning and authentication. Long-lived static credentials are forbidden by default. The policy mandates short-lived, automatically rotated tokens issued through workload identity federation — AWS IAM Roles, Azure Managed Identities, GCP Workload Identity, or the cloud-agnostic SPIFFE/SPIRE for cross-environment cases. Where static credentials are unavoidable (legacy systems, third-party integrations), they must be vaulted, rotated on a documented cadence, and tagged with an explicit exception that expires.
Authorization and least privilege. Permissions are scoped to the minimum set required for the identity’s declared purpose, with deny-by-default as the baseline and time-bound elevation for exceptions. Reuse of the same identity across applications or environments is prohibited — a violation OWASP tracks as NHI5:2025.
Lifecycle management. Creation, modification, dormancy detection, and decommissioning are codified with SLAs. An NHI that hasn’t authenticated in 90 days enters review; one that hasn’t in 180 days is deactivated automatically unless its owner justifies retention.
Monitoring and accountability. All NHI activity is logged with attribution. For AI agents specifically, logs must distinguish the subject (the human or upstream system that initiated the action) from the actor (the agent executing it), with the delegation chain preserved.
Third-party and OAuth integration governance. External applications granted OAuth scopes into the environment are inventoried, risk-rated, and reviewed quarterly. The Salesloft Drift breach is the canonical example of why this clause cannot be optional.
AI-agent-specific controls. Step-up authentication and human-in-the-loop approval for high-risk actions, intent-bound scopes, and instant revocation capability for misbehaving agents.
Mapping Policy Clauses to the OWASP NHI Top 10
The OWASP Non-Human Identities Top 10 — 2025 is the closest thing the industry has to a shared vocabulary for what an NHI policy must defeat. Compiled from recent breaches, CVE scores, and survey data including Datadog’s State of Cloud Security reports, the list ranks risks by exploitability, prevalence, detectability, and impact. A policy should be readable as a direct response to each item.
NHI10:2025 deserves its own emphasis. When developers manually run scripts using an NHI with permissions to production environments, errors or unauthorized changes become difficult to trace because logs attribute the actions to the NHI rather than the human. A policy should explicitly forbid administrators from using service-account credentials for interactive console access — convenience is the standard rationalization, audit failure is the standard outcome.
Lifecycle: Provisioning, Rotation, and Offboarding
Lifecycle is where most policies fail in practice. The principles are uncontroversial; the SLAs are what make them real.
Provisioning must be automated and tied to a request that captures purpose, owner, scope, and expected lifespan. When a new NHI is created, it should be assigned an owner, given scoped permissions, and added to an auditable inventory. Manual provisioning through cloud consoles is the path to shadow identities — the policy should require IaC or a centralized provisioning workflow for any production NHI.
Authentication credentials follow a hierarchy. Workload identity federation first: AWS IAM Roles for EC2 and EKS, Azure Managed Identities, GCP Workload Identity, and SPIFFE/SPIRE for cross-cloud or hybrid workloads. These eliminate the static credential entirely. Where federation isn’t possible, short-lived OAuth tokens with refresh flows. Static API keys and long-lived passwords are a last resort, vaulted in a secrets manager, rotated on a maximum 90-day cadence, and flagged as exceptions requiring annual re-justification.
Rotation is enforced through automation, not policy hope. The policy specifies maximum credential age — typically 90 days for static secrets, 7 days or less for service-to-service tokens — and the inventory system flags non-compliant identities for remediation. The OWASP guidance is direct: many cloud environments provide facilities for automatic generation of short-term credentials that obviate the need for hard-to-manage long-term secrets, including AWS Roles, Azure Managed Identities and the cloud-agnostic SPIFFE SVIDs.
Offboarding is the single most-violated clause. When an employee leaves, every NHI they owned must transfer to a new owner within a defined window (typically 30 days) or be deactivated. When an application is decommissioned, its NHIs are revoked the same day, not “eventually.” When an NHI hasn’t authenticated in 90 days, dormancy review triggers; at 180 days, it’s deactivated unless explicitly retained.
Authorization Model: Least Privilege at Machine Speed
The classic least-privilege challenge for NHIs is that “what the workload actually needs” is rarely documented and almost never minimal. Policies that simply state “least privilege required” without enforcement mechanism produce no behavior change.
What works:
Scope-bound provisioning. Every NHI request specifies the resources and actions required. The provisioning system generates a policy from that specification — not the other way around. Engineers cannot request “AdminAccess for now, we’ll tighten later.” For AI agents, scopes are bound to the agent’s declared intent and the delegating subject’s entitlements. An agent acting on behalf of a finance analyst inherits a subset of that analyst’s permissions, scoped further by the agent’s task.
Just-in-time elevation. Where elevated access is genuinely needed — incident response, scheduled batch jobs, deployment events — it’s granted for a bounded window and revoked automatically. Standing privilege is the exception requiring justification.
Continuous access evaluation. Permissions are not granted once and forgotten. Access reviews run quarterly for high-privilege NHIs, annually for all others. Automated tools flag privilege drift, dormant permissions, and identities that have never used scopes they hold.
Environment isolation. A non-negotiable: no NHI authenticates across production, staging, and development with the same credential. Separate identities per environment, separate vaults, separate audit trails.
AI Agent–Specific Provisions
The agentic class breaks assumptions baked into older NHI policies. Three provisions specifically address it.
Delegation-aware identity. Every agent action carries both the subject (the human or upstream service that initiated the chain) and the actor (the agent executing). OAuth 2.0’s token-exchange and subject-actor binding patterns provide the underlying mechanism. The policy requires that delegation chains be preserved in audit logs and that agent permissions never exceed those of the delegating subject — an agent cannot acquire authority its principal lacks.
Just-in-time agent provisioning. Long-lived agent credentials are forbidden. Agents are provisioned per task or per session, with credentials that include a TTL, the declared purpose, and the delegation context. Just-in-time provisioning eliminates credential sprawl before it starts — agent identities are provisioned on demand with attributes like TTL, purpose, risk, and delegation context attached, and when the task is done, the identity is retired.
Human-in-the-loop for high-risk actions. Sensitive operations — financial transactions above a threshold, production data modifications, external communications, infrastructure changes — require step-up authentication of the human principal before the agent can execute. The policy enumerates the action classes that trigger this and prohibits agents from performing them autonomously.
Instant revocation. Every agent must be terminable in real time. The policy mandates a kill switch — typically token revocation at the IdP combined with workload-level shutdown — with a documented response time (under five minutes is reasonable for production agents).
Tool-use governance. Agents that invoke external tools through Model Context Protocol (MCP) or similar mechanisms must be governed at the tool boundary, not just the agent boundary. Each tool invocation is logged, scoped to the agent’s current task, and subject to the same access policies as direct API calls.
Third-Party OAuth Integrations: The Salesloft Drift Lesson
The August 2025 Salesloft Drift breach is the policy case study of the year. The shape of the attack: UNC6395 stole data from Salesforce instances by exploiting compromised OAuth tokens from the Salesloft Drift app, beginning as early as Aug. 8, 2025 through at least Aug. 18, 2025. The blast radius: over a ten-day period, the attackers systematically queried and exported large volumes of records from more than 700 organizations, including Cloudflare, Google, PagerDuty, Palo Alto Networks, Proofpoint, SpyCloud, Tanium, and Zscaler.
What the attackers did with the access matters as much as how they got it. Stolen records were combed for plaintext AWS keys, VPN credentials, Snowflake tokens, and other secrets that could enable follow-on compromises. Customer support cases — text fields where engineers paste credentials when troubleshooting — became a credential mine.
The policy implications are concrete. OAuth integrations are inventoried and risk-rated based on the data they can access. Third-party tokens are treated as first-class NHIs with rotation and scope-review requirements. Anomaly detection on integration API traffic — unusual query volumes, off-hours activity, novel User-Agent strings — is mandatory for high-risk integrations. And the corollary policy on the human side: support case content and ticket bodies are scanned for embedded secrets, with policies forbidding pasting credentials in plaintext.
The Microsoft Midnight Blizzard breach reinforces the same point from a different angle. After gaining access to a non-production Microsoft 365 test tenant, the attackers exploited a legacy OAuth application — an unmanaged non-human identity — with full privileges to access Microsoft’s production environment. The policy clause that would have caught this: every OAuth application in the directory has an owner, a documented purpose, and a scheduled review. Forgotten apps are deactivated, not left running on the chance someone might still need them.
Regulatory and Standards Alignment
NHI policy doesn’t exist in a vacuum. Several frameworks anchor it.
NIST SP 800-63-4, finalized in July 2025, modernized the digital identity baseline with phishing-resistant authentication and continuous evaluation patterns. While the 800-63 suite remains primarily focused on human authentication — authentication of other than human claimants such as APIs is out of scope for SP 800-63-3 — its risk-based model and assurance-level framework inform how NHI policies should differentiate controls by impact.
NIST SP 800-53 Rev. 5 controls in the Access Control (AC) and Identification and Authentication (IA) families apply directly to service accounts and machine identities, particularly IA-5 (authenticator management) and AC-2 (account management).
The OWASP NHI Top 10 is the operational reference for what an NHI policy must defeat.
Cloud-provider baselines — AWS IAM best practices, Azure AD service principal guidance, GCP service account hardening — provide platform-specific implementation guardrails the policy should reference rather than restate.
Industry-specific overlays add requirements: PCI DSS 4.0 for payment environments, HIPAA for healthcare, FFIEC and SEC guidance for financial services. The August 2025 FINRA cybersecurity alert on the Drift breach is itself now part of the regulatory record financial firms must respond to.
For organizations subject to executive-branch federal requirements, US government-issued mandates like NSM-10, EO 14028, and OMB M-23-02 now require real-time cryptographic inventorying to strengthen national cybersecurity, which extends naturally to NHI inventory and credential management.
Frequently Asked Questions
Should AI agents be governed by the same policy as service accounts? Same policy, different overlays. Baseline controls — ownership, inventory, least privilege, lifecycle — apply identically. Agent-specific provisions for delegation, JIT provisioning, human-in-the-loop, and instant revocation extend the baseline rather than replace it.
How often should NHI access reviews happen? High-privilege NHIs (production write access, administrative scopes, broad OAuth grants) should be reviewed quarterly. All others annually. Automated tooling flags privilege drift continuously between formal reviews. Treat the review cadence as a floor, not a ceiling.
What’s the right ownership model when no human “owns” an NHI? There is no such case. If an NHI doesn’t have a human owner, it shouldn’t exist. When the original owner leaves or transfers, ownership transfers within 30 days or the NHI is deactivated. Team or DL ownership is acceptable as long as a specific human is accountable and identifiable.
How do you handle legacy systems that can’t use federated credentials? Document the exception with an expiration date, vault the credential, enforce the shortest viable rotation cadence, and add compensating controls — typically network restrictions, enhanced monitoring, and explicit anomaly alerting. Treat the exception as a remediation backlog item, not a permanent state.
The Stance Worth Taking
Most NHI access control policies fail not because they’re missing principles but because they’re missing teeth. Every policy says “least privilege.” Few specify how requests are scoped, who validates them, how drift is detected, or what happens when an SLA is missed. The Salesloft Drift breach didn’t expose hundreds of organizations because they lacked policies forbidding excessive OAuth scopes. It exposed them because no one was enforcing the policies they had.
The change worth making in 2026 is treating NHIs — including AI agents — as first-class identities subject to the same rigor as human accounts, with overlays for what makes them different rather than gaps for what makes them inconvenient. Identities have owners. Credentials have lifespans. Scopes have justifications. Delegation chains have evidence. When those four things are true and enforced, the rest of the policy mostly writes itself.
When they’re not, the next breach post-mortem will read like the last one.
