Authorization is the real perimeter for AI, cloud, and IAM

At a glance

What this is: This analysis argues that authorization is the real perimeter because breach impact is driven by what an identity can do after login, not by login alone.

Why it matters: It matters to IAM practitioners because human, NHI, and autonomous access all fail in the same place when authorization is fragmented, over-scoped, and weakly governed.

By the numbers:

• Over 80% of breaches involved valid credentials.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Opal Security's analysis of why authorization is the real perimeter

Context

Authorization is the control that determines what an identity can actually do after authentication succeeds. In modern environments, that decision is spread across application logic, cloud IAM, SaaS admin panels, Terraform, and third-party integrations, which makes the policy surface wider than most programmes can reason about consistently.

The practical identity governance problem is not login assurance but runtime permission control across humans, NHIs, and increasingly autonomous systems. When ownership is fragmented, attackers do not need to bypass every layer, only the one that grants the broadest inherited access.

This is why authorization has become a board-relevant security boundary rather than a back-end implementation detail. Existing IAM and IGA programmes often monitor entitlements, but they still struggle to enforce and explain the effective permissions that emerge once multiple systems, roles, and identities interact.

Key questions

Q: How should security teams reduce breach impact when valid credentials are compromised?

A: They should focus on limiting what a valid session can do after authentication. That means narrow entitlements, short-lived access, strong segmentation, and continuous authorization checks at runtime. The goal is not to eliminate every credential compromise, but to ensure one stolen identity cannot translate into wide lateral movement or data exposure.

Q: Why do over-scoped identities increase breach severity in cloud and SaaS environments?

A: Over-scoped identities turn a single compromise into broad reach because the attacker inherits more permissions than the job requires. In cloud and SaaS environments, that often includes data access, admin functions, and cross-environment traversal. The more persistent the access, the harder it is to contain the incident once the session is active.

Q: What do IAM teams get wrong about authorization governance?

A: They often treat authorization as a review artifact instead of a live security control. That approach misses the difference between assigned access and effective access, especially when policies are spread across multiple platforms. Strong governance requires one view of privilege, observable enforcement, and regular removal of access that no longer matches the task.

Q: Who is accountable when a third-party identity causes data exposure?

A: Accountability sits with the organisation that trusted the identity without sufficient boundaries, not just with the vendor that used it. If a third-party account was over-scoped, persistently trusted, or insufficiently monitored, the governance failure is internal. Frameworks such as NIST CSF and zero trust both expect explicit control over external access.

Technical breakdown

Fragmented authorization across cloud IAM, SaaS, and code

Authorization is often implemented in several places at once: application code, infrastructure-as-code, cloud policies, and SaaS admin settings. Each layer can be correct in isolation and still produce unsafe effective access when combined. That fragmentation makes it hard to answer a basic question: what can this identity actually do right now? Without a shared policy model and runtime evaluation, the environment accumulates hidden privilege paths that are not visible in reviews or configuration audits.

Practical implication: centralise policy reasoning so effective access can be evaluated across systems, not just within them.

Why valid credentials still lead to large breaches

A valid credential does not equal safe access. Once an attacker or abused identity obtains a legitimate session, the decisive factor becomes privilege scope, session duration, and whether controls limit lateral movement. This is why breaches often widen after initial access rather than at the point of entry. The problem is less about authentication failure and more about inherited entitlements that were never designed for the session reality of modern infrastructure.

Practical implication: treat valid-session abuse as a primary threat model, not a secondary detection problem.

Task-specific access and runtime enforcement

Modern authorization needs short-lived, task-specific access with policy evaluation at the point of use. That means decisions should account for identity type, environment, and risk posture rather than relying on static role assignments alone. Runtime enforcement is especially important where non-human identities or third parties can move faster than review cycles. Policy-as-code helps, but it only works when the organization can test, version, and observe authorization decisions continuously.

Practical implication: move critical entitlements toward just-in-time access and observable runtime enforcement.

Threat narrative

Attacker objective: The attacker’s objective is to convert one trusted identity into broad operational reach and extract data or move laterally without triggering strong authorization boundaries.

1. entry: The initial foothold often comes from credential stuffing, phishing, malware theft, or an application flaw that yields a legitimate session rather than a noisy break-in.
2. escalation: The real expansion happens when the compromised identity inherits broad or persistent privileges across cloud data, SaaS, or backend systems.
3. impact: Attackers exfiltrate data, traverse environments, or abuse trusted access paths because authorization boundaries were too loose to contain the session.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization is the real perimeter because breach damage is determined by effective permissions, not successful login. Authentication has improved dramatically, but modern attackers still win by operating inside trusted sessions and inheriting whatever access the environment has already granted. That makes runtime authorization the control plane that actually constrains blast radius. Practitioners should treat effective access as the security boundary that matters.

Fragmented authorization is an identity governance failure, not just an implementation inconvenience. When policy lives in code, cloud consoles, SaaS panels, and platform-specific rules, no single team owns the true access model. The result is inconsistent review, weak explainability, and privilege paths that persist outside the view of governance. Practitioners should recognise that fragmented policy reasoning is a control gap, not a documentation problem.

Third-party and non-human identities expose the same authorization weakness at higher speed and scale. The M&S case in the article shows how a legitimate external identity can still be over-scoped and persistently trusted. That is the same failure pattern seen across NHIs, where access outlives the task and broad privilege becomes the default. Practitioners should apply the same authorization discipline across vendors, workloads, and service identities.

Short-lived, task-specific access is becoming the only defensible authorization model in complex environments. Static role design cannot keep pace with cloud sprawl, SaaS delegation, and machine-to-machine access patterns. Policy needs to be evaluated at use time, not assumed safe because it was approved at provisioning time. Practitioners should rebuild authorization around session scope, context, and observability.

Identity blast radius is the right named concept for this problem. It describes the amount of damage one trusted identity can cause once authorization is too broad or too persistent. The concept is useful because it spans human accounts, NHIs, and autonomous systems without pretending the risks are identical. Practitioners should measure and reduce the blast radius of every identity class.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite.
• For the next control layer: review the Ultimate Guide to NHIs for lifecycle, visibility, and offboarding discipline that supports runtime authorization governance.

What this signals

Identity blast radius will become a more useful operating metric than entitlement count. The organisations that can explain effective permissions across human, non-human, and vendor identities will detect exposure earlier and contain it faster. A programme that cannot answer what an identity can do right now is already behind the threat model.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, authorization sprawl is no longer an edge case for machine identities. The same governance failure now shows up in service accounts, workloads, and third-party access, which means policy unification has become a prerequisite for containment.

Runtime authorization will matter more as AI systems and automation consume broader access paths. Organisations that still depend on static approvals and periodic review will struggle to see how access is actually used. That makes short-lived, observable authorization a programme design issue rather than a tooling preference.

For practitioners

• Map effective permissions, not just assigned roles. Trace what each high-risk identity can actually reach across cloud IAM, SaaS, Terraform, and internal tools. Reconcile the configured role with the real access path, then remove entitlements that only exist because multiple systems overlap.
• Move critical access to task-specific sessions. Use just-in-time access for privileged actions, vendor access, and sensitive data paths so the default state is no standing privilege. Keep the session scope narrow and bind it to the task, environment, and identity type.
• Version and test authorization policies before rollout. Treat policies as code with change control, regression testing, and reviewable diffs so access logic is explainable before it reaches production. This reduces the chance that a small rule change creates an outsized exposure path.
• Separate third-party identities from internal trust zones. Give vendors and other external actors explicit boundaries, separate entitlement sets, and stronger runtime monitoring. Do not let a legitimate external identity inherit broad internal access simply because it is operationally convenient.

Key takeaways

• Authorization failures, not login failures, explain most large-scale breach impact because attackers rely on trusted access paths.
• Evidence from major incidents and breach research shows that valid credentials, privilege escalation, and lateral movement drive the damage.
• IAM teams should redesign governance around effective access, task-specific sessions, and runtime policy enforcement across every identity class.

Key terms

• Effective Access: The permissions an identity can actually use after all roles, policies, inheritance, and platform-specific rules are combined. It is often broader or narrower than what a dashboard shows, which is why governance must examine runtime reality rather than relying on assigned entitlements alone.
• Identity Blast Radius: The amount of damage a single identity can cause if it is compromised or abused. In practice, this depends on privilege scope, session duration, segmentation, and the reach of downstream systems. Reducing blast radius is the core objective of modern authorization governance.
• Runtime Authorization: Authorization decisions made at the moment access is used, rather than only at provisioning or approval time. This approach matters because risk changes during a session, and static approval records do not reliably reflect what an identity can do after it enters the environment.
• Task-Specific Access: Access granted for a narrow purpose, limited in scope, and often time-bound. It reduces standing privilege by tying permissions to the work being performed, which is especially important in cloud, SaaS, vendor, and machine access scenarios where broad roles create unnecessary exposure.

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.

This post draws on content published by Opal Security: Back Authorization has always been the real perimeter. Read the original.