Authorization model

IMPLEMENTED in 0.4.0 (context-registry.v2). Workstation product concepts, not SEIF Protocol authority.

Principal classes

APPLICATION IDENTITY ≠ HUMAN IDENTITY. CONSUMER CAPABILITY ≠ RELEASE AUTHORITY. An application credential can never be configured to deploy: the class bound is checked when the identity is created and on every request.

Scope

Every principal belongs to one organization. Service identities are scoped to exactly one Project; application identities must also name the environments they may resolve in. Humans may optionally be scoped to Projects. Authorization checks, in order: the route's capability (router-level, before any handler work), then the Project and environment of the addressed object. Authorization precedes routing, so an out-of-scope caller cannot learn whether an environment has an active deployment. Cross-organization reads return 404 (the object does not exist for that tenant).

Lifecycle

POST /v1/service-identities creates an identity (no secret). POST …/credentials issues a credential: the bearer secret appears once in that response; the Registry stores its SHA-256 digest, a 4-character hint, creator, expiry and last use. At most two credentials are active per identity, so rotation is replace-in-one-step ({"replaces": "<credential id>"}) or overlap-then-revoke. …/revoke and …/disable take effect on the next request. Every step is audited. Credentials carry recognizable prefixes so the secret scanners in Builds, traces, provider responses and delivery audits refuse them.

Security invariants

• No route reachable by an application credential belongs to the access, development or delivery planes (tested over the route table).
• Approval (environment.approve) and break-glass are human-only. A human Admin cannot inject traces (trace.ingest is automation/runner only).
• Separation of duties (requireDistinctApprover) refuses an approval by the principal who registered the candidate, re-checked at promotion; break-glass under that policy needs a second administrator.
• Denied mutations by machine credentials are audited (access.denied, bounded per principal).
• Bearer secrets are never stored, logged, returned after issuance or written to traces.

<!-- BEGIN GENERATED: node scripts/authz-matrix.mjs -->

Capabilities by principal class and role

Service identity defaults

• application default: context.resolve, context.expand, context.report_consumption, context.report_outcome
• automation default: build.view, build.register, regression.run, environment.view, binding.view

Endpoint matrix

<!-- END GENERATED -->