Credentials and recovery

Store a provider credential at the handoff, keep it out of transcripts, and recover it through the provider.

The broker proves identity and records that a signup happened. It does not hold provider credentials, and it cannot recover one. That single boundary decides everything on this page.

What the broker does not keep

No provider API keys, tokens or passwords.
No provider resource inventory.
No ability to exchange a signup_token for a credential.

The signup_token is a signed proof that the provider created or resolved an account for this agent under this acceptance. It is not a credential, and it is not a bearer token for the provider's API.

The broker records the proof row, the accepted terms, the account reference and the context pointer. That is the whole handoff.

Store it at the handoff

The moment a signup response contains a credential is the moment to store it. The identity_record_signup result says so explicitly, on every path:

{
  "handoff": {
    "broker_stores_credentials": false,
    "store_credentials_now": true,
    "recovery": "provider-owned",
    "context_url": "https://skdl.dev/docs/SKILL.md",
    "note": "Persist any provider credential in a secure store before redacting, summarizing, or ending the task. The Broker never stores provider credentials. If a credential is lost, use the provider's recovery path (see its guide); do not re-run signup to recover it."
  }
}

A reasonable store is a secret manager, a password manager entry, or the runtime secret store the agent's job already uses. What matters is that it survives the conversation.

The transcript is not storage. Neither is the inbox, the ledger, a chat summary, a task log or a code comment. If a credential appears in any of those, treat it as exposed.

Order of operations: store first, then redact, summarise or end the task. Redacting before storing is the failure mode that started this rule.

A repeated signup for an existing account resolves it. A resolve returns resolution: "resolved" and no credential, by design: credentials are show-once. So re-running signup cannot recover a key, and looping on it only adds noise to the provider's logs.

The provider's guide is the recovery path. For VaporCloud, guide version 1.3.0 documents key rotation:

export ASSERTION_JWT="<a fresh assertion.jwt for audience vaporcloud>"
curl -sS -X POST https://skdl.dev/api/account/rotate-key \
  -H "Authorization: Bearer $ASSERTION_JWT"

{
  "account_id": "7b0c9e2a-4f1d-4c8a-9e37-2d5b6a1c8f04",
  "vapor_api_key": "vc_live_<32 hex>",
  "rotated_at": "2026-10-21T18:20:00.000Z"
}

Three details from the guide: the call needs a fresh assertion for aud: "vaporcloud" and no vendor API key or extra scope; the previous key is invalidated immediately and never returned; the call is safe to retry, and only the newest key works.

To get that assertion, call identity_prove again with the same audience, terms URL, hash and text. The acceptance is reused and no new ledger mail is sent; the broker returns an unexpired assertion for the rotation call. Then rotate, and store the new key before you do anything else.

When there is no recovery path

Not every provider documents rotation. If the guide has no recovery section:

Stop. Do not re-run signup.
Check the provider's dashboard or account settings for a key reset, using the account reference from the receipt.
Ask the human owner to act in the provider's UI, since the account is attributed to them.
Contact the provider's support or security contact, which the discovery document or the guide should name.
If the provider has no path at all, the credential is gone. The account still exists and the human is still accountable for it; plan to replace the integration or the account deliberately, not by looping signup.

Rotation and revocation

Rotate a provider credential when it may have leaked, when the agent is being retired, or on the provider's schedule. Rotation happens at the provider, with the provider's endpoint or dashboard.

Revoking the agent in the broker does not rotate anything at the provider. Revocation stops new assertions and further identity and inbox calls; it does not touch credentials the agent already stored or accounts it already created. If you revoke because of a suspected compromise, rotate the provider credentials as a separate step, then review the ledger and inbox for unexpected activity.

What the human should know

The human owner is accountable for the account the agent created, and can read the agent's inbox. Tell them, in plain terms: which provider, which account reference, where the credential is stored, and what the recovery path is. Do not send the credential itself through the inbox or the transcript.

First signup shows the handoff in context.
ToS and ledger covers the record that remains after the credential is gone.
Trust and limits explains why the broker does not hold credentials.