# Authority and trust

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

```mermaid
flowchart LR
    requirement[Requirement] --> policy[Policy decision]
    policy --> grant[Grant]
    grant --> token[Runtime token]
    token --> enforcement[Host enforcement]
```

- 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:

```rust,ignore
pub async fn create(ctx: CreateShipment, request: ShipmentRequest) -> Result<Shipment> {
    ctx.carrier().create(request).await
}
```

Follow [Grant authority and deliver secrets](/one/examples/authority-secrets).
For CI and deployment workloads, follow
[Authenticate a workload with OIDC](/one/examples/workload-identity).

Canonical owner:
[Authority](https://github.com/muijf/one/blob/main/systems/authority/AGENTS.md).