TL;DR: PlainID says enterprise authentication solved the “who are you?” problem, but runtime access remained hard to control across siloed technologies as human and non-human identities multiplied. The governance challenge is no longer entry alone, but what each identity can do once inside.
At a glance
What this is: This is a company overview arguing that modern access control must shift from login decisions to runtime authorization over what identities can do, see, and expose.
Why it matters: IAM and NHI teams need to treat authorization as a live governance plane, because identity volume and application sprawl make static access assumptions too weak for real-time control.
👉 Read PlainID's overview of runtime authorization for mixed identity environments
Context
PlainID frames the problem as a gap between authentication and authorization. Enterprises solved the question of who a user is, but not the question of what that identity can do after access is granted.
The article positions runtime authorization as a response to identity sprawl across applications, customers, partners, employees, and non-human identities. That makes the subject relevant to IAM, IGA, and NHI governance because the control point moves from login to action-level permissioning.
Key questions
Q: How should security teams implement runtime authorization in identity security programmes?
A: Security teams should move the final allow-or-deny decision out of application code and into a dedicated policy layer that evaluates identity, resource, action, and context at request time. That keeps authorization consistent across services, makes policy change auditable, and prevents each team from inventing its own access logic.
Q: Why does authentication alone fail to control access in modern applications?
A: Authentication proves an identity, but it does not govern the actions that identity can take once inside the application. In modern estates, risk emerges from runtime behaviour, data exposure, and cross-system privilege paths. That is why access control must include decision-time authorisation rather than stopping at sign-in assurance.
Q: What are the signs that application authorization is becoming unmanageable?
A: Common warning signs include growing numbers of roles, permissions, and environment specific exceptions, plus repeated if/then/else logic scattered through code. Another signal is when every access change becomes slow to write, test, and deploy. At that point, the organisation is carrying security logic in too many places, which makes consistency and governance difficult to sustain.
Q: What is the difference between authentication and runtime authorisation for data access?
A: Authentication confirms who or what received access. Runtime authorisation decides what that identity can do after the session starts, including whether it can reach a schema, modify a table, or invoke a destructive action under current conditions.
Technical breakdown
Why authentication is not enough for runtime access
Authentication answers identity proof, but it does not control in-session decisions about actions, data exposure, or workflow boundaries. In modern application stacks, those decisions must be evaluated at runtime because entitlements vary by tenant, role, relationship, asset sensitivity, and context. That is especially true when the same platform serves customers, partners, employees, and service identities. Once those actors are inside, the security problem becomes authorisation drift, not just entry control. Runtime authorisation inserts policy at the decision point so the application can allow or deny specific actions based on current conditions, not just a prior login event.
Practical implication: separate login assurance from action authorisation, and review where runtime policy enforcement is missing inside applications.
What centralized authorization management changes
Centralized authorization management is a control architecture that makes access policy consistent across multiple applications and technology stacks. Instead of hardcoding permissions into each system, the policy decision is externalized so different apps can query the same authorisation logic. That matters when organisations need to govern many identities and business lines without duplicating rules everywhere. The technical value is less about convenience than consistency: one policy model can reduce contradictory entitlements, hidden privilege paths, and app-by-app exceptions. For NHI governance, it also gives teams a place to express non-human access boundaries without relying on each workload owner to implement them differently.
Practical implication: centralize policy decisions where multiple applications currently implement their own access logic.
Why AI-era identity sprawl increases authorization risk
AI-era identity growth changes the access problem because the number of actors and decision paths expands faster than manual governance can track. Human users, service accounts, partners, customers, and automated systems all generate distinct access needs, but the same legacy permissions model often tries to govern them uniformly. That creates oversharing, stale exceptions, and invisible runtime exposure. When identities are dynamic and cross-system, the security issue is not merely credential issuance. It is whether policy can keep pace with what those identities can do at the moment of use, including data exposure and downstream system actions.
Practical implication: map runtime permissions by identity type and application context rather than assuming one entitlement model fits all.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime authorization is the real control plane when authentication no longer differentiates risk. The article reflects a mature identity problem: access is granted too early in the stack to be the only meaningful control. Once human and non-human identities enter the application, the more important question is what they can do, not simply whether they arrived with valid credentials. Practitioners should treat authorization as an always-on governance layer, not an application afterthought.
Centralization matters because authorization sprawl produces policy inconsistency faster than most teams notice. When each application implements its own permission rules, exceptions accumulate and cross-system governance weakens. That creates a hidden control gap in hybrid estates where customers, partners, staff, and machines share application surfaces. The practical consequence is that access review alone cannot compensate for fragmented decision logic.
Identity sprawl in the AI era turns runtime decisions into a scale problem, not just a design problem. The article’s core signal is that enterprises are now managing more identity types, more interactions, and more exposure points at the same time. That makes runtime policy enforcement a structural requirement for IAM and NHI governance. The implication is that identity programmes must evaluate decision latency, policy consistency, and entitlement visibility together.
Authorization policy must become identity-type aware if enterprises want coherent governance across humans and NHIs. Human roles, partner access, customer sessions, and service identities do not carry the same risk model, yet many enterprises still govern them with shared assumptions. A runtime authorisation layer can express those differences without fragmenting control ownership. Practitioners should use this shift to redesign how action-level permissions are modeled across the estate.
The named concept here is runtime authorization drift: the widening gap between who is authenticated and what the organisation can still govern at the moment of action. In mixed identity environments, that drift becomes more dangerous than login failure because policy inconsistency survives successful authentication. The implication is that teams should measure and reduce drift as a first-class governance problem.
What this signals
Runtime authorization now sits at the centre of identity governance when multiple identity types share the same application surface. Static role design cannot keep pace with customer, partner, staff, and machine access patterns if policy remains embedded in each app. Teams should expect policy centralisation to matter more as the number of identities and decision paths grows.
Identity programmes need to measure policy drift, not just access volume. When authorization rules are duplicated across systems, the real control failure is inconsistency at decision time. That is where NHI, human IAM, and application governance converge: the estate is only as governable as its least consistent permission path.
For practitioners
- Define runtime decision points Identify where applications currently make allow or deny decisions locally and mark those paths for external policy enforcement.
- Separate authentication from authorization Review application designs so proof of identity and permission to act are controlled by different mechanisms and ownership models.
- Classify access by identity type Map human users, partners, customers, service accounts, and automated identities to distinct authorization rules instead of a shared entitlement pattern.
- Standardize policy across application stacks Consolidate duplicated permission logic so one authorization model governs multiple technologies, reducing exception drift and hidden privilege paths.
Key takeaways
- Authentication and authorization are no longer separable operational concerns in large estates, because runtime decisions define the real exposure surface.
- Siloed application permission logic creates hidden governance drift that access reviews alone will not uncover.
- Practitioners should move toward centralized, identity-type-aware policy enforcement for humans, partners, customers, and non-human identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on controlling what identities can do after entry, which maps to overbroad access scope. |
| NHI-08 — Environment Isolation | The article describes mixed identities across siloed stacks, where isolation boundaries affect access governance. | |
| Recommendation — Review runtime permissions and reduce overprivileged access paths for non-human identities. Separate authorization boundaries by application context and identity type to limit cross-environment exposure. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Runtime authorization is an implementation of least privilege at the point of action. |
| Recommendation — Apply least privilege at decision time, not only at provisioning time. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The topic is directly about how permissions and authorizations are governed across identities. |
| Recommendation — Centralize entitlement governance so applications enforce consistent permissions and authorizations. | ||
Key terms
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Authority Drift: Authority drift occurs when different systems hold conflicting versions of identity data and no clear owner resolves the mismatch. It is a governance failure that leads to duplicate work, stale entitlements, and access decisions based on partial or inconsistent records.
- Identity Type Awareness: The practice of distinguishing human users, non-human identities, and AI agents before applying governance controls. It is essential because each actor type changes on a different lifecycle cadence, so one review model cannot reliably govern all three without losing risk context.
- Decision-Time Enforcement: A control pattern where authorisation is checked at the moment an actor tries to perform an action, not only when access is granted. For agentic systems, this is the difference between observing behaviour and actually constraining it before impact.
What's in the full article
PlainID's full overview covers the operational detail this post intentionally leaves for the source:
- The company story behind the runtime authorization platform and why its founders say existing access models fell short
- Enterprise use cases for controlling what identities can access, do, and expose across mixed application stacks
- Details on the scale claim around securing over 35 million identities and processing billions of authorization decisions daily
- Leadership and funding background that explains how the vendor positions its enterprise transition
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org