Browser-level cloud access closes the missing middle in IAM

At a glance

What this is: This analysis says the cloud security stack has a visibility gap after authentication, because browser-session abuse can look like normal user activity to CSPM and CNAPP.

Why it matters: IAM, cloud security, and NHI teams need to account for the live browser session because control-plane posture alone cannot distinguish legitimate access from hijacked access.

Context

Cloud access now lives in the browser as much as in the cloud control plane. CSPM and CNAPP can tell teams whether an IAM role is over-permissive or a resource is misconfigured, but they are not designed to observe what happens after a user authenticates and starts working inside an approved session.

That creates a governance gap between identity verification and cloud action. Once phishing, session hijacking, or token theft has produced a valid session, infrastructure-centric tooling often sees only normal behaviour, even when the session is being used to reach sensitive cloud functions or SaaS controls.

The result is a blind spot in cloud IAM operations: teams can harden configuration and still miss abuse that happens through the browser. This is increasingly typical in cloud-native environments where access is mediated through web sessions rather than direct control-plane interaction.

Key questions

Q: What breaks when cloud security only monitors the control plane?

A: Teams lose sight of the interaction layer where authenticated users act through the browser, so malicious behaviour can look like normal cloud use. CSPM and CNAPP still matter, but they cannot distinguish a legitimate login from a hijacked session. The practical failure is that security posture appears intact while the browser session is already being abused.

Q: Why can a compromised browser session bypass cloud IAM controls?

A: Because IAM policies usually evaluate who is allowed to act, not whether the current browser interaction is trustworthy. If an attacker inherits a valid session through phishing, token theft, or session hijacking, the requests can remain inside expected permissions. The result is authorised activity from an untrusted operator, which is hard for posture tools to spot.

Q: What signs show that browser-level access governance is missing?

A: Look for cloud-connected applications that allow local accounts, password-only access, duplicate identities, or weak MFA coverage outside centrally managed apps. Another signal is when incident teams can only see login time and IP address, but not the user interaction that led to a sensitive action. Those gaps indicate the browser layer is not governed.

Q: How should cloud teams respond when browser access becomes the real control plane?

A: They should extend visibility and response into the live session, not stop at IdP logs or cloud posture checks. That means using browser context to detect suspicious rendering, token theft, and risky interaction patterns, while also preserving evidence that shows what the user actually did. Without that layer, response is partial.

Technical breakdown

Why CSPM and CNAPP stop short of session abuse

CSPM and CNAPP are built to validate configuration, posture, and permissions in cloud environments. They are strong at spotting exposed resources, risky IAM policies, and control-plane misconfiguration, but they do not instrument the browser session where identity turns into action. That matters because the browser is now the execution surface for cloud work. If an attacker inherits a legitimate session, the cloud platform may still record allowed actions, even when the session itself has been manipulated. The tooling is looking at entitlement state, not interaction state.

Practical implication: Treat posture tooling as necessary but incomplete, and recognise that browser-level telemetry covers a different control boundary.

Why valid sessions hide malicious behaviour

Modern cloud attacks often avoid direct exploitation of the cloud plane. Instead, the adversary obtains a valid authentication event through phishing, session hijacking, or token theft, then operates inside the approved session. To the IdP and cloud platform, the user is authenticated and the requests are authorised, so the activity blends in with normal work. The weak point is not policy definition but session trust. Once the attacker is inside the authenticated browser session, many defensive signals collapse into ordinary user behaviour unless the browser itself is observed.

Practical implication: Assume that authenticated does not mean trustworthy, and validate the session layer separately from the IdP and cloud account.

The browser is becoming the real control plane for cloud access

When users interact with cloud services, they do so through a browser, and that browser session is where the most meaningful security decisions are now being exercised. This is not the same as endpoint security or infrastructure security. It is session-level governance over what the user actually saw, submitted, and clicked before any cloud API call occurred. That makes browser inspection useful for both prevention and response. It can surface shadow SaaS, local accounts, and MFA gaps that conventional cloud tooling cannot map reliably, especially when application estates are fragmented.

Practical implication: Extend access governance into the browser so that cloud security decisions reflect the session actually used to reach the application.

Threat narrative

Attacker objective: The attacker aims to operate inside trusted cloud workflows long enough to reach sensitive actions without triggering posture-based controls.

1. Entry begins when the attacker compromises a user through phishing, session hijacking, or token theft and obtains an approved browser session.
2. Escalation occurs inside that session because the attacker works with valid identity state, so cloud and IdP tools see authorised activity rather than a clear anomaly.
3. Impact follows when sensitive cloud actions are completed through the browser before infrastructure-level signals or postures can reveal abuse.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

Browser-session visibility is the missing control layer in cloud IAM: posture tools govern configuration, but they do not govern the live interaction layer where identity becomes action. That leaves a structural blind spot between authentication and cloud execution. The practitioner implication is that cloud access governance must include the browser session, not just the IdP and control plane.

Session trust, not just policy correctness, is now the decisive governance problem: a valid login can still represent compromised access if the session was obtained through phishing, token theft, or hijacking. This is not a failure of IAM policy design alone; it is a failure to observe the runtime context in which policy is exercised. Practitioners need to evaluate whether their controls can distinguish approved access from approved abuse.

Control-plane security is no longer sufficient on its own: cloud teams have spent years hardening IAM, infrastructure as code, and posture management, yet the article shows how easily an attacker can step around those controls by operating in the browser. The named concept here is the missing middle, the gap between identity authentication and API execution where real abuse now happens. That gap has to be treated as a first-class governance boundary.

Shadow SaaS and local account sprawl widen the browser gap: once access is distributed across unmanaged applications, duplicate identities, and password-only workflows, cloud security teams lose the ability to rely on centralised assurance. The issue is not only visibility but consistency of access enforcement across the app estate. Practitioners should read this as a signal that access governance must extend to every cloud application path, not only the ones under direct platform management.

From our research library:

• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.

What this signals

Browser-level governance changes the meaning of cloud access: once work happens through a session, the question is no longer only whether the environment is configured correctly. The question becomes whether the security team can observe the moment identity turns into action, which is where many cloud incidents now play out.

Missing middle is a useful operating concept for cloud IAM: the gap between authentication and final API execution is where conventional posture tools lose context. Practitioners should use that gap to reframe access governance around session visibility, not just configuration assurance.

For practitioners

• Map browser-mediated cloud access paths Identify where users actually reach cloud services through the browser, including shadow SaaS and unmanaged app flows, so the real control surface is visible.
• Correlate session context with identity events Retain click-level browser context alongside IdP events so responders can tell whether a session was abused, not merely authenticated.
• Review password-only access in shadow applications Find cloud-connected apps that still allow local accounts or bypass MFA and prioritise them because they undermine cloud access even when core IAM looks sound.
• Extend access governance to the live session Treat the browser session as part of the control plane and define what activity should be visible, inspectable, and blockable before the final API call.
• Validate response workflows against browser evidence Make sure incident teams can use browser-session evidence to scope compromise quickly instead of relying only on login timestamps and IP addresses.

Key takeaways

• Cloud security posture tools can validate configuration, but they do not see browser-session abuse that happens after legitimate authentication.
• The main evidence of the gap is that an attacker can operate inside an approved session while identity and infrastructure signals still look normal.
• Closing this gap requires browser-level visibility so teams can inspect, detect, and respond before cloud actions complete.

Key terms

• Missing middle: The missing middle is the gap between identity provider authentication and final cloud or SaaS action. It is the place where posture tools, login logs, and infrastructure monitoring often lose visibility, even though the browser session can still be abused by a valid-looking identity.
• Browser-layer visibility: Browser-layer visibility is the ability to observe user activity where it actually happens in the web session, including app use, input, consent, and extensions. For AI governance, it becomes the evidence layer that shows what employees used, what data they exposed, and what access they granted.
• Session abuse: Session abuse is the misuse of an already established browser session to perform actions that were not intended by the legitimate user or system owner. It can include token theft, consent misuse, hijacked navigation, or post-authentication actions that bypass the original access decision.
• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.

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.