Cross-cluster and n8n

The practical v0.1 story is simple: an external automation runner can be accepted as a configured trusted source. That runner might be in another Kubernetes cluster, an EKS-hosted workflow system, or an n8n worker that needs to call Acme's Orders API.

In v0.1.0-rc.1, this is software/JWKS-style policy acceptance unless SPIFFE federation is explicitly deployed and configured. There is no Control Plane auto-enrollment path in v0.1.

Current flow

Acme adds the automation source to the route policy:

{
  "issuer": "https://issuer.acme.example/automation-jwks",
  "trust_domain": "acme.example.automation",
  "subject_exact": "system:serviceaccount:n8n:n8n-runner",
  "required_key_binding": "software"
}

The automation runner signs GET /orders; the adapter verifies the signature, request binding, audience, route, replay, freshness, and source rule.

What is live today

Scenario	Current posture
External n8n runner with a configured signing key	Supported as software/JWKS-style acceptance
Another Kubernetes cluster without SPIFFE federation	Supported as software/JWKS-style acceptance
EKS-hosted automation	Supported as software/JWKS-style acceptance
Cross-cluster SPIFFE federation	Future unless you explicitly deploy and operate federation
Control-managed trust anchor enrollment	Future

Why this still matters

This removes the static bearer token from the automation workflow. The external runner does not hold an API key for Orders. It signs each request, and the proof is bound to method, path, audience, route, body hash, and replay state.

The upstream still owns business authorization. TrustPlane Auth does not decide which customer, tenant, invoice, or order the workflow may access after the request is verified.

Future path

TrustPlane Control is future governance for managing many Auth deployments. It is not a hot-path dependency for each request. The future cross-organization path can include:

• Control-managed trust anchor enrollment
• OIDC/JWKS source onboarding
• SPIFFE federation where both sides deploy it intentionally
• revocation feeds
• audit and governance workflows

Those features improve lifecycle management. They do not change the core request-time rule: the adapter must be able to verify the caller, proof, and route policy locally.