Trust anchors
Declare what may call you — before anything asks.
A trust anchor is the policy a machine caller must match before it can reach your API. Workloads enroll against it automatically, every request is verified against it locally, and revoking it is one edit.
What it is
Policy first, callers second.
Most machine access starts with a credential: something is issued, copied into a config, and from then on whatever holds it is treated as the caller. An anchor inverts that. You describe the workload you are willing to accept — where it runs, what it may reach, when, and on whose behalf — and the boundary only enrolls callers that can prove they fit.
Nothing is issued to the caller and nothing is stored on their side. A workload that stops matching its anchor stops being authorized on its very next request.
- name
- reporting-agent-eu
- source
- aws.ec2 / eu-west-1
- instance
- i-38* (prefix match)
- network
- 10.2.0.0/16
- window
- 08:00–14:00 business days
- audience
- api.yourcompany.com
- route
- GET /api/customers
- scope
- read:aggregates · tenant=brand-a
- freshness
- proof valid once, seconds not hours
- enroll
- automatic for matching workloads
Lifecycle
Declared, enrolled, verified, revoked.
Four states, and only one of them involves a human. The rest happens per request, at the boundary in your environment.
- 01
Declare
You write the anchor: source, network, window, audience, route, scope.
- 02
Enroll
A workload attests. If the attestation fits an anchor, it is enrolled automatically.
- 03
Verify
Every request is checked against the anchor locally, then allowed or refused with a reason code.
- 04
Revoke
Edit or delete the anchor. The next request stops matching — nothing to rotate, nothing to chase.
The dimensions
What an anchor can say.
Where it runs
The attestation source itself — a SPIFFE identity, an OIDC workload token, or a cloud instance certificate — plus the account, region, or instance pattern it must come from.
What it may reach
Audience, route and action. An anchor that permits a read against one route does not silently extend to a write, another route, or another audience.
When and from where
Network range and operating window. A batch workload that only exists between 08:00 and 14:00 has an anchor that says so, and requests outside it never match.
On whose behalf
Tenant, brand or jurisdiction as an explicit policy dimension, so a workload authorized for one tenant cannot act against another just because your platform can reach both.
Revocation
One edit, not a rotation project.
Revoking a key means finding every place it was copied, replacing it, and hoping nothing was missed. Revoking an anchor means changing the statement the caller has to match.
Narrow the route, tighten the window, drop a tenant, or delete the anchor outright. The next request that arrives no longer matches, is refused with a reason code, and the refusal is recorded like any other decision. Callers that still match keep working, unchanged.
Because proofs are valid once and expire in seconds, there is no long-lived artifact still circulating after the edit. There is nothing outstanding to expire.
Boundaries of the idea
What an anchor is not.
Not a credential
There is nothing to distribute, paste, or store. An anchor is a statement about who may enroll; it is never handed to the caller.
Not a token scope
Anchors are written in your vocabulary — workloads, routes, tenants, windows — rather than as opaque strings a caller can present anywhere.
Not a hosted check
Anchors are pushed to the boundary in your environment. Matching happens locally, so a control-plane outage degrades management, not enforcement.
See an anchor refuse a caller.
We will write an anchor against one of your own APIs during the call, enroll a workload, then break the match and watch the boundary refuse it.