> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usehasp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Revocation

> Revocation policies, cascade behavior, and what revocation does and does not undo.

Credentials can be revoked at any time by the delegating user, any org admin, or an automated policy. Revocation is immediate regardless of policy — both `drain` and `kill` stop new authorizations the moment revocation fires.

## Revocation policies

Configure the revocation policy per credential at issuance time.

| Policy  | In-flight behavior                                      | Use case                                                 |
| ------- | ------------------------------------------------------- | -------------------------------------------------------- |
| `drain` | In-flight invocations complete; no new calls authorized | Routine end-of-shift, scheduled rotation                 |
| `kill`  | All in-flight invocations are cancelled immediately     | High-risk credentials, incident response, emergency hold |

"Drain" does not mean a grace period for new calls — only calls already in progress are allowed to finish. The moment revocation fires, no new tool invocations are accepted under the credential.

## Cascade revocation

Revoking a credential also revokes every credential delegated from it, transitively. All descendants are revoked with `kill` policy regardless of their own configured policy. This is non-negotiable — once the root authorization is revoked, no downstream agent may continue.

The `agent.credential_revoked` audit event on the root credential lists all cascade-revoked descendant IDs in `cascade_revoked_credential_ids`.

## Via dashboard

**Developers → Agents → \[agent] → \[credential] → Revoke**

A confirmation dialog lets you enter an optional reason. The reason is recorded in the audit event.

## Via API

```
POST https://api.usehasp.com/v1/agents/{agent_id}/credentials/{credential_id}/revoke
Authorization: Bearer hasp_api_live_...
Content-Type: application/json

{
  "reason": "Shift ended"
}
```

See [Issuing Credentials: Revoking a credential](/ai-api/agents/issuing-credentials#revoking-a-credential) for the full endpoint spec.

## Archive-triggered revocation

Archiving an agent revokes all its active credentials with `kill` policy. The revocation is recorded with `revocation_reason: agent_archived`.

## Automatic expiry

Credentials have an `expires_at` timestamp. Once past, the credential is treated as inactive by the gateway — no revocation event is emitted, but `isActive()` returns false and the credential cannot authorize new invocations.

Expiry is distinct from revocation. An expired credential still appears in the credentials list with `status: expired`; a revoked credential has a `revoked_at` timestamp.

## Audit events

Every revocation emits `agent.credential_revoked` per affected credential (root + each cascade descendant), integrity-chain-anchored. The event records:

| Field                            | Description                                                          |
| -------------------------------- | -------------------------------------------------------------------- |
| `credential_id`                  | The revoked credential                                               |
| `agent_id`                       | The agent the credential was issued to                               |
| `actor_user_id`                  | Who triggered the revocation                                         |
| `revocation_policy`              | `drain` or `kill` (from the root credential)                         |
| `revocation_reason`              | Optional reason string                                               |
| `cascade_revoked_credential_ids` | IDs of descendants revoked in the same transaction (root event only) |

## What revocation does not do

Revocation prevents **future** actions. It does not unwind actions that completed before revocation. An EHR write that completed under a now-revoked credential remains valid in the audit chain — revocation cannot retroactively invalidate completed work. This is critical for data integrity in regulated workflows.