What is TrustPlane Auth?

TrustPlane Auth is proof-bound machine authorization for APIs, gateways, clusters, clouds, and agentic runtimes — the enforcement plane of the TrustPlane platform, whose operating model is “control centrally, enforce locally”. Instead of letting a caller present a shared secret, it requires the caller to prove — cryptographically, per request — that it created this exact request, for this route, at this time, under the trust policy you configured. A verifier checks that proof locally, before the request ever reaches your API.

SPIFFE authenticates workloads. TrustPlane Passport authenticates requests.

The problem: machines still log in like it’s 2010

Most machine-to-machine and API traffic is still authenticated with a long-lived shared secret: an API key, a static bearer token, a password in an environment variable. That model has three deep problems:

1. It is a bearer secret. Whoever holds the string is the client. Copy the key, and you are the client — from anywhere, forever, until someone rotates it.
2. It is not bound to the request. An API key that can read /orders can also be replayed against /admin/delete-everything if the server forgets to check. The key proves who, never what this specific request is allowed to do.
3. It leaks quietly. Keys end up in git history, CI logs, screenshots, and chat messages. You usually find out after the breach, from the audit log.

AI agents and automated workflows make all three worse: there are now thousands of non-human callers, created and destroyed constantly, each needing access to APIs.

flowchart LR
  subgraph Old["The old way: long-lived bearer secret"]
    A["Caller"] -->|"x-api-key: static-api-key (forever)"| B["API"]
  end
  A -. "secret leaks" .-> X["Attacker replays copied key<br/>from anywhere, any request"]
  X --> B

The idea: prove the request, don’t present a secret

TrustPlane Auth flips the model. Instead of presenting a secret, a caller proves a request:

• The caller already has a workload identity (from SPIFFE/SPIRE, an OIDC/JWT issuer, or a local TrustPlane issuer).
• It gets a TrustPlane Passport: a short-lived, audience-scoped authorization artifact derived from that identity. Not a forever-token.
• For each call, it attaches proof that this exact request (method, path, body, time) was made by the holder of the passport’s key — a transcript-v1 request binding.
• A verifier (a sidecar adapter, a gateway, or library middleware) checks all of that locally, with no mandatory phone-home, and only then lets the request through.

flowchart LR
  subgraph New["The TrustPlane way: proof-bound request"]
    C["Caller<br/>(has workload identity)"] -->|"short-lived passport<br/>+ proof bound to THIS request"| V["Verifier / Adapter"]
    V -->|"verified request only"| API["Protected API"]
  end
  C -. "passport leaks" .-> Y["Attacker cannot reuse it:<br/>expired, wrong audience,<br/>wrong request, already consumed"]
  Y -.->|denied| V

A stolen passport is nearly worthless: it expires in seconds, it is scoped to one audience, it is bound to one request shape, and once it is used its jti is consumed so it cannot be replayed.

What proof-bound authorization gives you

Property	API key	TrustPlane Passport + proof
Lifetime	Long-lived	Short-lived (seconds–minutes)
Scope	Often broad	Audience + route + source-rule scoped
Bound to the request	No	Yes (method/path/body/time via transcript-v1)
Replayable if stolen	Yes	No (audience + expiry + atomic replay consume)
Verifiable offline	N/A	Yes (local trust bundle)
Adds a new client	Often a code/secret change	Publish trust material — no app/adapter redeploy

Where it sits

The TrustPlane Auth adapter sits in front of an API, gateway, or upstream service. The upstream application keeps owning its normal business authorization and RBAC decisions. TrustPlane Auth answers the earlier question: should this machine request reach the upstream at all?

flowchart LR
  C["Caller"] --> I["CLI, broker, or issuer path"]
  I --> H["Signed TrustPlane headers"]
  H --> A["Adapter in front of API"]
  A --> U["Upstream API"]
  U --> B["Business authorization"]

The caller uses a CLI, broker, or issuer path to create signed TrustPlane headers. Those headers bind the proof to the request instead of sending a reusable shared secret. The adapter verifies that proof locally before forwarding the request.

What the adapter verifies

For each protected request, the adapter verifies:

• Trusted issuer or public key: the request was signed by a source the adapter trusts.
• Request binding: the proof matches the actual method, path, body hash, audience, route, nonce, time window, and allowed headers.
• Route policy: the source is allowed to call this route under the current policy.
• Replay: the same proof cannot be accepted twice.
• Source and trust-anchor policy: issuer, key, subject, signer class, freshness, and source rules match the configured trust policy.
• Optional SPIFFE-backed attested workload: where deployed, the broker path can use same-cluster SPIFFE/SPIRE identity for workload-backed issuance.

All of that is local verifier work. TrustPlane Control — the governance plane of the TrustPlane platform, designed to be used alongside Auth for fleet governance — is never a hot-path dependency for request verification. See the adoption path for how that fits together.

Fit it into an existing gateway setup

TrustPlane Auth can protect an API directly through the adapter. Existing gateways such as Envoy, NGINX, and Kong are relevant integration targets, but they are not required for the core verifier model.

Gateway-specific templates can make adoption faster once the core adapter path is clear. Audit legacy gateway templates before reuse; do not copy them blindly. See Gateway integration patterns for the current adapter-routing model.

Three ways to adopt it

TrustPlane Auth meets you where your code already is:

1. Brownfield adapter — drop a reverse-proxy verifier in front of an existing API. The upstream code does not change. This is the “adapter wedge.”
2. Library middleware — verify inside your own Go HTTP service with pkg/middleware/http.
3. Broker + sidecar — a local broker issues request-bound passports for callers, and (on Kubernetes) can require SPIFFE/SPIRE attested_workload identity.

What you can run today

TrustPlane Auth is free to use. The current release includes everything you need to put the proof-bound model in front of a real API:

• The TrustPlane Auth CLI, with checksum-verified downloads.
• Proof-bound request signing.
• The adapter image.
• A Helm chart.
• Go, TypeScript (Node.js-only), and Python SDK packages for caller-side proof-bound request signing — pin the exact versions (v0.2.2 for Go, 0.2.2 for TypeScript, 0.2.2 for Python).
• Signed bundles.
• Software/JWKS and OIDC/JWKS source policy.
• A supported same-cluster SPIFFE/SPIRE broker path (broker built from source or run via the local demo; a published broker container image is not part of the current release).
• Cross-organization examples documented through source policy and route policy.

Some pieces are documented patterns, delivered by Control, or planned:

• Cross-cluster SPIFFE federation is documented as a pattern; a turnkey flow is not currently supported.
• Managed enrollment, revocation, governance, and audit workflows are delivered by TrustPlane Control, the managed governance plane — the Control Guide documents its console, and Availability and product boundaries lists its current limitations.
• An n8n node, MCP, and LangChain/OpenAI/Anthropic integrations are planned adoption lanes; not currently supported.
• OAuth and backend egress token exchange are planned compatibility bridges; not currently supported.

TrustPlane Auth is useful on its own: it protects an API boundary with local verification, signed trust material, route policy, replay protection, and proof-bound requests.

What it is not

TrustPlane Auth is deliberately small and honest about its edges. It is not a service mesh, not a CA replacement, not an OAuth replacement, not a payment network or marketplace. There is no hosted account, database, or managed bundle distribution required to run it. It works locally and offline. Auth is also not the whole TrustPlane platform: governing machine access at fleet scale — enrollment, policy releases, revocation, fleet visibility, audit, operator access — is the job of TrustPlane Control, the governance plane designed to be used with Auth.

Accuracy

Commands, fields, and reason codes in these docs match shipped behavior rather than invented examples.

Next steps

• Build the vocabulary: Concepts
• Follow one request through the system: How it works
• Get the verified artifacts: Install
• Run the local proof-bound request flow: Quickstart