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 can use configured software/JWKS-style request acceptance. Control also supports enrollment through validated generic OIDC JWKS sources; a GitHub Actions CI OIDC source has served in one deployment. Neither observation establishes that every automation provider or tenant is ready for enrollment. Check the source availability matrix.

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 Trust Anchor enrollment	Available for supported proof profiles; verify the exact source revision, policy and target activation

If your runner lives in another Kubernetes cluster or trust domain, the separate source and federation checks are 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)

The MCP bridge is a private preview, not a public package. It shows how a thin 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.