Bootstrap Trust

ACGP v1.0 alpha standardizes governance semantics, not full deployment trust federation. This guide defines the repo-shipped minimum trust/bootstrap profile for serious deployments.

For the conceptual boundary model behind this guide, see Protocol Boundaries.

Zero-to-one bootstrap is now shipped. The remaining work starts when deployments need federation, external identity systems, or stronger assurances around local fast-path execution.

What This Guide Covers

Use this guide to answer the operational question the protocol does not answer for you: how does a fresh deployment decide which steward to trust?

The minimum repo-shipped answer is:

  • choose one steward trust root
  • bind that trust root to one steward service identity
  • distribute that root to calling runtimes before production traffic begins
  • verify local fast-path behavior with sampling or remote checks
  • document who can override ARS and steward trust decisions

Machine-Readable Artifacts

The minimum trust profile ships with concrete artifacts:

  • trust-root schema: schemas/steward-trust-root.schema.json
  • trust-root example: examples/trust/steward-trust-root.json
  • planned rotation example: examples/trust/steward-rotation.json
  • revocation example: examples/trust/steward-revocation.json
  • validation vectors: conformance/vectors/trust-bootstrap-vectors.json

Runtimes SHOULD validate the trust-root artifact before accepting signed governance responses.

Trust-Root Artifact Format

The steward trust root is the minimum bootstrap artifact. It defines:

  • steward ID and monotonic trust-root version
  • environment and optional scope binding
  • validity window
  • allowed service identities and required signing identity binding
  • steward signing keys and key lifecycle state
  • rotation metadata, including steward replacement when necessary
  • revocation metadata and cache lifetime

If transport identity and signing identity are not identical, the mapping MUST appear explicitly in service_identities.

Steward Trust Root Configuration

Serious alpha deployments SHOULD start with one explicit steward trust root per environment.

Minimum expectations:

  • assign one production steward authority for each environment
  • publish the steward trust root through configuration management, not ad hoc runtime discovery
  • version trust roots so clients can rotate predictably
  • keep dev, staging, and production trust roots separate

Accepted implementation patterns include:

  • a pinned internal CA certificate for mTLS
  • a pinned public key or signing certificate for the steward service
  • a service-mesh identity root distributed through platform configuration

Steward Signing Identity Expectations

The steward identity used for transport authentication and the identity used for signed governance artifacts SHOULD be operationally linked.

Minimum expectations:

  • the evaluator service presents an authenticated service identity
  • the signing key used for governance artifacts is documented and versioned
  • clients know which kid values or certificates are expected for the steward they trust
  • key rotation and revocation follow the shipped artifact workflow in this guide

Do not rely on self-asserted sender_id or agent_id values alone as the trust anchor.

ACGP core semantics now treat agent_id as the runtime- or operator-assigned identifier of the governed agent principal. That semantic clarification does not change this guidance: agent_id alone is still not a sufficient deployment trust anchor without transport, signing, and operator/runtime validation.

Production Trust-Binding Flow

  1. Transport authenticates the calling service.
  2. The Steward validates that service identity against the configured trust root.
  3. The expected signing identity is checked against the trust-root authorization set.
  4. sender_id is accepted as an application-layer field, not as the trust anchor by itself.
  5. Governance overrides are accepted only from explicitly authorized service identities.

In production deployments, a self-asserted sender_id without authenticated service identity is not sufficient trust proof.

Deployment Bootstrap Checklist

Before accepting production traffic:

  1. Provision the steward service for the target environment.
  2. Generate or assign the steward trust root and signing identity.
  3. Distribute trust material to all calling runtimes.
  4. Pin or otherwise authorize the steward identity at the ingress or client layer.
  5. Validate that the active blueprint source and steward identity are the expected pair.
  6. Validate the trust-root artifact against schemas/steward-trust-root.schema.json.
  7. Exercise health, metrics, and one signed governance response in staging.
  8. Record the bootstrap event in the deployment audit trail.

When The Minimum Profile Is Enough

The repo-shipped minimum profile is enough when:

  • one evaluator service per environment is operationally acceptable
  • one pinned steward trust root per environment fits your trust model
  • transport identity and signing identity can be linked and distributed through configuration management
  • Tier-0 approvals can be sampled or remotely verified instead of treated as final authority

When You Need More Than The Minimum Profile

Add deployment-specific controls beyond this guide when:

  • multiple organizations or external identity domains must trust the same steward path
  • trust roots must be discovered or rotated automatically across many runtimes
  • hardware-backed attestation or independent ARS verification is required
  • Tier-0 bypass risk is unacceptable without stronger remote enforcement or disablement

Rotation Procedure

Use the planned rotation path for scheduled key turnover:

  1. Publish a new trust root with incremented version and rotation.previous_version set to the currently trusted version.
  2. Add the new active signing key and mark the prior key as retiring or reference it via replaces_key_id.
  3. Distribute the new trust root before rotation.effective_at.
  4. Refresh runtime caches within revocation.cache_max_age_seconds.
  5. Remove the prior key only after the grace period expires.

Revocation Procedure

Use the emergency path when a signing key or steward instance is compromised:

  1. Add the compromised key to revocation.revoked_key_ids and set the key status to revoked.
  2. Publish a replacement trust root with rotation.reason = emergency_revocation.
  3. Invalidate runtime caches immediately and force refresh.
  4. Disable acceptance of signatures from the revoked kid.
  5. Record the event as a security incident with rollback and recovery notes.

Emergency Steward Replacement

If the steward service itself must be replaced:

  1. Publish a new trust root with a new steward_id.
  2. Set rotation.reason = steward_replacement and rotation.previous_steward_id to the retired steward.
  3. Require runtimes to reject the old steward after the transition window.
  4. Re-run staging validation before restoring production traffic.

Local Fast-Path Sampling and Verification Guidance

Tier-0 local evaluation remains the most exposed trust boundary in alpha because the local runtime can be compromised independently of the steward.

Minimum expectations when Tier-0 fast path is enabled:

  • sample a subset of locally approved actions for remote steward verification
  • force remote verification for higher Governance Tiers or higher-value actions
  • log sampling outcomes and mismatches to the audit pipeline
  • disable fast path entirely in environments that cannot tolerate unsigned local decisions
  • log at least trace ID, action, governance tier, local decision, and sampling outcome for every sampled Tier-0 approval
  • provide an operator control to disable Tier-0 fast path in higher-risk environments

For serious alpha deployments, treat local fast-path approval as a latency optimization, not as an authority root.

ARS Override and Governance Guidance

The protocol does not define who is allowed to override ARS or Governance Tier assignments. Deployments MUST define that authority explicitly.

Minimum expectations:

  • specify which operator role can raise a Governance Tier
  • require documented justification for manual ARS overrides
  • record steward replacement, trust-root replacement, and emergency restrictions as audited security events
  • prefer tighter runtime posture over relaxed posture when trust is uncertain
  • require steward-side review for suspicious or missing ARS evidence
  • define an incident response path for missing or suppressed Tier-0 traces

Operator Responsibilities Outside Protocol Core

Operators remain responsible for deployment trust guarantees that ACGP does not standardize in alpha.

This includes:

  • identity provider integration
  • certificate issuance and revocation
  • key management and rotation
  • secure distribution of trust roots
  • incident response for steward compromise
  • platform-level enforcement such as mTLS, RBAC, and network segmentation

Practical Alpha Profile

If you need one concrete minimum answer for a serious alpha deployment, use this:

  • one evaluator service per environment
  • one pinned steward trust root per environment
  • one documented steward signing identity per environment
  • one audited bootstrap event when trust material changes
  • remote sampling for local Tier-0 approvals
  • operator-only ARS tightening and emergency override authority

That is enough to make the alpha trust boundary operationalized instead of merely advisory.