How it works

Five checks between a request and your API — in milliseconds.

A provider-side authorization boundary. Every machine request arrives carrying its own cryptographic proof, valid once, verified locally at the boundary.

01

Attest

The workload proves where it runs before it is allowed to ask for anything. Attestation comes from the platform itself — a SPIFFE identity, an OIDC workload token, or a cloud instance certificate. Nothing is typed in, copied, or stored by the caller.

02

Match anchor

The attestation is matched against a trust anchor you declared in advance: the source it must come from, the network it must sit on, the window it may operate in, and the route it may reach. If the attestation does not fit an anchor, there is nothing to enroll and nothing to issue.

03

Issue passport

A matching caller receives a short-lived passport bound to that caller and that scope. It is not a portable bearer credential you can paste elsewhere — it is tied to the identity that attested and the narrow scope its anchor permits.

04

Verify request

Every request is verified locally at the boundary: the caller, the action, the audience, the route, the freshness of the proof, and whether it has been seen before. A proof is valid once, so a replayed proof is refused on arrival.

05

Decide + log

The boundary allows or denies and attaches a reason code to the outcome. Every decision — allow and deny alike — lands in an evidence-grade audit record, per request, so a later review can reconstruct exactly what happened and why.

Trust anchors

Policy in your vocabulary.

Policy in your vocabulary, not token scopes. No credential distribution. Revocation is one anchor edit.

anchor.customers-agent
source: aws.ec2 / us-east-1instance: i-38*  (prefix match)network: 10.2.0.0/16window: 08:00–14:00 business daysroute: /api/customers onlyattest: cloud certificate verifiedenroll: automatic for matching agents

How anchors are declared, enrolled and revoked →

Deployment

Fits in front of what you already run.

  • 01

    Brownfield adapter

    A container placed in front of your existing API. Application code stays unchanged — the boundary does the verifying before a request ever reaches your handlers.

  • 02

    Greenfield adapter

    Teams write endpoints and never auth logic. Available as a container today, with an SDK on the roadmap.

  • 03

    Local verification

    No hosted call sits in the request path. A control-plane outage degrades management, never enforcement.