Skip to main content
Version: MVP

ADR 0007 · Credential and identity architecture

4 min readAcceptedRecorded 2026-05-09

What this ADR decides

That Craik treats credentials and operator identity as first-class governance inputs. Typed AuthProfile records carry credential identity, OIDC carries operator identity, and every provider receipt binds both dimensions.

Governance thesis.

Every action is authorized by a credential. Every credential is authorized by an operator. Every authorization graph is itself receipted.

Context

Provider credentials and operator identity are governance inputs, not incidental plumbing. Craik receipts need to answer which human authorized work, which credential carried the provider call, which policy allowed it, and which authorization grant made the credential usable. Reconstructing those answers from environment variables or local shell state would be fragile and would not survive handoffs, audits, or future multi-agent coordination.

Decision

Credential identity

Typed AuthProfile

Unit of credential identity. ID shape <provider_family>:<name>.

CredentialSource protocol

Resolves request headers at call time.

Env-var API keys

Local-CLI OAuth fallback

Vendor CLI bridge

External secret references

Stigmem-backed references

Marker identity

For no-secret local providers.

Operator identity

Mechanism
Use case
Notes
OIDC device-code flow
headless / remote
Persistent operator session.
OIDC loopback + PKCE
browser-capable entrypoints
Standard browser redirect.
Workload identity providers
CI / cloud
No long-lived provider secrets.
RFC 8693 token exchange
federation
Brokered credentials.

Identity on every receipt

Provider receipts carry both dimensions:

auth_profile_id

auth_kind

auth_identity_hash

operator_subject

operator_issuer

operator_email

operator_groups

Policy constraints

Policy envelopes can constrain both dimensions:

required_operator

allowed_operator_groups

Required issuer

allowed_credential_kinds

allowed_credential_profiles

Approval-gated first live use.

First live use of a credential profile requires explicit operator approval. Operator-to-profile authorization grants are stored on the profile with a receipt chain so the authorization graph is queryable.

Consequences

Two-dimensional audit

Every provider receipt records the operator who drove the work and the credential identity that carried it.

Queryable identity

Operators can query all actions taken by a human or all actions carried by a credential identity without exposing raw credentials.

First-class authorization

Credential authorization becomes durable state instead of tribal knowledge.

Forward-compatible isolation

Future multi-agent runtime can isolate credentials and operators per agent without redesigning receipts.

Workload-identity ready

CI and cloud deployments can use workload identity and token exchange instead of storing long-lived secrets.

Tradeoff: setup surface

Users need to understand operator login, credential profiles, approval, and policy constraints before using live providers in governed mode.

Alternatives considered

Alternative
Disposition
Why rejected
SAML for operator identity
rejected for MVP
OIDC is more common for CLI, CI, and cloud-native auth flows.
Direct OIDC provider authentication
rejected
Major LLM providers do not currently accept arbitrary workload or operator OIDC tokens as provider credentials. Token exchange keeps the model extensible if providers add federation later.
Env-var-only credential resolution
rejected
Cannot represent Claude subscriber credentials, enterprise secret managers, team-shared Stigmem credentials, rotation, or per-profile authorization.
Static origin allowlists
rejected
Developer and CI environments often have dynamic origins, and origin checks do not answer which operator was authorized.

Retraction: none active.

Retract this ADR if Craik adopts a federated identity mesh that makes per-profile credential authorization and local operator sessions obsolete.

What's next