GCP just-in-time access exposes the limits of static permissions

At a glance

What this is: This is an analysis of GCP just-in-time access and its finding that static IAM permissions create lingering exposure in dynamic cloud environments.

Why it matters: It matters because IAM, PAM, and NHI programmes need controls that match time-bound cloud work, not permissions that remain valid long after the task has finished.

Context

Just-in-time access is a time-limited authorisation model that grants permissions only for the window in which a task needs them. In cloud environments, that matters because static IAM assignments often outlive the work they were created for and turn convenience into exposure.

Ploy’s article argues that GCP access control needs to move away from always-on permissions and toward temporary grants with monitoring and revocation. The underlying governance problem is not speed of access, but whether identity programmes can prevent standing privilege from becoming the default operating model.

The article also ties JIT access to least privilege, auditability, and MFA-backed workflows. That places the topic squarely in IAM, PAM, and NHI governance, because the same lifecycle issue appears whenever a credential or role remains available longer than the business need that justified it.

Key questions

Q: What breaks when static IAM is used for temporary cloud access?

A: Static IAM breaks when a role-based entitlement outlives the task it was meant to support. Access accumulates across projects, revocation lags behind real work, and organisations lose the ability to prove that permissions were temporary. The result is excess privilege, higher blast radius, and weaker compliance evidence for cloud operations.

Q: When does just-in-time access actually improve cloud security?

A: Just-in-time access improves cloud security when elevated privilege is narrowly scoped, time-limited, and fully logged. It works best for maintenance, break-glass, and exception workflows where standing privilege would otherwise remain in place. If approval, expiry, or auditing is weak, JIT only disguises over-privilege rather than removing it.

Q: What are the signs that cloud governance is too static for regional operating conditions?

A: The clearest signs are relying on broad global policies, lacking visibility into where resources run, and discovering regional costs or restrictions only after deployment. If teams cannot block specific services by region, move workloads proactively, or adapt controls by location and resource type, governance is already too rigid. Static control models break when regional risk and pricing diverge quickly.

Q: How should teams decide which access should be just-in-time?

A: Use just-in-time access for permissions that are high impact, infrequently needed, or sensitive enough that standing privilege creates unnecessary exposure. Keep persistent access only where operational continuity genuinely demands it. The decision should be based on task criticality, data sensitivity, and how quickly the risk changes during execution.

Technical breakdown

Why static IAM permissions fail in dynamic cloud environments

Static IAM permissions are assigned ahead of time and remain valid until someone removes them. In a cloud operating model, that creates a mismatch between the grant and the task, because access needs change faster than manual entitlement cleanup. The result is standing privilege, which widens the attack surface and makes every dormant role a potential path for abuse. JIT access narrows that window by making privilege conditional on an active request and a limited duration, rather than a permanent assignment.

Practical implication: treat persistent cloud roles as an exception state and measure how many remain active without a current business purpose.

How just-in-time access changes the privilege lifecycle

JIT access turns permission from a standing state into a time-boxed event. A request is made, access is approved or policy-matched, the privilege is issued for a defined period, and the entitlement is then revoked or expires. That lifecycle matters because it reduces the time available for misuse and creates a clearer audit trail for who accessed what and when. In governance terms, the control shifts from after-the-fact cleanup to controlled issuance and automatic expiry.

Practical implication: align approval, expiry, and logging so that temporary access cannot silently become a permanent entitlement.

Where JIT access sits with least privilege and MFA

Least privilege defines the minimum access needed for a task, while JIT defines when that access exists. They are related but not the same. JIT can also be paired with MFA to strengthen the step where a user or operator requests access, which helps reduce the impact of compromised credentials. In practice, the value comes from combining scoped entitlement, time limits, and strong authentication rather than relying on any single control to carry the whole model.

Practical implication: design JIT as a control bundle with least privilege, MFA, and revocation, not as a standalone feature.

Threat narrative

Attacker objective: The objective is to exploit lingering cloud permissions to reach resources that should have been available only briefly, or not at all.

1. Entry occurs when excessive cloud permissions remain available after the original business need has passed, leaving a reusable path into resources that should no longer be open.
2. Escalation follows when an actor encounters broad standing access instead of a short-lived, task-scoped grant, allowing broader reach than the current job justifies.
3. Impact is created by the persistence of those permissions, which extends exposure, complicates accountability, and increases the chance of unauthorised use or data access.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

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

Static permissioning is a governance assumption built for slower access patterns. Cloud IAM programmes often assume that a role granted today will still map cleanly to the same business need tomorrow. That assumption fails in environments where engineers, operators, and automated workflows move faster than entitlement cleanup. The implication is that standing privilege is not just inefficient, it is structurally misaligned with cloud operating reality.

Just-in-time access is really a control over exposure duration. Its significance is not that access becomes faster or slower, but that the valid window narrows to the smallest practical task interval. That makes auditability and revocation meaningful again because permission exists only while it is needed. Practitioners should treat duration as a first-class governance variable, not an implementation detail.

Ephemeral privilege changes the economics of cloud abuse. When permissions expire by design, attackers have less time to exploit them and defenders have a clearer boundary for accountability. That does not remove risk, but it reduces the value of stale entitlements that otherwise accumulate in IAM estates. The practical conclusion is that entitlement duration deserves the same governance attention as entitlement scope.

Access review programmes do not fix access that should never have been standing in the first place. Review cadences are designed to validate persisted entitlements, but cloud teams increasingly need issuance controls that prevent unnecessary persistence from forming. This is where JIT, PAM discipline, and NHI lifecycle thinking converge: the problem is not only who has access, but how long access remains valid before review even happens. Practitioners should redesign governance around expiry, not just certification.

Identity blast radius: the more persistent the permission, the larger the damage window. The article’s core lesson is that cloud identity programmes need a way to shrink the time in which a mistake, compromise, or misuse can matter. That insight applies across human operators and non-human identities alike, because both can accumulate access that outlives the moment that justified it. Security teams should measure blast radius in time as well as scope.

From our research library:

• 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.

What this signals

Exposure duration is becoming a core IAM design variable. Cloud programmes that still optimise for convenience first and cleanup later are carrying unnecessary identity risk. The better question is no longer who can eventually get in, but how long access can remain valid after the work has been completed.

JIT access changes governance from entitlement accumulation to entitlement expiry. That shift matters because the security value comes from reducing the window in which a bad grant can be abused. For IAM and PAM teams, the real measurement is whether temporary access is actually temporary in practice.

NHI and human identity governance are converging on the same control problem. Whether the actor is a person, a service account, or an operator, persistent permissions create the same governance debt. Programmes that can issue, expire, and review access on the right lifecycle boundary will be better placed to support cloud operations without normalising standing privilege.

For practitioners

• Map standing cloud roles and service permissions Identify which GCP roles, service accounts, and operator privileges remain active without a current task, ticket, or time limit. Focus first on broad administrative rights and cross-project access that creates the largest exposure window.
• Define issuance rules for time-bound access Set policy conditions for when access can be granted, how long it may remain valid, and what approval or authentication step is required before issuance. Make expiry automatic rather than dependent on manual cleanup.
• Pair JIT with MFA and logging Require strong authentication at the point of access request and ensure every temporary grant produces an audit trail that records requester, resource, duration, and revocation outcome.
• Separate privilege assignment from privilege use Do not let a role assignment become the default path for everyday work. Use temporary elevation for specific tasks so that access exists only in the operational window where it is needed.

Key takeaways

• Static cloud permissions leave access alive after the task that justified it has finished, which is the governance flaw this article highlights.
• The case for just-in-time access is about shrinking exposure windows and improving auditability, not just speeding up access requests.
• Teams that still depend on standing privilege should move toward temporary issuance, automatic expiry, and stronger request-time authentication.

Key terms

• Just-in-time tool access: Just-in-time tool access means granting a testing agent only the permissions it needs for a specific task and only for the time required. In offensive AI workflows, this limits the blast radius if the system behaves unexpectedly or reaches beyond its intended scope.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• Access Audit Trail: Access audit trail is the recorded history of access-related events, such as logins, permission changes, approvals, denials, and privileged actions. It provides evidence for investigation, compliance, and accountability by showing who accessed what, when it happened, from where, and under which authorization.

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 building or maturing an IAM programme, it is worth exploring.