Agentic workflows

Automation platforms and agentic runtimes are prolific API callers with a familiar weakness: they keep long-lived API keys in a credential store. TrustPlane Auth replaces that with per-request proof. An n8n worker, an EKS-hosted workflow system, or any external automation runner can be accepted as a configured trusted source — it signs each request it makes, and Acme’s adapter verifies that proof before the request reaches the Orders API.

In the current release, 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.

How an automation runner calls a protected API

flowchart LR
  N["n8n / external automation"] -->|"signed request"| A["Acme TrustPlane adapter"]
  A -->|"allowed by route policy"| O["Orders API"]
  A --> T["Trusted source<br/>issuer key + allowed_sources"]

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

If your runner lives in another Kubernetes cluster or trust domain, the broader story — including the future federation and governance path — is on Cross-cluster calls.

Why this matters for automation

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 — so a replayed webhook, a copied request, or a leaked workflow export does not grant access.

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.

Exposing signed requests to an agent (MCP)

An agent runtime needs no TrustPlane-specific code. A thin MCP server can expose the signing flow as tools the model calls in natural language:

• list granted routes — resolve the workload’s signing profiles and return the method+path grants, so the agent knows what it may call;
• signed request — for a chosen method+path, sign the request under that route’s signing profile and send it; a request to a route the key is not granted fails closed.

The signing coordinates (kid, route id, audience, issuer, subject, trust domain) come per-route from the resolve response, so one server is upstream-agnostic — it signs whatever routes the key is granted, to whatever host the profile names. The agent never holds an API key; each tool call signs one request under a short-lived key, so turning the MCP server off removes the agent’s only path to the data.

Two details the signer must get right (see Enrollment troubleshooting): the passport is signed under the profile’s signing kid (not the key id), and the passport TTL must stay within the adapter’s replay window.

Next steps

• Cross-cluster calls — the same trust model when the caller is in another cluster or organization.
• Local development — the generic key-generation and signing command flow behind software/JWKS sources.
• Request binding — how proofs are tied to the exact request.