Compute
Create, rotate and revoke API keys
Give every agent and automation its own key, capture the secret during protected setup because it is shown once, and prove a revocation took effect before you trust it.
Before you start
You need administration authority, a place to store the new secret, and the name of the one thing this key will be used by.
If you cannot name that one thing, do not issue the key yet. A key without a named holder cannot be rotated or revoked with confidence.
Give every agent its own identity
Issue one identity per agent, per automation and per person. Never share a key between two of them.
A shared key cannot be revoked. Revoking it stops everything that used it, so nobody revokes it, and it outlives the reason it was created.
Separate identities also give you separate budgets and separate events. When spend moves, you can say which caller moved it.
Grant work scopes only
A work key holds six work scopes covering submission and reading its own results. The exact scope names are shown on the key when you create it, and in the OpenAPI description you download.
Management scopes are never mintable on a work key. Configuration, identity administration, destinations and finance stay disjoint from work submission by design.
If an automation genuinely needs to administer something, that is a different credential. Read what each grant can hold before you widen anything.
Capture the secret during setup
Plan the key, create it, then read it back. The plaintext secret is revealed once, during that protected setup, and never again.
Copy it straight into your credential store. Do not paste it into a terminal, a ticket, a chat message or a file you intend to delete later.
If the secret is lost, it cannot be recovered. Rotate the identity and take the new secret instead.
Rotate before you revoke
Rotation and revocation are separate acts, and the order matters.
- Create the replacement key on the same identity.
- Move the caller onto the new secret and confirm one real call succeeds.
- Read back the identity and check both keys are in the state you expect.
- Revoke the old key.
- Read back again, and check the events.
Doing this in reverse causes an outage you then have to fix under pressure.
Prove the revocation took effect
A revoke response tells you the request was accepted. It does not tell you the current state.
Read the identity back and confirm the key is revoked. Then make one deliberate call with the old secret and confirm it refuses on authority.
Finally, check the identity's events. The revocation should appear there with a time you recognize. If any of those three disagree, treat the key as live and escalate.
Confirm success
The new key works for its intended caller. The old key refuses. The events record both changes.
Nothing else in your account changed, because you rotated one identity rather than reissuing several.
If you suspect a key is compromised
Act in this order, and do not wait for certainty.
Revoke the affected key first. Then rotate the identity so the caller has a working secret again. Then read back every destination and spend rule that key could reach, and check its events and receipts for work you did not expect.
Never include the secret, a payload dump, a signed URL or bank details in a support message. Quote the receipt reference and the request_id instead; that is enough for support to help.