Skip to content

Current and future scope

TrustPlane Auth is a customer-side runtime for proof-bound machine authorization. This page is the canonical support matrix for what is available today and what is planned. Use it when another page needs exact status.

Area Current status
CLI downloads Available: current release v0.2.4 archives from the public downloads mirror. Verify SHA256SUMS before running.
Adapter image Available as ghcr.io/trustplane-dev/trustplane-auth-adapter (public). Current tag v0.2.2; pin the tag plus its digest from the package page.
Broker image Not published in the current release. The broker runs from source builds (make build) and the local demo.
Helm chart Available as the trustplane-auth chart package (public on GHCR). Pin chart version 0.2.2 and digest-pinned images.
Local passport issuance and verification Supported by the TrustPlane Auth runtime and CLI.
transcript-v1 request binding Supported for proof-bound request signing and verifier rebuild.
Replay consume-on-accept Supported, including Redis-backed shared replay state.
Route/source policy Supported through allowed sources, signer-class policy, provenance/context hooks, and bundle freshness.
Brownfield adapter Supported in front of an existing upstream API.
Local broker Supported for request-bound passport issuance.
Same-cluster SPIFFE/SPIRE broker path Supported when deployed and configured for the documented attested_workload profile.
Software/JWKS and OIDC/JWKS-style sources Supported as software-class source policy acceptance.
Signed trust material and policy bundles Supported for local bundle build, merge, removal, signing, verification, and refresh workflows.
Control-signed bundle file consume Supported with the current adapter image (v0.2.2; requires v0.1.0-rc.2 or later). Auth consumes mounted signed files locally and does not depend on Control service availability at request time.
Local acceptance gate Supported through make v01-acceptance.
Conformance vectors Available for transcript, passport, signer taxonomy, bundle/source, broker IPC, and SDK/client/broker compatibility checks. Planned MCP, n8n, and workflow-agent integrations must pass the same baseline before being cited as available.
Go SDK Public module for caller-side proof-bound request signing — pin github.com/trustplane-dev/trustplane-auth-sdk-go@v0.2.2.
TypeScript SDK Node.js-only public package for caller-side proof-bound request signing — pin @trustplane/auth-sdk@0.2.2.
Python SDK Available for caller-side proof-bound request signing: python -m pip install trustplane-auth-sdk==0.2.2, import module trustplane_auth. Caller-side signing only — no enrollment or Control API support. See Python SDK.
Control Trust Anchor enrollment (trustplane enroll) Available in CLI v0.2.1 and later (current release v0.2.2): OIDC JWKS trust-anchor sources verify external workload identity at enrollment time (e.g. Kubernetes projected ServiceAccount tokens on EKS) and issue a derived client key inheriting an existing client’s protected-resource policy. The 0.2.2 SDKs also support TA-G1 public auto-enrollment from caller code. See OIDC JWKS enrollment runbook.
  • Backend-facing JWT/JWKS assertion tier (backend_jwt).
  • OAuth compatibility egress (oauth_compat_egress) for selected third-party providers.
  • OAuth exchange flows, introspection, DPoP, HTTP Message Signatures, and discovery endpoints as runtime bridges.
  • MCP or workflow integration packages.
  • Hosted Control governance, managed bundle distribution, hosted revocation, tenant registry, approval workflow, RBAC, and audit UI.

TrustPlane Auth can protect APIs without a hosted service. Auth is the free-to-use enforcement plane of the TrustPlane platform. TrustPlane Control is the governance plane and the enterprise offering, delivered as managed SaaS: fleet governance for teams that need managed signing, distribution, revocation, audit evidence, approvals, policy history, and status across many Auth deployments. TrustPlane Edge is the self-hosted deployment of Control, with advanced, tailored capabilities. Auth and Control are two distinct components designed to be used together, and Control is never a hot-path dependency for request verification.

For client and integration authors, start with the SDK contract and conformance vectors before building SDK or workflow surfaces.