Registry and trust

When to read thisCopy Anchor Link

Read it when you need to judge whether the extension model is strict enough for your environment, when you plan to build providers that will eventually be installed under a governed process, or when you wonder how an agent that is missing a capability can obtain one without granting itself authority.

The four extension classesCopy Anchor Link

The manifest kind already fixes the ceiling of authority.

Governed install (designed)Copy Anchor Link

A capability provider is installed by a governed process owned by the runtime, not by copying a binary. The design has these steps, in order:

1. Verify signature and provenance. The package is checked against a keyless signature identity (an OIDC issuer plus subject). The signer_identity in the manifest must match the verified identity exactly on both parts, and the SBOM and provenance references must verify. A mismatch fails the install.
2. Recompute the digest. The host hashes the package content (with manifest.yaml excluded) and compares it with the declared digest. It pins the value it computed, never the declared one.
3. Compute the permission change. The host compares the new manifest with the locked one and derives the permissions delta itself. See widening rules.
4. Run the conformance suite in a sandbox. The conformance_suite named by each capability is looked up in the host's kit index and run by the host. It is a claim the host verifies, not one it takes on trust.
5. Evaluate policy. Widening always requires approval. A lower-trust tier is non-production by default.
6. Pin and record. The digest, content hashes and signer identity are written to the lockfile, and the install is recorded as evidence.

Versions are locked for the duration of a change. There is no dynamic installation during a run.

Parts of this are visible in the public protocol. The manifest comments define the install-time comparisons exactly (a rollback is a widening; a version equal to the locked one with a different digest is rejected; no lock entry means the whole manifest is a widening). The install itself, the lockfile writer and the approval workflow are not in the public tree.

Digest-pinned, signed, permission-declaredCopy Anchor Link

The three properties are enforced at different points:

Permission widening re-approvalCopy Anchor Link

An upgrade that adds a capability, a credential intent, a network destination, an environment or a writable path, that lowers a risk floor or removes declared evidence, or that raises timeouts or budgets, is a widening. The same holds for a changed signer or a rollback to a lower version. A widening cannot install on policy alone: a human approval is required, and what the approver sees is the delta the host recomputed from the lock, not the delta the publisher wrote. A narrowing needs no new approval.

This is the practical meaning of "agents cannot widen grants": a plugin cannot enlarge its own authority by shipping a new version, and an agent cannot cause a plugin to be installed that its policy would not approve.

Trust tiers (designed)Copy Anchor Link

Distribution is designed around tiers that decide how much a registry vouches for an extension and what conformance evidence exists for it.

Revocation is intended to be a signed index update after which the runner refuses a revoked digest. Badges are scoped and expire. Tiers do not change what a manifest declares or what the host enforces; they change what must be reviewed before install and whether the result may run in production by default.

These three modes of conformance correspond to the kit modes on the Conformance page.

Capability-gap bounded provider synthesis (designed)Copy Anchor Link

Sometimes a change needs a capability no installed provider offers: an internal API, an in-house tool. Stopping for a person to write a plugin caps throughput at the engineer the system is meant to free. Letting the agent write and use its own tool defeats the trust model. The design resolves this with a bounded, approved path:

1. The orchestrator opens a child build workflow for the missing capability, inspecting the internal API or documentation that discovery or knowledge found.
2. A provider is generated from the SDK template, with a manifest, declared permissions, conformance tests and security tests.
3. It is built with an SBOM and provenance, and signed.
4. Behavior tests run in a sandbox with canaries.
5. A named human approves the new authority, meaning the exact permission set the manifest declares.
6. Only then is the provider published to the private tier, and the parent change resumes pinned to the exact digest.

The synthesis may add capabilities outside the trust kernel. It may never modify policy evaluation, the credential broker, evidence integrity, plugin verification, sandbox enforcement, approval flow or the circuit breaker, and a protected list makes those unreachable as a build target. The synthesized provider is an ordinary extension from then on: pinned, signed, declared, conformance-run and widening-reviewed like any other. The agent does not approve itself, and the generated plugin does not receive standing authority from having been generated.

What a reader can verify todayCopy Anchor Link

Without any registry, you can check the contract that a registry would rely on:

• manifest.proto states each install-time rule in its field comments.
• The sample and official providers build manifests whose digest is the real sha256 of their executable, and say plainly that their SBOM and provenance references are placeholders that install would refuse.
• The kits show what a conformance suite looks like. See Conformance.

Failure modes and safeguardsCopy Anchor Link

Next stepsCopy Anchor Link