Give your agents real authority, never give them a key. OAuth let you grant apps scoped access without handing over your password. Latch is the next leap: real spending power, real API access, real execution rights. All of it bounded, revocable, and proven on every request, without ever handing over a credential it can leak.
Already hold a workspace key?
Latch isn't about restricting agents. It's about finally being able to use them, for the things you couldn't safely let them touch before.
Give an agent a real budget, enforced at the edge. The over-budget call returns 403 before it leaves your network.
Real API access, real execution rights, scoped per relationship. One token, many upstreams, each with its own policy.
Every request is a receipt. Drill into the pipeline trace, replay it, prove what happened and why it was allowed.
Every other gateway has to read your data in plaintext to govern it. Latch enforces policy on encrypted payloads inside attested hardware. Govern the call without anyone, including us, seeing it in the clear.
The problem isn't just that keys leak. It's that possession is the wrong proxy for authority. An agent shouldn't be powerful because it holds a secret, only because policy proves it's allowed, for this action, right now.
And the API can't help you here: it executes on possession alone. It has no idea what this caller is allowed to spend, what it's already spent, or whether this call should happen. That context lives in a doc nobody reads and a billing page you check Monday, never at the call site, where it could actually stop anything.
# .env
OPENAI_API_KEY=sk_live_…m4n2
# assistant.ts: full authority,
# any model, any endpoint, any budget
await openai.chat.completions.create({
model: "gpt-4o",
max_tokens: 16000,
messages: [...],
});# .env
LATCH_TOKEN=lat_assistant_3f2a
# assistant.ts: same call, governed
await openai.chat.completions.create({
model: "gpt-4o",
max_tokens: 16000, # → denied
messages: [...],
}, { baseURL: process.env.LATCH_URL });Point your agent at a latch instead of the raw key. That's the whole integration, no rewrite. Your credential is already governed: scoped, rate-limited, audited, revocable. When your threat model demands it, wrap secrets and policy end-to-end with HPKE encryption in a few lines, so nothing, not even Latch, sees the payload in the clear.
The raw credential. Never leaves Latch. Bind it once.
Stored server-side, encrypted at rest. The Secret defines what the credential is and how to inject it into upstream calls.
POST /admin/secrets
{ "name": "OpenAI prod",
"credential": "sk_live_…m4n2",
"injection": "bearer" }A scoped access token derived from a Secret.
Give your agent a latch, not the Secret. Each latch has its own upstream base URL and its own filter pipeline. Many latches can fan out from one Secret.
lat_jordan_eng_3f2a
└── upstream https://api.openai.com
└── pipeline 6 filters
└── enabled yesAn ordered list of filters. First deny wins.
Composable: add, remove, reorder filters without touching the Secret. Conditional filters skip themselves cleanly, so payload validation can run only on writes, for instance.
[ method, endpoint, rate_limit,
payload, ip_allowlist, response ]
↓
allow → upstream / deny → 403One token, many upstreams. Path prefix routes the call.
Mounts are the composition layer. /openai → OpenAI, /stripe → Stripe, /schedule → a calendar API, all under one token, with per-mount pipelines and per-mount SLAs.
lat_… ─┬─ /openai → OpenAI
├─ /stripe → Stripe
├─ /sched → Schedule API
└─ /self → self-discoveryMix declarative and procedural. Cedar policies sit alongside your own JS. When you need shape no built-in covers, drop in custom_code.
For anything the built-in filters don't quite cover, write the policy in Rust. You get the full request context, governed outcalls to other latches, and a return type that's just Decision::allow() or Decision::deny(reason). Compiles to WASM, ships attested into REX, runs in single-digit milliseconds.
// policy.rs · compiled to WASM, shipped to REXuse latch::{Context, Decision, http_get}; #[latch::policy]fn evaluate(&ctx: &Context) -> Decision { // 1. method allowlist if !matches!(ctx.method, "GET" | "POST") { return Decision::deny("method not allowed"); } // 2. spend cap on chat completions if ctx.path == "/v1/chat/completions" { let max = ctx.body.u64("$.max_tokens").unwrap_or(0); if max > 4096 { return Decision::deny(format!("max_tokens {} exceeds 4096", max)); } } // 3. governed outcall · check on-call rotation, cache 60s let oncall = http_get("/oncall/who").cache_ttl(60).send()?; if oncall["user"] != ctx.headers["x-user"] { return Decision::deny("only on-call may use this latch"); } Decision::allow()}This is what bounded power looks like in practice. One master key never moves. Everyone, and every agent, downstream gets exactly the authority policy allows: the VP gets full models and a high ceiling, the contractor gets a small budget that expires, the bot gets read-only with PII redacted. Each can do real work. None holds the master key. Revoke any node and its descendants follow.
The bearer key was built for humans. Your agents need the next thing: authority they're granted, not a secret they hold.
Latch is in private beta. Request access at the top of the page and we'll send back a workspace key + a short call to walk through your stack.