Protect your first API

The adapter accepts a proof-bound request only after verifying the passport, request binding, route/source policy, bundle freshness, and replay state. It then forwards the request to the configured upstream. Your application does not need to implement TrustPlane verification.

First, run a complete local request

Run the first local protected request with the released, checksum-verified CLI. Its maintained fixture creates the broker, Auth adapter, and synthetic upstream for you and checks an unsigned denial, signed allow, replay denial, and changed-path denial. The output shows which request reached the upstream. This step needs no Control account or Kubernetes cluster.

Then plan your own upstream

The local fixture’s trustplane up process uses its own loopback upstream. It does not reconfigure your service. To protect an existing HTTP API, review these inputs before deployment:

Input	What to verify
Upstream	A private endpoint reachable by the adapter, with no direct public bypass.
Protected operation	Exact method and path, route ID, audience, authority, and allowed source.
Trust and policy	Reviewed, signed public-key material and route policy; no private key in a mounted public bundle.
Replay	One replica with durable local storage, or shared replay state for multiple replicas.
Freshness	The route’s freshness class and the signed bundle or managed offline lease deadline.
Network	Inbound TLS to Auth, bounded egress to DNS/Control/upstream, and a private upstream boundary.

For provider-neutral chart shape, read Helm chart. For a Control-governed installation, use the managed Auth Site guide, which includes ownership, target registration, trust-root delivery, and exact activation checks. The isolated managed-site verification is documented in the linked chapters. Validate your own release matrix, target activation and private upstream before serving customer traffic.

When your site is active, send one unsigned request and one short-lived signed request through Auth. Check the exact runtime decision and upstream outcome. For a managed site, also correlate the request ID in Control Audit. A 403 by itself does not establish which verification check ran.