Just-in-Time Access for Humans

Executive summary

Human access to cloud accounts has been governed the same way for years: grant a standing permission set, recertify it in a quarterly access review, and hope the review catches what changed. The result is predictable. Administrators and on-call engineers carry powerful permission sets around the clock, access reviews rubber-stamp what nobody remembers granting, and a single phished credential inherits everything its owner could ever do. The alternatives have not fared better — PAM vaults translate poorly to cloud-native access, and CIEM remediation hand-trims entitlements one ticket at a time.

Just-in-Time (JIT) access in the Sonrai Cloud Permissions Firewall takes standing privilege off the table without a cleanup project. Humans request access to a permission set in a specific account when they need it, through Slack or Microsoft Teams; the grant is time-bound and expires automatically. Permission sets never sanctioned for an account can be denied outright — even ones never enrolled in JIT. Dormant identities are quarantined rather than deleted, and every session ends with an AI-generated summary.

Key takeaways

The defect in standing access is temporal. A permission set granted for a task in March is still live on a November weekend for an attacker holding the credential.
Quarterly recertification degenerates into bulk approval. A reviewer facing hundreds of assignments cannot know what is still needed, so the safe answer is always to keep it.
Adoption requires no entitlement cleanup. Existing permission sets, assignments, and IAM policies stay exactly where they are. Enforcement sits above them, and the standing grants underneath stop mattering.
Deny-first covers what was never enrolled. Most JIT products govern only what has been enrolled in them. The Cloud Permissions Firewall can block permission sets not sanctioned for an account whether or not they were ever enrolled — which is where the forgotten risk actually lives.
Nobody gets dead-ended. A user who never saw the JIT training can log in exactly as before; the console returns an access error and a Slack message arrives moments later asking them to justify the need.
Approval is not a blank cheque. Inside an approved session, privileged actions are still governed by what that user has actually done before, so an unfamiliar action raises a secondary approval.
Incident response gets one gate, not many. Auto Permissions on Demand lets designated on-call permission sets cover all privileged activity for the session, because interrupting a responder mid-incident is how controls get bypassed.
Every session ends with an AI-written account of what happened and what looked wrong, so approvers read a narrative instead of a CloudTrail export.

Standing privilege and the access-review treadmill

The core defect of standing access is temporal. A permission set granted for a task in March is still live on a November weekend, available to an attacker who has compromised the credential. Nothing about the original grant was wrong; it simply outlived the work it was issued for.

Quarterly recertification degenerates into bulk approval

Recertifying hundreds of assignments every quarter asks a reviewer a question they cannot answer: is this still needed? Without knowing what each assignment is currently being used for, the safe response is to keep it. The review completes, the numbers look healthy, and nothing has been removed.

Trimming entitlements hits the same wall as every ticket-driven program

Each removal is a negotiation, each one risks blocking legitimate work, and the estate regrows faster than it can be pruned. What is needed is not a better cleanup process but a model in which cleanup is unnecessary.

The alternatives have not solved it either

Privileged Access Management vaults were designed for a world of long-lived servers and shared administrator credentials, and they translate poorly to cloud-native access patterns built on federated identity and permission sets. CIEM tools diagnose over-permissioning accurately but hand the remediation back as tickets, which returns you to hand-trimming entitlements one at a time.

Privileged access exists only while it is being used, is approved by the people with context, and leaves a reviewable record every time.

Standing access vs. just-in-time access

How standing permission sets with periodic recertification compare to time-bound just-in-time access.
Dimension	Standing access with quarterly review	JIT in the Cloud Permissions Firewall
When privilege exists	Continuously, from grant until someone removes it	Only for the duration of an approved request
How access ends	A revocation someone has to perform	The grant expires on its own; there is nothing to revoke
Value to a phished credential	Everything its owner could ever do	Only what is currently approved and unexpired
Adoption cost	N/A - it is the status quo	No entitlement cleanup; a JIT posture in days
Coverage of forgotten access	Whatever the review happens to catch	Deny-first blocks unsanctioned permission sets, enrolled or not
Who decides	A reviewer working through a list out of context	The scope owner, in Slack or Teams, at the moment of need
Inside an approved session	Full permission set, unconditionally	Least privilege still applies; unfamiliar privileged actions raise a second approval
Dormant identities	Survive until someone dares to delete them	Quarantined by an org-level deny, revived through a JIT approval in seconds
Evidence produced	An attestation that the review happened	An AI-written summary of what happened in every session

Access that exists only when it is needed

Permission sets are enrolled in JIT and scoped to the accounts where they are sanctioned. A user makes a request — from Slack, from Microsoft Teams, or simply by logging into the AWS console — naming the permission set, the account, and the duration. It routes to the scope's owner, who approves it where they already work.

When the grant expires, the access is simply gone: nothing to revoke, nothing to recertify, nothing for an attacker to find. Unanswered requests escalate to the approver at the next level up the scope hierarchy, and unapproved requests are denied. A default deny state persists otherwise.

No prior request flow is required

A user can log in exactly as they did before JIT existed. The AWS console returns an access error, and within moments a Slack message from the Sonrai app asks them to justify the need — or to self-approve, where that is allowed. Even someone who missed the JIT training is never dead-ended, because the request flow comes to them. An optional browser extension makes the same experience seamless directly in the console.

Seven things that make this work in production

1. No cleanup of already-existing entitlements

Adopting JIT does not start with an audit of who has what. Existing permission sets, assignments, and IAM policies stay exactly where they are — no rewriting, no revocation campaign. Enforcement sits above existing entitlements: what is approved for an account works, what is not is denied, and the standing grants underneath simply stop mattering. Organizations reach a JIT posture in days.

2. Deny-first: unsanctioned permission sets are blocked, enrolled or not

Most JIT products govern only what has been enrolled in them. To ignore access that is not enrolled — and therefore under-managed and forgotten — is to ignore the riskiest access in the estate. The Cloud Permissions Firewall can invert this by blocking permission sets not approved for an account, whether or not they were ever enrolled in JIT. Assignments created years ago, provisioned too broadly, or added out of band become unusable everywhere they have not been sanctioned.

3. Zombie identities: quarantined safely, revived through JIT

Every organization carries identities that stopped being used long ago — a test workload, an abandoned AI hackathon project, a former contractor, the admin user from a migration that finished two years back. These are pure attack surface, and they are not rare: Sonrai's 2024 Cloud Access Data Report found that 61% of cloud identities are unused.

Confirming they are safe to delete usually takes extensive human-to-human investigation into what they do and who owns them, so the irreversible step gets deferred indefinitely. The Cloud Permissions Firewall quarantines them instead: an organization-level deny makes them instantly unusable to an attacker while destroying nothing. Because JIT is already the front door, revival is simple — an owner approves a request and the identity is working again in seconds. The same process can open and close access for privileged deployment identities during change windows.

4. Approved is not unlimited: least privilege inside the session

A JIT approval opens a permission set. It does not suspend least privilege. Inside the session, privileged actions are still governed by what this user has actually done before.

An SSO user approved into Administrator access who regularly changes Route 53 DNS records finds those changes pre-approved the moment the session is active. If that same user has never created an access key, the first attempt raises a secondary approval before it proceeds. Familiar workflows run without friction, while a hijacked session — or an operator drifting beyond their pattern — meets a human check at the first unfamiliar privileged action.

5. Auto Permissions on Demand: on-call to SuperAdmin in one approval

That in-session least-privilege layer is a choice, made per permission set. Interrupting a responder mid-incident with an approval for every change is how controls get bypassed, so for designated on-call and incident-response permission sets it can be toggled off via Auto Permissions on Demand.

The JIT approval itself then covers all privileged activity for that session: no secondary approvals, no re-challenge when the investigation takes a new turn. One approval is the only human gate, with the session clock, scope, and record-keeping still bounding it. Everywhere else, the extra checks stay on.

6. AI session summaries: what happened, and what looked wrong

Knowing what happened inside a time-bound session is critical for visibility and compliance. Every JIT session produces an AI-generated summary covering both what happened — the services touched, the changes made — and any suspicious activity, meaning actions outside the stated purpose of the request or activity inconsistent with the permission set's normal use. Approvers review a readable narrative instead of a CloudTrail export, and unusual sessions surface themselves.

7. Approval flows as simple, or as demanding, as the access warrants

Approval flows are configured per permission set and per scope, from self-approval — designated low-risk access granted instantly, with a full record kept — up through mandatory second-party approval. Routing can differ by time and permission set: business-hours requests to the resource owner, after-hours requests to the on-call approver, and the most sensitive permission sets always requiring a second party. Friction is calibrated to risk.

What adoption looks like

Scope. Decide which permission sets are sanctioned in which accounts, and quarantine the dormant identities that should not be usable at all. Optionally deny everything else, enrolled in JIT or not.
Delegate. Establish owners and approvers per scope, and set the conditions: self-approval, grant time limits, second-party requirements, routing, and escalation.
Enroll. Enroll the permission sets humans should request just-in-time, including on-call permission sets covered by Auto Permissions on Demand.
Operate. Requests and approvals flow through Slack or Teams, grants expire automatically, and every session ends with an AI session summary.

Key concepts and definitions

Just-in-time (JIT) access: Privilege granted only at the moment it is needed and for a bounded period, rather than held continuously. The grant expires on its own, so access ends without anyone performing a revocation.
Standing privilege: Access that remains live from the moment it is granted until someone removes it. Its defining risk is temporal: the permission outlives the task it was issued for and is fully available to anyone who later compromises the credential.
Permission set: A named bundle of permissions assigned to users for a given cloud account, typically through federated single sign-on. In JIT, permission sets are the unit that gets enrolled, sanctioned per account, and requested.
Access review (recertification): A periodic exercise in which reviewers confirm whether existing access is still required. At cloud scale it tends toward bulk approval, because a reviewer working through hundreds of assignments has no way to know which are still in use.
Deny-first coverage: Blocking permission sets that are not sanctioned for an account regardless of whether they were ever enrolled in JIT. It matters because unenrolled access is the access nobody is managing, which makes it the most likely to be forgotten and the most attractive to an attacker.
Zombie identity: A dormant, unused role or user left over from a finished project, a departed contractor, or a completed migration. Sonrai's 2024 Cloud Access Data Report found 61% of cloud identities are unused. They are quarantined with an organization-level deny rather than deleted, so the change is reversible through an approval.
Quarantine: An organization-level deny that makes an identity instantly unusable to an attacker while destroying nothing. It delivers the risk reduction of deletion without its irreversibility, which is what makes it safe to apply to identities nobody can confidently account for.
Auto Permissions on Demand: A per-permission-set setting under which a single JIT approval covers all privileged activity for the session, with no secondary approvals. Intended for on-call and incident-response access, where repeated challenges would push responders to bypass the control entirely.
Secondary approval: A human check raised inside an already-approved session when a user attempts a privileged action they have no history of performing. It is what keeps an approved session from becoming unlimited privilege.
AI session summary: An automatically written account of a completed JIT session covering the services touched and changes made, plus any activity inconsistent with the request's stated purpose or the permission set's normal use.
Scope: A level of the cloud hierarchy — organization, organizational unit, or account — that has a designated owner and approvers. Requests route to the owner of the relevant scope, and unanswered requests escalate to the next level up.
Default deny: The resting state of the system. Absent an approved, unexpired grant, privileged access is denied, so privilege exists only while it is actively in use.

Conclusion

Standing human privilege persists not because anyone defends it, but because removing it has always been a project too painful to finish.

JIT in the Sonrai Cloud Permissions Firewall removes the project: no entitlement cleanup, deny-first coverage for what nobody remembered to govern, zombies quarantined instead of deleted nervously, one approval per incident, least privilege enforced even inside an approved session, and an AI-written account of every session.

Access arrives in the time it takes an approver to tap a Slack message — and privilege exists only while it is in use.

Frequently asked questions

What is just-in-time (JIT) access in cloud environments?

Just-in-time access means privilege is granted only at the moment it is needed and for a bounded period, instead of being held continuously. A user requests a permission set in a specific account for a stated duration, an owner approves it, and the grant expires on its own. Because there is nothing standing, there is nothing to revoke and nothing for a compromised credential to inherit later.

Why are standing access and quarterly access reviews not enough?

The problem with standing access is temporal: a permission set granted for a task in March is still live on a November weekend for anyone holding the credential. Quarterly recertification does not fix it, because a reviewer facing hundreds of assignments cannot know which are still needed, so the safe answer is to keep them. Reviews complete, numbers look healthy, and nothing is actually removed.

How is JIT different from a PAM vault?

Privileged Access Management vaults were built for long-lived servers and shared administrator credentials, and they translate poorly to cloud-native access based on federated identity and permission sets. JIT in the Cloud Permissions Firewall works with the permission sets your SSO already issues, routes approvals through Slack or Teams, and enforces at the cloud organization level rather than brokering a credential out of a vault.

Do I have to clean up existing entitlements before adopting JIT?

No. Existing permission sets, assignments, and IAM policies stay exactly where they are — no rewriting and no revocation campaign. Enforcement sits above them: what is sanctioned for an account works, what is not is denied, and the standing grants underneath stop mattering. That is what allows organizations to reach a JIT posture in days rather than running a cleanup project first.

How do people request access?

From Slack, from Microsoft Teams, or simply by logging into the AWS console. A request names the permission set, the account, and the duration, then routes to the owner of that scope, who approves it in the tool they already work in. An optional browser extension makes the same flow seamless directly in the console.

What happens to someone who does not know JIT exists and just logs in?

They are never dead-ended. The user logs in exactly as they did before, the AWS console returns an access error, and within moments a Slack message from the Sonrai app asks them to justify the need — or to self-approve, where that is permitted. The request flow comes to the user rather than requiring them to know about it in advance.

What happens when a JIT grant expires?

The access is simply gone. There is nothing to revoke, nothing to recertify, and nothing left for an attacker to find. The system returns to its default deny state, which is what it holds whenever there is no approved, unexpired grant.

Can you block permission sets that were never enrolled in JIT?

Yes, and this is a deliberate difference from most JIT products, which govern only what has been enrolled in them. The Cloud Permissions Firewall can block permission sets not sanctioned for an account whether or not they were ever enrolled. Assignments created years ago, provisioned too broadly, or added out of band become unusable where they have not been sanctioned — which is precisely where forgotten risk accumulates.

Does an approved JIT session give unlimited privilege?

No. A JIT approval opens a permission set but does not suspend least privilege. Inside the session, privileged actions are still governed by what that user has actually done before. Someone approved into Administrator access who routinely edits Route 53 records finds those changes pre-approved, but if they have never created an access key, that first attempt raises a secondary approval before it proceeds.

How does this work during an incident, when speed matters?

Through Auto Permissions on Demand, a per-permission-set setting for designated on-call and incident-response access. The JIT approval itself covers all privileged activity for that session, with no secondary approvals and no re-challenge when the investigation takes a new turn. One approval is the only human gate, with the session clock, scope, and record-keeping still bounding it. Interrupting a responder mid-incident for every change is how controls get bypassed, so this is deliberate.

What is an AI session summary?

An automatically written account of each completed JIT session. It covers what happened — the services touched and the changes made — and flags suspicious activity, meaning actions outside the request's stated purpose or activity inconsistent with how that permission set is normally used. Approvers read a narrative rather than a CloudTrail export, so unusual sessions surface themselves.

How do you handle dormant or zombie identities?

They are quarantined rather than deleted. An organization-level deny makes the identity instantly unusable to an attacker while destroying nothing, which sidesteps the investigation that normally stalls deletion indefinitely. Because JIT is already the front door, revival takes one approval and seconds. Sonrai's 2024 Cloud Access Data Report found 61% of cloud identities are unused, so this is a large share of the estate.

Can approval requirements differ by permission set or time of day?

Yes. Flows are configured per permission set and per scope, ranging from self-approval for designated low-risk access — granted instantly, with a full record kept — up to mandatory second-party approval. Routing can vary by time: business-hours requests to the resource owner, after-hours requests to the on-call approver, and the most sensitive permission sets always requiring a second party.

How long does it take to adopt JIT?

Days. Because adoption requires no entitlement cleanup and enforcement sits above the access that already exists, there is no audit phase to work through first. The sequence is to scope which permission sets are sanctioned where, delegate owners and approvers, enroll the permission sets humans should request, and operate through Slack or Teams.

Research and sources

This paper describes the behavior of just-in-time access in the Sonrai Cloud Permissions Firewall: the request and approval flow, expiry, deny-first coverage, in-session least privilege, Auto Permissions on Demand, quarantine, and AI session summaries are product descriptions rather than research findings.

The one statistic cited — that 61% of cloud identities are unused — comes from the Sonrai 2024 Cloud Access Data Report, which analyzed production cloud estates averaging 11,290 identities each, of which 19% were human and 81% were machine identities.

Prefer the PDF? Download the full whitepaper to share with your team.

Download the whitepaper (PDF)

Interactive Product Tour