Skip to main content

What TrustPlane Auth Protects

TrustPlane Auth protects APIs by verifying cryptographic proof on each request. It is built for machine-to-machine calls: services, agents, workflows, brokers, and other non-human callers that need to reach APIs without sending a shared API key over the wire.

The core move is simple: replace "whoever has this shared string may call the API" with "this caller can prove it created this exact request, for this route, at this time, under this trust policy."

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?

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.

Brownfield Gateway Fit​

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. Legacy gateway templates should be audited before reuse; do not copy them blindly. See Gateway integration patterns for the current adapter-routing model.

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. Control is future governance and fleet management; it is not a hot-path dependency for request verification.

What Is Ready In v0.1.0-rc.1​

The private-preview release candidate includes the pieces needed to try and evaluate the Auth story today:

  • CLI downloads with SHA256 verification.
  • Proof-bound request signing.
  • Adapter image.
  • Broker image.
  • Helm chart.
  • Signed bundles.
  • Software/JWKS and OIDC/JWKS source policy.
  • Same-cluster SPIFFE/SPIRE broker path proven.
  • Cross-organization examples documented through source policy and route policy.

Start with First 15 Minutes for the verified download path, then use Quickstart to run the local proof-bound request flow.

What Is Preview Or Future​

These parts are intentionally scoped as preview or future work:

  • TrustPlane Auth v0.1.0-rc.1 artifacts are available for evaluation. You can try them in front of your own API endpoints. During preview, source repo access, support expectations, and release cadence are managed by the TrustPlane maintainers.
  • Cross-cluster SPIFFE federation is documented as a pattern, but it is not turnkey yet.
  • Control-managed enrollment, revocation feeds, governance, and audit workflows are future Control work.
  • SDKs, an n8n node, MCP, and LangChain/OpenAI/Anthropic integrations are future adoption lanes.
  • OAuth and backend egress token exchange are future compatibility work.
  • Broad availability language should not be used for this release candidate.

TrustPlane Auth is useful without those future pieces: it can protect an API boundary with local verification, signed trust material, route policy, replay protection, and proof-bound requests.