Who should be accountable when automated provisioning creates unauthorised access?

Accountability should sit with the identity owner who approved the workflow design, the application owner who accepted the entitlement model, and the control owner who monitors revocation. Automation does not remove responsibility. It makes weak accountability more visible because errors scale faster.

Why This Matters for Security Teams

Unauthorised access created by automation is rarely a single broken control. It is usually a governance failure that spans design, approval, and revocation. The core issue is that workflows can grant privileges faster than people can review them, especially where service accounts, API keys, or delegated agents are involved. NHI Management Group research shows that 97% of NHIs carry excessive privileges, which makes over-provisioning a predictable outcome when entitlement boundaries are vague. See the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 for the underlying risk patterns.

Security teams often assume the automation platform owns the outcome, but accountability still follows the humans who designed the approval path and the control owners who allowed the entitlement to persist. That matters because automated provisioning can scale a single mistake into hundreds of unintended grants before any review cycle catches it. In practice, many security teams encounter the incident only after an access review, rather than through intentional entitlement testing.

How It Works in Practice

Accountability should be mapped to the point where the access decision was introduced, not only where it was executed. If a provisioning workflow creates an entitlement that should not exist, the identity owner is responsible for the workflow design, the application owner is responsible for the entitlement model, and the control owner is responsible for detecting and revoking the bad grant. That is consistent with current guidance from NHI governance and with the control intent behind NHI Lifecycle Management Guide.

Practitioners usually need three layers of evidence:

• Who approved the provisioning logic and its trigger conditions.
• Which application roles, scopes, or API permissions were exposed by default.
• Which monitoring, revocation, and recertification controls were supposed to catch drift.

In mature environments, the workflow itself becomes auditable control evidence. That means tying ticketing, IaC, IAM policy, and access logs to a named owner and a change record. For autonomous or agentic systems, the same principle applies but the runtime context matters more: the policy decision should be evaluated at request time, not only at deployment time. Frameworks such as the OWASP guidance above and OWASP Agentic AI Top 10 reinforce that dynamic systems need continuous control validation, not static approval alone.

This guidance tends to break down in federated environments where multiple teams can alter provisioning rules without a single authoritative control owner because revocation responsibility becomes ambiguous.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster automation against clearer ownership. The hard cases are usually not simple role assignments, but delegated administration, cross-tenant provisioning, and event-driven systems that issue access based on external signals.

There is no universal standard for this yet, but current guidance suggests treating the following as escalation points:

• Self-service provisioning that bypasses application owner review.
• JIT or ephemeral access that is granted correctly but never revoked.
• Agent-driven workflows that can chain tools and expand access beyond the original request.
• Third-party integrations that inherit scopes the business never explicitly approved.

In those cases, accountability should still be anchored to the control design and the entitlement model, even if the triggering action came from automation. Where agentic systems are involved, the better question is not only who pressed approve, but who accepted a runtime policy model that could not distinguish intended from unintended access. That is why control owners should document revocation thresholds, exception handling, and owner-of-record assignments before the workflow goes live. For broader governance context, the Top 10 NHI Issues and the 52 NHI Breaches Analysis show how quickly weak ownership turns into repeatable exposure.

Related resources from NHI Mgmt Group

• Who is accountable when automated deprovisioning does not happen after access review?
• Who is accountable if an MSP onboarding workflow creates excessive access?
• Who is accountable when offboarding leaves access behind?
• Who is accountable when access workflows sit in ITSM but enforcement sits elsewhere?