IAM and PAM should own the access model because the control problem is privilege, not prompt management. AI teams may operate the workflow, but they do not define entitlement scope, revocation, or offboarding. Governance succeeds when the same lifecycle controls used for humans and NHIs are applied to AI-enabled access paths.
Why This Matters for Security Teams
Claude identity governance is not a prompt engineering problem. It is an access governance problem that determines who can act, what they can reach, and how quickly access is removed when the workflow changes. That is why IAM and PAM own the control plane: they already manage entitlement scope, elevation, approval, and offboarding. AI teams may understand the model behaviour, but they should not be left to define production privilege.
The risk is amplified when AI-enabled workflows touch secrets, APIs, and downstream tools. NHIMG research on the 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect a breach of NHIs, which shows how quickly machine access becomes a real attack surface. The control lesson aligns with NIST Cybersecurity Framework 2.0 and the lifecycle focus in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
In practice, many security teams encounter over-permissioned AI access only after a workflow has already touched production systems or exposed secrets.
How It Works in Practice
The clean operating model is simple: IAM defines the identity and entitlement framework, PAM handles privileged elevation and session control, and AI teams document the workflow requirements that must be translated into policy. That division matters because Claude, like other autonomous assistants, may need to call tools, query data, or trigger actions dynamically. Those permissions should be issued as workload access, not as permanently embedded human-style roles.
For practitioners, the strongest pattern is to map each Claude-enabled task to a bounded permission set, then enforce it at request time. Current guidance suggests combining role-based baselines with context-aware authorisation, just-in-time elevation, and short-lived secrets. That means a Claude workflow should receive only the API scope, token TTL, and approval path required for the current task, then lose access when the task ends. This is consistent with lifecycle governance in the 2024 ESG Report: Managing Non-Human Identities and with control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls.
- Use IAM to define the identity source, trust boundary, and access review owner.
- Use PAM to broker elevation, session approval, and revocation for sensitive actions.
- Use AI teams to specify task intent, tool dependencies, and failure-safe workflow limits.
- Use short-lived credentials and offboarding hooks so access disappears when the workflow is disabled.
This model breaks down when organisations let the AI team own entitlement design directly, because they usually optimise for task success rather than least privilege and revocation discipline.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, requiring organisations to balance velocity against auditability and blast-radius reduction. That tradeoff is real in Claude deployments where teams want fast experimentation but still need production-grade control.
There is no universal standard for this yet, but current guidance suggests treating the ownership question differently by environment. In sandbox or internal prototyping, AI teams may coordinate access requests and test constraints, while IAM still owns the underlying identity policy. In production, especially where Claude can reach customer data, admin consoles, or code execution tools, IAM and PAM should remain accountable for entitlement lifecycle, break-glass handling, and periodic reviews. This is the same reason NHIMG’s Top 10 NHI Issues and Analysis of Claude Code Security both point back to governance, not model output, as the real control boundary.
The edge case to watch is shared ownership without clear decision rights. If AI teams approve what the agent needs, but IAM owns the identity and PAM owns elevation, gaps appear unless there is one accountable policy owner for each privilege path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Ownership and lifecycle control are core NHI governance concerns. |
| OWASP Agentic AI Top 10 | A1 | Agentic workflows need bounded tool access, not prompt-only controls. |
| CSA MAESTRO | GOV-01 | Governance requires clear accountability across agent, platform, and security owners. |
| NIST AI RMF | AI RMF governance addresses accountability for autonomous AI use cases. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management map directly to this ownership question. |
Separate workflow ownership from entitlement ownership and keep IAM as control authority.
Related resources from NHI Mgmt Group
- Why do AI tools create new identity governance risks for IAM teams?
- How should IAM teams respond when identity governance moves toward AI-native automation?
- Who should own AI agent governance when identity and access are shared across teams?
- Who should own governance when AI agents cross identity, access, and application teams?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
