Trust Surface

Bearer Token Policy

`.agency` issues one long-lived bearer token per authenticated user for use in approved hosts, local tools, and background agents. The token is portable. The authorization is conditional.

Effective date: March 6, 2026

Core Rule

Each bearer token is personal to one authenticated user, governed by `.agency`, and continuously checked against current organization, legal, policy, and billing state. A valid token does not guarantee access unless the user and organization remain in good standing at the time of each request. Existing active bearer tokens are retained by default; replacement is an explicit regenerate action or a response to suspected compromise or misuse.

Control Model

  • One active bearer token per authenticated user
  • Long-lived token issued by .agency, not raw Auth0 access tokens
  • Retain the active token by default; rotation is explicit or compromise-driven
  • Immediate revoke and regenerate controls
  • Live checks for org membership, policy acceptance, contract status, billing status, and service entitlement
  • Opaque token format with protected server-side storage
  • Audit logs for issuance, regeneration, revocation, and request-time authorization

Prohibited Use

  • Shared team tokens
  • Public repositories or uncontrolled environments
  • Bypassing contract, payment, or policy requirements
  • Continued use after suspected exposure

User Responsibilities

  • Do not share the token with another person or team.
  • Store the token in a secure secret manager or equivalent controlled environment.
  • Regenerate or revoke the token immediately if compromise is suspected.
  • Expect access to stop if the user or organization is no longer in good standing.
  • Understand that regeneration invalidates the prior token immediately.

Termination and Enforcement

`.agency` may revoke or suspend bearer-token access immediately where compromise, misuse, billing delinquency, contract failure, policy violation, or other legal, operational, or security risk is detected. Revocation terminates token usability at once. Regeneration replaces the prior token with no overlap unless CREATE SOMETHING explicitly provides a managed transition mechanism.