Who should be accountable when an identity failure affects critical infrastructure or delegated AI access?

Why This Matters for Security Teams

When an identity failure affects critical infrastructure, the issue is rarely just technical. It becomes a governance failure because someone approved the trust relationship, someone allowed the privilege, and someone must answer for the impact. That is especially true when delegated AI access is involved, because autonomous systems can act faster and more broadly than human operators expect. Current guidance suggests accountability should map to decision ownership, not console ownership.

This distinction matters because modern incidents often emerge from standing access, over-broad delegation, or weak approval boundaries rather than a single misconfigured control. NHIMG’s 52 NHI Breaches Analysis shows how quickly identity mistakes become operational outages or security events when non-human trust is left ambiguous. The same pattern appears in agentic deployments where the sponsor, platform team, and business owner each assume someone else is responsible. Industry research from OWASP Non-Human Identity Top 10 reinforces that non-human identity risk is primarily a lifecycle and accountability problem, not just a secrets problem.

In practice, many security teams encounter accountability gaps only after a privileged identity has already been abused or an AI agent has already changed infrastructure without clear approval.

How It Works in Practice

Accountability works best when it is assigned to the owner of the trust decision at the moment access is granted, reviewed, or delegated. For critical infrastructure, that usually means the identity and access management owner, the privileged access owner, or the business approver for the workload. For agentic AI, the accountability model has to go one step further: the sponsoring human, the application owner, and the control owner should each have explicit duties for authorisation, scope, monitoring, and revocation.

Practically, this means documenting who can approve access, who can change policy, and who must investigate misuse. It also means separating operational administration from governance responsibility. A platform team may run the tooling, but the business function that accepted the risk should own the decision record. For autonomous systems, runtime controls matter as much as approvals. Standards and guidance from CISA cyber threat advisories and the Anthropic Project Glasswing research both point to the same operational truth: delegated access must be constrained, observable, and revocable.

• Define a named trust owner for every privileged identity, API token, and AI delegation path.
• Use least privilege and just-in-time access so accountability is tied to a short-lived approval, not a standing grant.
• Log the human approver, policy decision, and effective scope for every delegated AI action.
• Require break-glass and revocation procedures so ownership is actionable during an incident.

NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks emphasizes that unclear ownership is one of the fastest ways non-human access becomes ungovernable. These controls tend to break down when multiple teams share the same AI agent or infrastructure service because approval authority, operational control, and incident responsibility are split across organisations with no single decision record.

Common Variations and Edge Cases

Tighter accountability often increases governance overhead, requiring organisations to balance auditability against deployment speed. That tradeoff is real, especially when critical infrastructure teams need rapid change windows or when AI agents operate across several business units. Best practice is evolving, but current guidance suggests the answer is not to dilute responsibility; it is to make delegation explicit and time-bound.

One common edge case is vendor-managed or shared-service environments. The vendor may operate the platform, but the enterprise still owns the risk acceptance for delegated access into critical systems. Another is multi-agent or multi-step AI workflows, where one agent requests access and another executes changes. In those cases, accountability should follow the approval chain and the final action chain, not just the system that initiated the request. Research on the State of Secrets in AppSec highlights how fragmented control and weak remediation discipline make ownership harder to enforce once credentials are exposed.

There is no universal standard for this yet, but teams should avoid vague terms like “shared responsibility” unless they also define the specific owner for approval, monitoring, revocation, and post-incident review. The more autonomous the access path, the more important it becomes to name one accountable human decision owner and one accountable system owner. That distinction becomes essential when an AI system is making infrastructure changes at machine speed and nobody can reconstruct who authorised the trust boundary after the fact.

Related resources from NHI Mgmt Group

• Who should be accountable for AI identity governance?
• Who is accountable when access decisions are delegated across roles and policies?
• Why is NHI governance critical in the age of AI attacks?
• How should security teams govern API keys used for generative AI access?