Who should own access risk when humans, machines, and AI agents all use the same workflows?

Ownership should sit with the programme that governs identity and access, not with each application team in isolation. Human IAM, IGA, PAM, and NHI governance need shared accountability because access risk now spans the full operating model. Separate ownership creates blind spots, especially where machine access is embedded in business process automation.

Why This Matters for Security Teams

When humans, machines, and AI agents share the same workflow, access risk stops being an application-level issue and becomes an operating model issue. The usual split between IAM, PAM, IGA, and platform teams leaves no single owner for the full path of entitlement, credential use, privilege escalation, and audit evidence. That is where gaps appear: a human approval may exist, but a machine token or agent action can still bypass the intended control plane.

NHIMG’s research on The State of Secrets in AppSec shows how fragmented secrets practices persist even when confidence is high, which is exactly the kind of split accountability that weakens shared workflows. The broader pattern is also visible in the Ultimate Guide to NHIs, where identity risk follows the workload, not the team boundary. Current guidance from NIST Cybersecurity Framework 2.0 supports ownership clarity, but it does not eliminate the need to define who governs cross-domain access decisions.

In practice, many security teams encounter privilege drift only after a machine credential, service account, or agent action has already been reused outside the original business process.

How It Works in Practice

The practical model is shared accountability with a single governance owner. That owner is usually the identity and access programme, but it should coordinate policy across human IAM, IGA, PAM, secrets management, and NHI governance rather than handing each workflow to the nearest application team. The point is not centralisation for its own sake. The point is to make sure one control plane can answer who requested access, what kind of identity acted, what was approved, and whether the access was still valid at the moment of use.

For machine and agent access, that means moving away from static grants and toward runtime decisions. The best practice is evolving toward context-aware authorisation, short-lived credentials, and workload identity as the primary trust anchor. Standards and guidance such as the NIST AI Risk Management Framework, OWASP Agentic Applications Top 10, and CSA MAESTRO agentic AI threat modeling framework all point in the same direction: access decisions must reflect the current workload, not just a preassigned role.

• Use one policy owner to define access standards across humans, services, and agents.
• Issue short-lived secrets or tokens per task, not long-lived standing access.
• Require workload identity evidence for machines and AI agents before privilege is granted.
• Evaluate policy at request time so approvals can reflect context, risk, and business purpose.

NHIMG’s 52 NHI Breaches Analysis is useful here because it shows that non-human compromise rarely stays isolated to one system once credentials and workflows are intertwined. These controls tend to break down when legacy applications force shared service accounts because the system cannot distinguish which actor actually performed the action.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance governance consistency against delivery speed. That tradeoff is real, especially in teams that ship automation quickly or operate mixed estates with legacy service accounts, human approvals, and agentic tooling in one chain.

There is no universal standard for this yet, but current guidance suggests treating the identity and access programme as the policy authority while allowing platform teams to own implementation details. That distinction matters for edge cases such as shared credentials in batch jobs, break-glass access, and AI agents that invoke multiple tools in a single task. In those cases, ownership should include evidence requirements, expiration rules, and revocation responsibility, not just entitlement approval.

The most common failure mode is assuming a human manager can approve access risk for an autonomous workload. A manager can approve business need, but not the runtime behaviour of an agent that chains tools, retries actions, or moves laterally after receiving new context. That is why NHI governance, PAM, and AI governance need a shared escalation path, as described in OWASP NHI Top 10 and the vendor-neutral implementation guidance around OWASP Non-Human Identity Top 10.

When workflows span procurement, finance, operations, and AI automation, ownership should be measured by who can enforce revocation, attestation, and auditability end to end.

Related resources from NHI Mgmt Group

• Should organisations use the same access model for humans and AI agents?
• Who should own governance when humans, services, and AI agents all access the same resources?
• Why do AI agents create new IAM risk in access review workflows?
• Should organisations use the same controls for humans, NHIs, and AI agents?