Who is accountable when access is decided in real time across multiple identity types?

Why This Matters for Security Teams

Real-time authorization across humans, service accounts, workloads, and AI agents changes the accountability model from a static access review to a live control decision. The organisation still owns the policy, but the evidence now has to show that the policy was applied at the moment of access, with the right identity type and context. That is where many teams lose control, especially when secrets are scattered and identities are poorly inventoried.

NHI Mgmt Group research shows how widespread that exposure already is: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. That makes accountability more than a governance question. It becomes a proof problem, where the defender must demonstrate that the policy engine, token issuer, and resource gate all agreed on the same decision.

Practitioners also have to account for the fact that identity risk is no longer confined to one class of actor. The OWASP Non-Human Identity Top 10 frames this as a control failure across lifecycle, privilege, and secret handling, not just a logging issue. In practice, many security teams discover the accountability gap only after a token has already been reused or a policy decision cannot be reconstructed.

How It Works in Practice

Accountability in a real-time, multi-identity environment depends on separating three things: who defines the policy, who enforces it, and who can prove the decision was valid at the time of access. The policy owner is usually security or platform governance. The enforcer may be a gateway, service mesh, API layer, or authorization service. The proof must include the request context, the resolved identity type, the decision outcome, and the policy version in force.

For workloads and agents, static role assignment is usually too coarse. Current guidance suggests using runtime authorization with short-lived credentials, workload identity, and policy-as-code. That means the system issues a narrowly scoped token for the task, validates it against a live policy decision, and revokes or expires it immediately after use. This aligns with the operational direction in the Ultimate Guide to NHIs — Key Challenges and Risks, where visibility and rotation are treated as core controls rather than hygiene tasks.

• Define one policy authority for each decision domain, then version and sign the policy.
• Use workload identity and cryptographic proof, not just shared secrets, to identify the requester.
• Evaluate access inline with context such as task, resource sensitivity, time, location, and originating service.
• Log the policy version, input attributes, decision outcome, and token TTL for auditability.
• Revoke credentials automatically when the task completes or the context changes materially.

NIST’s Zero Trust guidance supports this model because trust is evaluated continuously rather than granted once at the perimeter. The NIST SP 800-207 Zero Trust Architecture is the clearest baseline for proving that access was authorized at request time. These controls tend to break down when legacy applications cannot pass identity context end to end, because the decision engine cannot reliably bind the policy to the actual requester.

Common Variations and Edge Cases

Tighter real-time control often increases operational overhead, requiring organisations to balance stronger proof of authorization against latency, integration cost, and developer friction. There is no universal standard for this yet when multiple identity types must be judged in the same transaction, especially across hybrid estates and multi-tenant platforms.

One common edge case is delegation. A human may trigger an agent, which then calls a service account, which then accesses a downstream API. In that chain, the organisation accountable for the policy still needs a clear delegation record showing where authority was transferred and where it stopped. Another edge case is emergency access, where JIT elevation may be acceptable but should remain time-bound and fully attributed.

For agentic systems, the governance bar is higher because the actor can change tools and targets mid-task. That is why NIST AI Risk Management Framework and the CSA MAESTRO guidance both push toward explicit accountability, runtime controls, and traceable decisions. Best practice is evolving, but the practical rule is stable: if the organisation cannot reconstruct the live policy decision and the identity chain, it cannot claim full control. In mixed legacy and cloud environments, that breakdown usually appears first in API gateways that do not preserve request context across hops.

Related resources from NHI Mgmt Group

• Who is accountable when DNS weaknesses disrupt access to identity services?
• Who is accountable when identity proofing and access provisioning fail together?
• Who is accountable when access review and lifecycle ownership are split across teams?
• When do NHI access reviews create more value than a one-time cleanup?