Temporary grants and emergency access
Bound administrative access by principal, scope, purpose, and expiry.
Temporary grants assign a role for a bounded period without changing a team's permanent bindings. They support maintenance approval, recovery, and other administrative tasks that require short-lived authority.
Request a grant
Open Access → Temporary grants → Request. Select the principal, role, resource scope, reason, and expiry. The organization policy sets the maximum duration and required approver team. The requested role must be eligible for temporary assignment.
The request creates no effective permission until approval and activation. Requesters cannot approve themselves under the default policy. An approver can narrow the requested scope or duration but cannot grant authority the approver is forbidden to delegate.
Permission evaluation
An active grant combines with ordinary bindings. It does not subtract permissions from another role and does not expand the scopes of an existing API key. A service account still needs the corresponding key scope for each request.
Record the grant ID in administrative requests when the client supports it. Audit events retain the binding that authorized the action so a later review can distinguish routine authority from emergency elevation.
Expiry and revocation
Expiry stops new requests that rely on the grant. To end it early, open
Access → Temporary grants, select the grant, and choose Revoke with a
reason. Check that its state is revoked; another binding can still authorize
the same principal.
Accepted work and open guest sessions need separate handling. Find active work under Operations → Queue and follow cancellation. Revoke a managed console connection through the Guest Console API, then check the guest for shells or processes that remain active. Disconnecting the managed transport does not log those out.
Revocation leaves completed configuration changes applied. Reverse each unwanted change through its resource's normal operation, and revoke any external credentials at their issuing provider.
Recovery owner
Keep a designated organization recovery owner independent of the ordinary SSO or SCIM path. Its credentials and recovery factors must be accessible through the organization's tested incident process, including during identity-provider failure.
Emergency use is audited and should be reviewed after the incident. A recovery account must not become the unrecorded shared identity for routine administration. Assign normal operators their own roles and service accounts.
Cleanup after an incident
Open Access → Temporary grants and review the grants created for the incident. Revoke unused grants, then use Simulate access for each affected principal and resource to check remaining permissions.
Review the incident's separately created access: API keys, guest sessions, and policy exceptions. Revoke external credentials at their provider. Temporary-grant expiry does not remove any of these objects.
Use Access API for bindings and grant requests, custom-role simulation to inspect effective permissions, and policy exceptions when the issue is an admission rule rather than missing identity permission.