One makes security part of composition. A declaration can state what is needed; only governed later stages can authorize and enforce it.
Four distinct stages
- A requirement states the minimum capability and scope needed by a root.
- A policy decision approves, denies, narrows, or requires review for an exact subject and context.
- A grant authorizes an exact principal, binding, scope, effect class, and validity window.
- A runtime token is an attenuated, revocable delivery mechanism.
- Enforcement validates the token at the real host, resource, transport, or provider boundary.
No declaration, plan, artifact, receipt, or installed credential substitutes for another stage.
Least authority by construction
Per-root closure determines the maximum code, resources, data, effects, and permissions that can enter a deployable. Planning binds every requirement to an exact provider realization and proposed subject. Authority issues grants only after policy and evidence checks, and runtimes receive narrower tokens for the active operation or resource.
Delegation is explicit and attenuating. Revocation, expiry, audience, epoch, purpose, environment, and resource scope survive into enforcement and inspection. An adaptive provider receives separate member grants rather than one ambient union credential.
Effects have a lifecycle
An effect moves through intent, authorization, dispatch, acknowledgement, observation, and reconciliation. The journal records an operation identity, attempt, fence, idempotency class, and known outcome.
Irreversible, destructive, sensitive, externally visible, or broad-blast-radius
effects can require stronger review and evidence. A timeout after dispatch is
OutcomeUnknown, not permission to retry or fail over.
Identity and trust remain owner-qualified
Namespace authority owns declaration identities. Workload identity, principals, provider admission, source-language-tool trust, artifact provenance, signatures, attestations, approvals, and observations each retain their own issuer, subject, scope, freshness, and verification path.
Trust is never inferred from repository presence or first-party branding. A One-maintained provider passes the same public admission, selection, Build, grant, binding, and observation contracts as a third-party provider.
Secrets stay symbolic
Source and plans contain typed secret requirements and references, never secret values. Providers resolve them only at the selected runtime boundary under an exact grant. Secrets are redacted from diagnostics, artifacts, observations, histories, caches, and generated projections by contract.
Progressive assurance
The semantic model is identical from local development to production. The required assurance follows actual consequence. Pure local work can remain lightweight; production effects can require governed provider admission, artifact signing, workload identity, scoped approval, isolation, rollout, observation, retention, and recovery.
There is no global production bypass. An override is narrow, expiring, attributable, owner-qualified, and visible in the plan and causal history.
Example
Illustrative code receives only the selected attenuated capability:
pub async fn create(ctx: CreateShipment, request: ShipmentRequest) -> Result<Shipment> {
ctx.carrier().create(request).await
}
Follow Grant authority and deliver secrets. For CI and deployment workloads, follow Authenticate a workload with OIDC.
Canonical owner: Authority.