Skip to main content

TrustPlane Auth

SPIFFE authenticates workloads. TrustPlane Passport authenticates requests.

TrustPlane Auth is an open-source auth plane for proof-bound machine authorization — across APIs, gateways, clusters, clouds, and agentic runtimes.

This site is a guided technical map. If you read it top to bottom you will understand what problem TrustPlane Auth solves, the theory behind it, every capability it ships today, and how to run it locally or as an adapter in front of a real API.

No prior knowledge of SPIFFE, JWTs, or Kubernetes is assumed. The docs build those ideas up as they go, while keeping the security properties precise.

The problem: machines still log in like it's 2010​

Most machine-to-machine (M2M) 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.

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

TrustPlane 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.

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" gives you​

PropertyAPI keyTrustPlane Passport + proof
LifetimeLong-livedShort-lived (seconds–minutes)
ScopeOften broadAudience + route + source-rule scoped
Bound to the requestNoYes (method/path/body/time via transcript-v1)
Replayable if stolenYesNo (audience + expiry + atomic replay consume)
Verifiable offlineN/AYes (local trust bundle)
Adds a new clientOften a code/secret changePublish trust material — no app/adapter redeploy

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

How to read these docs​

Accuracy posture

These docs track the TrustPlane Auth runtime and deployment artifacts. Commands, fields, and reason codes are documented to match shipped behavior rather than invented examples.