Revoke once, access stops

When something goes wrong you need access to stop, and you need to be able to show that it stopped. This is what one revocation actually reaches, and where the edges are.

Keycard issues nothing new once you revoke. A server that asks Keycard for a credential on every call, like the Quickstart’s, fails on its next call; a token an agent already holds keeps working until it expires. A Keycard-issued credential lives 24 hours by default, less if the Resource sets a shorter Credential Lifetime, and a credential brokered from an external Provider keeps that Provider’s lifetime. Security Architecture has the figures.

Containment for agents usually means rotating credentials across every system that holds one. That is slow at the moment when speed is the whole point, and it is hard to prove afterwards.

The proof is the harder half. Rotating a secret leaves no record tying the incident to the moment access ended. When an auditor asks when this agent lost access, the answer is reconstructed from deployment timestamps rather than read from a log.

Standing access makes it worse. An agent holding a long-lived credential has access from the moment it was granted until someone remembers to take it away, so the window is measured in however long it took to notice.

• You need to withdraw one agent’s or one person’s access without redeploying anything
• A reviewer wants evidence that access ended, not an assurance
• Access was granted per user and per Resource, so it can be withdrawn the same way
• You are being asked what your containment story is, and you would rather answer precisely than confidently

Suppose a contractor’s engagement ends, or an agent starts making requests that look wrong. You want that agent’s access to end, you want to know it ended, and you want the record to show both the withdrawal and the refusal.

Where the agent obtained a credential outside Keycard, revoking here reaches nothing, because the coverage is the credentials Keycard issues.

Where the downstream system holds its own long-lived credential that Keycard brokered rather than minted, withdrawal behaves differently. That case is covered below and it is the one most likely to surprise a reviewer.

Access is granted per User and per Resource, so it can be withdrawn the same way. Revoking a grant tells Keycard to stop satisfying requests for that pairing.

The next time the Application asks for a credential, whether that is a fresh exchange or a refresh, there is no grant to satisfy it and the request fails. The User has to authorize again before anything is issued.

The two halves are recorded in different places. The withdrawal appears on the Resource’s Activity feed (Read an Activity Feed). The refused request that follows is a Failure in the Audit Log carrying insufficient_authorization, which is a distinct code from the access_denied a policy denial returns. That distinction is what lets you show a reviewer which mechanism stopped the call.

flowchart LR
    A[Revoke the grant] --> B[Keycard]
    C[Agent requests a credential] --> B
    B -->|"no grant to satisfy it"| D["Refused: insufficient_authorization"]
    B -->|"withdrawal"| H[Activity feed]
    D --> E[Audit Log]
    F[Credential already held] -.->|"keeps working until it expires"| G[Resource]

1. You revoke the grant for that User and Resource, in the Console or through the API.
2. Keycard stops issuing for that pairing. The next exchange fails, and so does a refresh, so the Application cannot quietly extend its access past the credential it currently holds.
3. The Application receives insufficient_authorization and should treat it as a prompt to re-authorize rather than as a transient error.
4. The revocation is on the Resource’s Activity feed, and the refusal is in the Audit Log, which exports to your own bucket alongside everything else.

One action, in one place. Keycard issues nothing new: a server that asks on every call stops at its next call, and a token already held stops when it expires, bounded by its lifetime (24 hours by default for a Keycard-issued credential, set per Resource; a brokered credential keeps its Provider’s lifetime). Nothing is redeployed and no secret is rotated across a fleet.

The evidence is a byproduct rather than an exercise. The refusal in the Audit Log names the person, the Application, and the Resource. The withdrawal is on the Resource’s Activity feed, so the question of when access ended is read rather than reconstructed.

Blast radius is bounded even before you act, because credentials expire on their own. Access that nobody renews lapses, which is a different posture from access that persists until someone remembers it.

For a client that holds a token, containment is bounded by the current credential, not instant. This is the single most important sentence on the page. Where a reviewer needs access to stop within a hard bound, the number that matters is the credential lifetime: set it per Resource with Credential Lifetime, and check what the external Provider issues for brokered access.

Revocation is per grant. It is scoped to one User and one Resource, so cutting someone off from everything means either repeating it per Resource or disabling the person, which is a different action with a wider reach.

Brokered access needs a second step. Where the credential came from an external provider such as Google or GitHub rather than being minted by Keycard, revoking the Keycard grant stops Keycard brokering anything new, and it does not revoke what that provider already issued. Cut that off in the provider’s own connected-apps settings as well, or the access continues on the provider’s terms.

A brokered static credential is withdrawn by rotating it. Where Keycard holds a static secret in Vault and hands it to an Application on request, it expires on nobody’s schedule. Rotation remains the mechanism, so plan for it the way you would for any shared secret. Resources covers how a vaulted credential differs from an issued one.

It stops the next issuance and it stops refresh for that Resource, so the agent can’t quietly extend that access. A server that asks for a credential on every call is refused on its next one. Revoking does not invalidate a credential already in the agent’s hands, which lives out its remaining lifetime.

Disabling or removing the person from the People page is the wider lever, and it stops them signing in or obtaining anything new rather than working through grants one Resource at a time. The same boundary applies underneath, so a credential already issued lives out its lifetime either way. Revoke access covers both paths.

Revoke while a session is running and have the Application request a new credential. The request fails with insufficient_authorization and appears in the Audit Log as a Failure naming the person, the Application, and the Resource; the revocation itself is on the Resource’s Activity feed. If export is configured, the Audit Log records reach your own bucket, so the evidence lives in your infrastructure rather than ours.

They stop the same call for different reasons and the log distinguishes them. A policy denial returns access_denied and the error names the policy and policy set that decided it. A revoked or absent grant returns insufficient_authorization, meaning the User has to authorize again. Reading which one you got tells you whether to change a rule or to re-establish consent.

• An employee leaving, where the directory change and the grant withdrawal need to agree
• An agent behaving unexpectedly, where you want it stopped before you understand why
• A time-boxed engagement, where access should end on a date rather than when someone remembers
• A compromised host, where the question is what that host can still reach and for how long

The shape is the same each time. Access was granted somewhere specific, it is withdrawn in that same place, and the record of both is the thing you can hand to whoever asks.

• Revoke access is the walkthrough, including what happens after you revoke
• What happens after you revoke is the precise behavior, worth reading before you describe it to a reviewer
• Audit Log & Sessions is where the refused credential request appears, which is how you confirm a revocation took effect
• Read an Activity Feed is where the withdrawal itself is recorded, on the Resource’s feed
• Credentials explains issuance, refresh, and what a credential is scoped to
• Access Policies is the other way a call gets refused, with a different error code
• Act as the user who asked is the pattern that makes per-user revocation possible in the first place