Skip to content

Agent Credential Provisioning

Deterministic setup for new agent credentials. Executes SPB-02, SPB-04, SPB-05, SPB-07, SPB-12.

Prerequisites

  • A documented purpose for the credential.
  • A specified runtime (local, home_lab, cloud).
  • A draft scope (minimum allowed actions/resources).
  • The user-only secret store will not be the source of this credential.

Request

Open a request entry (issue, PR, or runbook ticket) with:

  • requester
  • purpose
  • agent or integration label
  • runtime
  • proposed scope
  • expected lifespan (default 90 days max — SPB-05)
  • audit emission strategy (which actions log to what, SPB-12)

Approval

Security owner reviews against this checklist:

  • Scope is minimum sufficient (deny by default elsewhere) — SPB-04.
  • Runtime matches data classification — SPB-10.
  • No reuse of user credentials — SPB-02.
  • No path through user-only secret store — SPB-03.
  • Rotation plan attached — SPB-08.
  • Audit events specified — SPB-12.

If any box is unchecked: send back with required changes.

Issuance

  1. Mint the credential at the issuer (e.g., AnyType API Key, GitHub fine-grained PAT, cloud IAM role).
  2. Apply scope exactly as approved.
  3. Tag the credential with the agent/integration label.
  4. Inject into the runtime by approved method:
  5. local: env var bound to the user's keychain → exposed only to the labeled agent's process.
  6. home_lab: secret manager (e.g., Vault) → injected at process start.
  7. cloud: cloud secret manager → mounted at runtime; never written to repo or logs.
  8. Verify integration works on the new credential.
  9. Audit event: key_issued with label, scope, runtime, expires_at.

Verification

  • Hit one allowed endpoint to confirm read.
  • Hit one disallowed endpoint to confirm deny.
  • Both results captured in audit.

Rollback

  • If issuance breaks the integration: revoke the new credential, do not fall back to a wider-scoped credential, and reopen the request with corrected scope.