Guide

NHI Audit & Compliance Mapping

What auditors and underwriters actually require, framework by framework

Every major compliance framework now expects organizations to demonstrate control over non-human identities, but none of these frameworks were written with machine identities as the primary subject. The control language is often general ("access control," "account management"), and the value of a mapping is in the specific sub-control an assessor will actually point to, not the general control family. This guide goes framework by framework across six standards — four general security and privacy frameworks, plus two that apply specifically to AI systems and EU financial entities — and covers the exact control, what an assessor wants as evidence, and where organizations most often fall short.

What this guide assumes

An inventory of non-human identities — service accounts, API keys, certificates, agent identities — that updates continuously, not a point-in-time export
Defined ownership mapping each non-human identity to a responsible team or individual
A credential rotation and revocation process with a documented service-level target
For the EU AI Act and DORA sections: an understanding of whether your organization's AI systems or financial-services status brings those frameworks into scope

What underwriters screen for before any framework specifics

Cyber insurance underwriters increasingly treat non-human identity governance as a renewal gate rather than a discount line item. What's driving that scrutiny is a question the frameworks haven't fully answered: as agents act under credentials that trace back to a human, the point at which responsibility actually lands when one of those actions goes wrong stops being settled — precisely the exposure an underwriter is trying to price. Before getting into framework-specific evidence, they check for three things.

Continuous inventory, not a snapshot. Underwriters increasingly ask for an automated, self-updating inventory of every machine account, API key, and certificate — with explicit ownership mapped to a team or individual for each one. A quarterly spreadsheet export, however thorough, doesn't qualify. The question isn't whether the inventory was accurate when it was taken; it's whether it's accurate right now.

An orphan remediation process with a real deadline. When an employee leaves, their human accounts get disabled automatically through the identity provider — but the API keys and service accounts they created rarely do. Underwriters look for a documented process that identifies credentials tied to departed personnel and rotates or revokes them within a defined window, typically 30 days.

No wildcard permissions in production. A service account or agent identity with blanket administrative scope is, from an underwriter's perspective, the same risk regardless of how unlikely it is to be misused — the question is what happens if it is. Evidence of active permission right-sizing, not just a policy document describing the goal, is what moves this from a finding to a non-issue.

Framework-by-framework summary

Each row below maps a framework's relevant control to what an assessor or underwriter expects to see for non-human identities specifically. The sections that follow go deeper on each.

Framework	Key control(s)	Core requirement	NHI evidence needed
SOC 2 Type II	CC6.1, CC6.2, CC6.3	Logical access control; registration and deprovisioning; periodic least-privilege review	Access reviews covering service accounts and agent identities on the same cadence as human accounts; automated deprovisioning evidence
NIST SP 800-53 Rev 5	AC-2, IA-9	Account management; service identification and authentication	Documented ownership per account; unique cryptographic identity per machine or service principal, not shared credentials
PCI DSS 4.0.1	7.2.5 / 7.2.5.1, 8.6.1–8.6.3	Periodic review of application/system account privileges; no hardcoded credentials; scheduled rotation	Review records for service account permissions; secrets-scanning results; rotation logs with timestamps
ISO/IEC 27001:2022	A.5.17, A.8.24	Secure management of authentication information, including machine secrets; cryptographic protection of stored secrets	Secrets vault deployment evidence; key management policy covering service account and API credentials
EU AI Act	Art. 12, Art. 14, Art. 26	Automatic logging for high-risk AI systems; human oversight; deployer obligations	Agent action logs capturing which identity — agent and originating human — authorized each action; oversight checkpoints on high-impact actions
DORA	Art. 8, Art. 9(4)(c)/(d), Art. 28	ICT asset inventory; least-privilege access and strong authentication; third-party ICT provider register	AI agents and MCP/tool providers included in ICT asset inventory and third-party register; per-agent credentials, not shared

SOC 2 Type II — CC6.1, CC6.2, CC6.3

CC6.1 requires logical access to information assets to be restricted to authorized entities — a category that explicitly includes service accounts and agentic identities, not just human users. CC6.2 covers what happens before and after that access exists: registration and authorization prior to issuing credentials, and timely removal when access is no longer needed. CC6.3 is the ongoing check — periodic review of access rights and roles against the principle of least privilege.

For non-human identities, the practical translation is that every service account and agent identity needs the same lifecycle treatment as a human account: provisioned with a documented justification, reviewed on a recurring cadence (commonly every six months), and deprovisioned promptly when the workload, application, or agent that used it is retired.

What the assessor wants to see

Access review records that explicitly include non-human identities — not a review scoped only to human user accounts with service accounts carved out as "out of scope." Automated evidence linking account creation, modification, and termination to a specific change record, with the identity of who authorized it.

The most common gap here is the "ghost account": an identity that was disabled in the IdP when an employee left, but remains active in a downstream system the IdP doesn't reach — a database, an internal admin panel, or a tool that was never wired into the offboarding workflow.

NIST SP 800-53 Rev 5 — AC-2 and IA-9

AC-2 (Account Management) requires documented ownership, authorization, and lifecycle tracking for every system account — this applies broadly and includes service accounts. IA-9 (Service Identification and Authentication) is the more specific fit for machine identities: it's the control added to address identification and authentication for non-human, service-level principals, as distinct from IA-2's focus on organizational (human) users.

The distinction matters in practice. An assessment that maps NHI governance only to IA-2 is mapping to a control about people. The evidence an assessor wants for IA-9 is about machines: does each agent or service have its own cryptographic identity, or are multiple workloads sharing one API key under a generic label like svc-prod?

What the assessor wants to see

A one-to-one mapping between service/agent identities and the credentials they use — no shared secrets covering multiple workloads. For AC-2, a record showing who approved each account's creation and what business justification was documented at the time.

PCI DSS 4.0.1 — Requirements 7.2.5/7.2.5.1 and 8.6.1–8.6.3

If your cardholder data environment includes any application or system accounts — and almost every CDE does — PCI DSS 4.0.1 has requirements written specifically for them. Requirement 7.2.5 and 7.2.5.1 mandate periodic review of application and system account privileges, on a frequency the organization defines and documents based on risk. Requirement 8.6.1 covers accounts capable of interactive login, requiring unique identification for accountability. Requirement 8.6.2 prohibits hardcoding passwords or passphrases for application and system accounts into scripts, configuration files, or source code. Requirement 8.6.3 requires a defined rotation schedule for those credentials, based on risk assessment.

What the assessor wants to see

A documented review frequency for service account privileges, with records showing reviews actually happened on that schedule. Secrets-scanning results across the codebase and configuration repositories showing no hardcoded credentials — not a policy stating they shouldn't be hardcoded, but evidence that they aren't. Rotation logs with timestamps that match the documented schedule.

ISO/IEC 27001:2022 — A.5.17 and A.8.24

A.5.17 (Authentication Information) governs the secure allocation and management of authentication information — and applies to machine secrets with the same rigor as human passwords. Service account credentials, API keys, and OAuth tokens fall squarely under this control: hardcoded API keys in a repository, or a service account password that hasn't changed since the system was first deployed, are A.5.17 failures. A.8.24 (Use of Cryptography) governs how those secrets are protected once stored — key generation, storage, distribution, rotation, and the cryptographic methods used to encrypt credentials at rest. The two controls work together: A.5.17 sets the policy for managing the secret, A.8.24 sets the technical requirements for protecting it.

What the assessor wants to see

Secrets managed through a dedicated vault rather than environment variables, configuration files, or chat messages — with a documented key management policy covering generation, storage, rotation, and access control for the keys protecting those secrets.

EU AI Act — Articles 12, 14, and 26

Scope: these obligations apply to AI systems classified as "high-risk" under the Act's Annex III, or that fall under its broader transparency requirements for certain AI systems. Whether an agentic system with delegated authority over a process like hiring, credit, or critical infrastructure falls into that classification depends on its specific use case. The major high-risk obligations become applicable from August 2, 2026.

Article 12 (Record-Keeping) requires high-risk AI systems to technically support automatic recording of events over the system's lifetime, sufficient to trace the system's operation back to specific actions — including, per the Act's own framing, who verified a given result. For an agentic system, that means a log of what the agent did, what triggered it, and the identity context behind the action.

Article 14 (Human Oversight) requires that high-risk systems be designed so a human can effectively oversee and intervene — calibrated to the system's level of autonomy and the risk of the action, not a single generic "approve" button that exists regardless of what's being approved. Article 26 sets obligations for deployers: using the system according to its instructions, monitoring its operation, and acting on indications that it presents a risk.

What this connects to

Articles 12 and 14 are where AI Act compliance and identity architecture meet directly. The dual-context token lineage described in the agentic identity controls guide — every privileged action logged against both the agent's identity and the originating human's identity — is exactly the evidence Article 12 asks for. The step-up authorization pattern in that same guide's ASI09 section is what Article 14's "effective oversight" looks like for high-impact actions, as opposed to oversight that exists on paper but routes every action through the same rubber-stamp approval.

DORA — Articles 8, 9, and 28

Scope: DORA applies to EU financial entities — banks, insurers, investment firms, and similar regulated entities — and to the ICT third-party providers that support them. It has been applicable since January 17, 2025. If your organization isn't a financial entity and doesn't sell into one, this section likely doesn't apply.

Article 8 requires financial entities to identify, classify, and maintain an inventory of information assets and ICT assets — a category that includes the credentials, certificates, and identities those assets depend on. Article 9 sets out the technical and procedural protections for those assets: Article 9(4)(c) requires policies that limit logical access to what's needed for legitimate, approved functions — least privilege, as a regulatory obligation rather than a best practice. Article 9(4)(d) requires strong authentication mechanisms and protection of cryptographic keys, based on the entity's data classification and risk assessment.

Article 28 requires financial entities to maintain a register of information on contractual arrangements with ICT third-party providers, particularly those supporting critical or important functions. For an organization deploying AI agents that connect to external MCP servers or third-party AI tool platforms, those providers may need to appear in this register — the agentic supply chain becomes part of the ICT third-party risk perimeter DORA was written to cover.

What the assessor wants to see

AI agents and the service accounts or certificates they use listed in the ICT asset inventory under Article 8, with assigned ownership. Access policies for those agents documented against the least-privilege standard in Article 9(4)(c), with strong authentication — not shared static credentials — satisfying 9(4)(d). Where agents connect to external MCP or AI tool providers supporting a critical or important function, those providers reflected in the Article 28 register alongside other ICT third parties.

Where this breaks

The "ghost account" — disabled in the IdP, still active downstream

An employee is offboarded and their identity provider account is disabled the same day. But a service account or API key they personally created — in a legacy admin panel, a production database, or a tool that was never integrated with the IdP — remains active for months. This is the single most common SOC 2 CC6.2 and PCI 8.6.1 finding, and it's almost always a discovery problem rather than a policy problem: the credential wasn't in the inventory in the first place.

A spreadsheet presented as a "continuous" inventory

A manually maintained spreadsheet, even one that's accurate and recently updated, doesn't satisfy "continuous" or "automated" inventory requirements — under cyber insurance underwriting, DORA Article 8, or NIST AC-2. The gap isn't accuracy at a point in time; it's that nothing keeps the spreadsheet current as new accounts are created between updates.

Shared service tokens with no per-identity accountability

Multiple workloads or agents authenticating with the same API key or service account credential means no individual identity can be tied to a specific action — failing NIST IA-9's intent, PCI 8.6.1's unique-ID requirement, and DORA 9(4)(d)'s strong-authentication standard simultaneously. This is also the most common reason an organization can't produce the dual-context logs Article 12 of the EU AI Act asks for: if five agents share one identity, the log can show what happened, but not which agent did it.

Hardcoded credentials surviving in old commits

Removing a hardcoded API key from the current version of a file doesn't remove it from version history. PCI 8.6.2 and ISO A.5.17 evidence gathered via secrets-scanning needs to cover repository history, not just the current branch — and any credential found in history should be treated as compromised and rotated, not just removed going forward.

Agent logs that record output but not authorization context

A log showing what an AI agent produced — the email it sent, the record it updated — without showing which identity (agent and human) authorized the action and under what permission scope, satisfies a basic activity log but not EU AI Act Article 12's record-keeping intent or a SOC 2 access-control review. The fix is architectural, not logging configuration: if the dual-context token lineage isn't enforced at the point of action, there's no authorization context to log.

MCP and AI tool providers missing from the third-party register

Organizations in scope for DORA often have a mature third-party risk process for traditional vendors — cloud providers, payment processors — but treat an MCP server or AI tool platform an agent connects to as an internal configuration detail rather than a third-party ICT provider. If that provider supports a critical or important function, Article 28 applies to it regardless of how it was procured.

This guide covers what assessors and underwriters look for. The agentic identity controls guide covers the architecture — JIT-scoped tokens, dual-context lineage, and mTLS node verification — that produces the evidence described here. The compliance landscape page covers why this shift is happening now, and the vendor index covers which platforms support continuous inventory, automated access reviews, and the credential lifecycle controls this guide maps to.