Authorization, not authentication, is now the access control layer

At a glance

What this is: This is an access-management analysis arguing that authorization has become the decisive control layer for modern environments, not connectivity or authentication.

Why it matters: It matters because IAM, PAM, NHI, and agent governance all fail when privilege is still granted and revoked as a manual exception instead of a governed runtime process.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read P0 Security's analysis of runtime authorization and zero standing privilege

Context

Access management is no longer just about getting to a system and proving who you are. In modern cloud and hybrid environments, the harder problem is authorizing what an identity can do after it is already connected and authenticated, especially when the identity may be a human, workload, or AI agent.

That shift matters because many programmes still anchor control design in network boundaries, SSO, MFA, vaults, and gateways. Those controls remain necessary, but they do not answer the runtime question auditors now ask most often: who had privilege, for what purpose, for how long, and with what evidence?

Key questions

Q: How should security teams govern privileged access after authentication?

A: Security teams should treat authorization as the real control layer and scope privilege at the moment it is needed. That means moving away from persistent admin rights, requiring task-specific approvals, and ensuring every elevation is tied to a target system, a reason, and an audit trail that survives incident review.

Q: Why do static credentials and standing access create more risk in cloud environments?

A: Static credentials and standing access expand the time window in which privilege can be misused, copied, or forgotten. In cloud and hybrid systems, that creates over-privilege, weak accountability, and difficult forensic reconstruction because the original reason for access is no longer visible when the action is taken.

Q: What breaks when access management stops at SSO and MFA?

A: What breaks is the ability to govern what identities can do inside the environment. SSO and MFA answer entry and identity proofing, but they do not control action scope, privilege duration, or revocation timing. That leaves authorization drift to accumulate across human, workload, and agent identities.

Q: How do teams know if runtime authorization is actually working?

A: A working runtime authorization model can answer, quickly and consistently, who did what, where, why, for how long, and under which approval. If that answer requires manual reconstruction from tickets, chat threads, and screenshots, then privilege governance is still operating as a reactive exception process.

Technical breakdown

Why authorization is the runtime control layer

Authorization is the decision layer that determines what an identity can do once it has entered the environment. In older architectures, network reachability and authentication were treated as the primary gatekeepers because the environment itself was comparatively static. In cloud, multi-cloud, and AI-native systems, that assumption breaks down. A user, workload, or agent can be authenticated and still be dangerously over-privileged. The practical challenge is no longer access to the perimeter, but the scope, duration, and auditability of actions taken inside the perimeter.

Practical implication: Treat authorization as a first-class control plane and measure whether privilege can be scoped, time-bound, and reconstructed after the fact.

Why static credentials and standing access create operational drift

Static credentials and standing access are convenient because they collapse repeated authorization decisions into a persistent entitlement. That convenience becomes risk when identities span human users, workloads, and AI agents, each of which may need different privilege windows and different evidence trails. Standing access also makes incident reconstruction harder because the record of why access existed is often separated from the moment it was used. In practice, the more static the privilege model, the more likely teams are to carry invisible overreach into production systems.

Practical implication: Replace persistent privilege with task-scoped access and require revocation to be tied to work completion, not calendar time.

What zero standing privilege changes for multi-cloud and agent access

Zero standing privilege shifts privilege from a durable property of the account to a temporary outcome of an authorization process. That matters in environments where access must span databases, clusters, consoles, and cloud control planes without creating shared accounts or proxy-based exceptions. For AI agents and workloads, this also means authorization must be attached to the activity itself, not just the identity record. The control objective is not simply to deny access by default, but to ensure every elevated action is both narrowly granted and fully attributable.

Practical implication: Design runtime elevation so each privileged action is granted just in time, limited to the target system, and logged with enough context for audit and incident review.

NHI Mgmt Group analysis

Authorization has become the control plane that matters most because connectivity and authentication are now commoditised. Security teams have spent years hardening tunnels, SSO, MFA, and vaults, but those layers no longer contain the highest-risk decisions. The decisive question is what an identity can do after it arrives, and that is an IAM and PAM governance problem before it is a network problem. Practitioners should stop treating privilege as an exception path and start treating it as the core access lifecycle.

Standing privilege is now an identity governance debt, not an access convenience. Once privilege persists beyond the task that required it, auditability degrades and blast radius expands across cloud, SaaS, and infrastructure systems. This is especially visible when the same governance model is applied to employees, contractors, workloads, and agents without distinguishing runtime context. The practical conclusion is that persistent privilege should be the thing programmes are trying to eliminate, not the thing they quietly tolerate.

Zero standing privilege is the natural end state for runtime access governance across human, workload, and agent identities. The article’s core point is not that authentication is obsolete, but that authentication alone cannot answer who can do what, where, for how long, and under what conditions. That makes lifecycle governance the real discipline: provision narrowly, elevate only when needed, and revoke as soon as the task ends. Practitioners should re-centre PAM and NHI governance on privilege lifecycle rather than identity entry.

Runtime authorization is the named gap this article exposes. The industry has made progress on access entry, but still struggles to govern what happens after entry in a way that is continuous, evidence-backed, and identity-type aware. That gap becomes sharper as AI agents and workloads join human administrators in sensitive workflows. The implication is that future access programmes will be judged less by login success and more by how precisely they control post-authentication action.

Access review processes remain too slow and too retrospective for modern privilege patterns. By the time a manual review catches standing access, the operational window that created the risk has often already passed. This is why governance has to move closer to runtime and tie approval, scope, and revocation to actual execution. For practitioners, the message is to redesign access governance around live privilege state rather than periodic certification alone.

From our research:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which shows how quickly privilege assumptions weaken when identity becomes non-human.
• As a next step, compare this access pattern with the NHI Lifecycle Management Guide to see where provisioning, rotation, and offboarding need to be tied back to runtime authorization.

What this signals

Runtime authorization is becoming the differentiator between mature and immature identity programmes. Teams that can still reconstruct privilege decisions after the fact are better positioned to govern hybrid estates, while those that depend on static access and manual exceptions will keep absorbing avoidable risk. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per the 2026 Infrastructure Identity Survey, the pressure to redesign access governance is no longer theoretical.

Zero standing privilege is the concept that will increasingly separate policy from practice. It is not enough to say access should be least-privileged if the environment still leaves durable rights in place between reviews. Practitioners should expect more scrutiny of how elevation is triggered, how it is revoked, and whether the evidence trail can survive an audit without manual stitching.

Identity programmes should prepare for a broader convergence between IAM, PAM, NHI governance, and AI agent oversight. The same authorization mechanics that govern a contractor or service account will increasingly be applied to software-driven actors, which means lifecycle controls, approvals, and evidence handling need one coherent model rather than separate exceptions.

For practitioners

• Map privilege after authentication Inventory every place where access is granted after login, including cloud consoles, databases, clusters, and internal admin tools. Document who can elevate, what conditions trigger elevation, and which evidence is attached to the decision.
• Eliminate standing privilege where work is episodic Convert persistent admin access into just-in-time elevation for on-call, break-glass, and sensitive operational workflows. Tie deprovisioning to task completion so access does not outlive the work that required it.
• Separate entry controls from authorization controls Keep SSO, MFA, and network segmentation as entry gates, but do not treat them as substitutes for runtime authorization. Make privilege scope, duration, and approval state explicit in the policy layer.
• Build audit trails around who did what and why Ensure logs can reconstruct the approval, duration, and target system for each elevated action. If incident response or audit teams still need to piece together screenshots and tickets, the authorization model is not mature enough.

Key takeaways

• Connectivity and authentication are necessary, but they no longer define the hardest access problem.
• Persistent privilege and static credentials create the governance drift that modern audits and incident reviews expose.
• Teams should shift to runtime authorization, just-in-time elevation, and auditable revocation across human, workload, and agent identities.

Key terms

• Runtime Authorization: Runtime authorization is the decision process that determines what an identity may do after it has already authenticated and connected. It matters because modern environments need to scope actions, duration, and approvals in real time, not rely on a one-time login event.
• Zero Standing Privilege: Zero standing privilege means identities do not keep permanent elevated access. Privileges are issued only when needed, limited to the task, and removed when the task is complete. In practice, it reduces blast radius and makes audit evidence more defensible across human, workload, and agent access.
• Standing Access: Standing access is persistent permission that remains available beyond the moment it was required. It is operationally convenient but governance-heavy because it increases over-privilege, weakens accountability, and leaves security teams with less precise evidence when incidents or audits demand reconstruction.
• Just-in-Time Privilege: Just-in-time privilege is temporary access granted for a specific purpose and revoked after use. It is an effective control when paired with clear approval context, target-system scoping, and reliable logging, because the privilege window is short and easier to govern than permanent rights.

What's in the full article

P0 Security's full article covers the operational detail this post intentionally leaves for the source:

• How the platform decouples authorization from network and authentication layers in mixed environments
• Practical workflow detail for just-in-time privilege across human users, workloads, and AI agents
• How audit evidence is captured for who did what, when, why, and under which approvals
• Why the approach removes shared accounts and standing access in day-to-day operations

👉 P0 Security's full post covers the access workflow, audit reconstruction, and deprovisioning detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.