Authorization for machine systems

Every request proves itself. No keys, anywhere.

A boundary in front of your APIs. One cryptographic proof per request — valid once, nothing stored, nothing to steal.

Watch it refuse →

A proven agent gets in

A proven agent gets in

Attested, matched, issued, verified — then allowed.

  1. ✓ calling
    Agent
  2. ✓ proven
    Attest
  3. ✓ matched
    Anchor
  4. ✓ issued
    Passport
  5. ✓ verified
    Boundary
  6. ✓ allowed
    API
200 · allowedreason: proof valid

01 The problem

Keys are everywhere. That's the problem.

Every integration you onboard leaves another standing credential behind.

  1. 01

    Every integration gets a key

    Agents, services, partners — each one holds a credential that opens your API, until someone remembers to rotate it.

  2. 02

    Keys are what leak

    They end up in config files, pipelines, and public repos. One copy in the wrong place opens everything.

  3. 03

    Nobody can say what happened

    A key proves someone got in. It cannot prove which request, doing what, was ever actually authorized.

  • 97% of organizations had an identity incident last year — Microsoft, 2026
  • 28.6M secrets leaked to public GitHub in 2025 — GitGuardian, 2026

02 The gap

~0

of ~2,000 public MCP servers scanned enforced any authentication.

Security scan, 2026

03 What you get

What you get.

No credential to distribute, a decision on every request, and a record of both.

Stolen proofs are worthless

A proof works exactly once. Steal it, and you hold a receipt for a request that already happened.

Nothing to leak

You stop issuing keys entirely. There is no credential to rotate, revoke, or wake up to on GitHub.

Every request judged

Each call is admitted or refused on its own merits — per request, not per session.

Evidence, every time

Every allow and deny becomes a record with a reason code. Audits read like receipts.

04 Watch it work

One path gets in. The other never does.

Allowed or refused — either way, it's on the record.

A proven agent gets in

A proven agent gets in

Attested, matched, issued, verified — then allowed.

  1. ✓ calling
    Agent
  2. ✓ proven
    Attest
  3. ✓ matched
    Anchor
  4. ✓ issued
    Passport
  5. ✓ verified
    Boundary
  6. ✓ allowed
    API
200 · allowedreason: proof valid
A stolen proof gets nothing

A stolen proof gets nothing

The proof was already spent. The boundary refuses it.

  1. ✓ replaying
    Attacker
  2. ✓ spent
    Copied proof
  3. ✓ refused
    Boundary
  4. API
Audit
logged · reason code
✕ Refusedreplay: proof already spent
  1. 01

    Attest

    Workload proves where it runs.

  2. 02

    Match anchor

    Against the policy you declared.

  3. 03

    Issue passport

    Short-lived, bound to this caller.

  4. 04

    Verify request

    Action, route, freshness, replay.

  5. 05

    Decide + log

    Reason code. Audited, per request.

05 Latency

The control plane is never in the request path.

Policy is pushed, not fetched. The auth plane sits in front of your own API and behaves like your own gateway, verifying locally against trust anchors it already holds. Nothing calls out to us while a request is in flight — so a control-plane outage degrades management, never enforcement, and your latency budget stays yours.

Read the full latency breakdown →

Trustplane

Caller
Boundary
API

verified locally · no external hop

Client-side brokers

Vendor cloud
Caller
Broker
API

credential fetched per request · extra round trip

Same request. One of these leaves your network before it is answered.

07 Demo

Watch it refuse.

Claude runs an agentic query. The request proves itself and is allowed.

08 The model

Three planes.

The part that actually refuses. It runs in your environment, in front of your API.

  • Verifies every request locally — no call to any hosted service in the request path, so your latency and availability stay yours.
  • Carries the proof types: the boundary is where the cryptography plugs in.
  • Ships as a container today. Brownfield: put it in front of an existing API, your code unchanged. Greenfield: write endpoints, never auth logic.
  • No metering in the enforcement path — the boundary never phones home to count requests.

What you buy when one protected API becomes twenty. The management layer, not the enforcement path.

  • Trust anchors: declare who may call, from where, in what window, to which route — and edit them fleet-wide.
  • Agent auto-enrollment: workloads matching an anchor enroll themselves by proving where they run. No credential hand-out.
  • Revocation: withdraw access by editing the anchor. Nothing to rotate, nothing to chase.
  • Fleet visibility: every protected API, every enrolled client, and their readiness in one view.
  • Evidence-grade audit: every allow and deny as a decision record with a reason code, exportable for compliance and incident review.

Custom pricing, scoped per deployment — cost tracks your estate, not your traffic.

For teams whose auditors assess the deployed instance, not just the code.

  • The control plane hosted inside your own environment, so trust anchors, enrollment, and audit records never leave your infrastructure.
  • Built for regulated and sovereignty-bound deployments where a shared SaaS control plane is not an option.

Talk to us about Edge — scope is defined per deployment.

Built at Axelerant to solve our own problem.