Latch / Docs
docs

Introduction

Latch turns raw credentials into programmable, verifiable authority.

An API key is not a string. It is authority.

A Stripe key can move money. An OpenAI key can spend thousands per hour. When you hand a credential to an agent, you are not sharing access. You are delegating power.

Today that delegation is binary. The key works or it does not. You cannot say "this key may issue refunds under $100 but may not delete customers." You cannot say "this key works on weekdays, during business hours, from this machine." The key is the authority, and the authority is absolute.

Today: binary delegation

  You ──── API key ──── Agent
            (full power)

  The agent can do anything the key allows.
  No scoping. No caps. No audit. No revocation.

Latch replaces that with one idea: the credential never leaves Latch.

You store the real key as a Secret. You mint a Latch, a scoped token (lat_…) with its own upstream and its own policy pipeline. You give the agent the latch, not the key. Every request the agent makes passes through the pipeline before the real credential is ever used, and the first filter to deny stops it dead.

With Latch:

  You ──── Secret (the real key, never returned)
             │
             ├── Latch A  lat_…  → policy → upstream
             └── Latch B  lat_…  → policy → upstream

  The agent holds a latch. It never sees the key.
  Revoke the latch and the agent is cut off. The key never rotated.

The well-behaved agent never knows Latch exists. It sets a base URL and a bearer token and makes ordinary HTTP calls. The misbehaving one finds out immediately.

What this gets you

Scoping. A latch can be restricted by endpoint, method, request body, rate, time of day, caller IP, or daily spend. See the filter reference.

Delegation that narrows. A latch can be extended into a child that inherits its policy and can only tighten it. One credential fans out into progressively more restricted tokens, resolved live at request time.

Hardware-bound identity. The identity filter gates a latch to specific agent keys, so a stolen token is useless on a machine you did not enroll.

One audit trail. Every decision, allowed or denied, with the filter that decided and why.

Where to start

If you want to make a call, go to the quickstart.

If you want to understand the model first, read about the filter pipeline, then multi-mount latches, which put several upstream services behind one token.

If you are integrating, the proxy API is the entire public surface: four operations, and a machine-readable OpenAPI document you can generate a client from.