Changelog

A new admin route mints a fresh access token onto an existing latch: the old token stops working the moment the rotation lands, the new one is returned exactly once, and everything else about the latch — its id, name, mounts, pipeline, children and counters — stays as it was. The same is available to a parent latch for its children through the delegation routes, so a holder that provisions many latches can rotate one of them without the owner's help. Rotation replaces the token and nothing else: a copy the owner placed in a mount header has to be re-applied afterwards. The Baby Step Zero example gains the matching commands, an inventory command that lists what an account holds beyond its tree, and a recovery section that says which token to rotate first after a leak.

A latch extended from an encrypted (TEE) latch carries a copy of the parent's sealed policy and credentials and evaluates that copy. Rotating a credential already refreshed those copies, but editing the parent — a changed filter, limit or mount secret — re-sealed the parent alone, so the change did not reach the latches extended from it. An edit that re-seals a parent now updates each extended descendant with the new seal before it answers. Encrypted-only deployments also refused a plaintext credential on the secret routes, which left no way to rotate a leaked credential sealed into encrypted latches short of creating a new secret and re-pointing every mount. A secret bound only to encrypted latches is stored encrypted at rest, sealed into the enclave and never read back by a local latch — the same position as a credential embedded in a mount at creation, which these deployments already accept — so rotating it in place is now allowed, and reaches its extended latches. A new admin route re-seals an encrypted latch to the current enclave key without changing anything else and hands the new seal to its extended latches — the recovery after the enclave is replaced. A personal access token can now revoke only itself; a signed-in session still revokes any token of its own.

New admin routes let a latch holder create children of one latch — the parent — look them up, suspend and resume them. The holder never calls them directly: the owner puts a mount on the parent's latch whose sealed secret is the owner's own access token and whose pipeline decides what a create request may look like, and a header the owner's mount override appends names the parent. The routes require that parent to belong to the owner, so every action is scoped to that parent's subtree — its children, their children, and so on down the tree, while a create always makes a direct child. A child is created as an extension of the parent — it inherits the parent's sealed configuration and can only add its own overrides — and its access token is returned exactly once. What a child may look like is not fixed in Latch: a payload filter on the parent's mount override pins the exact shape a create request must have, so the same routes serve any use case where one latch provisions many. Request and response bodies kept in the activity log are scrubbed of bearer-token shapes, so a create response captured by a parent with body logging on no longer stores the child's token among them. A TEE latch still records the enclave's signed response for later verification, which a child token is recoverable from whatever that setting says, so treat one as readable by anyone who can read the owner's activity log. Name checks on create now use a single lookup instead of loading every name the owner has.

A rate_limit filter took its slot as soon as it allowed a request, and kept it even when a later filter — or, on a TEE latch, the enclave's sealed policy — then denied the request, so attempts that never went through still drained the budget of the key they counted against (the latch, the caller IP, or a keyBy json_path value). The slot is now given back whenever the request never reaches the upstream: a later filter denies it, a spend cap denies it, the credential cannot be injected, or a TEE latch's sealed policy denies it before calling out. Over-cap attempts no longer inflate the counter either, so the count is the number of requests that went through. A request that was already on its way keeps its slot — an upstream that fails, a response filter that blocks the reply, or a TEE answer the server cannot verify, where whether the call happened is unknowable — and simulation never counts. The activity log marks a request whose slot was given back.

The proxy re-serialised upstream JSON bodies through the JavaScript JSON parser — every JSON object response on the direct proxy path, and any redacted response on the encrypted path — which rounds an integer above 2^53 to the nearest double. A 64-bit sentinel such as a chain's rent-exempt epoch marker came back as a value above the 64-bit maximum, and strict clients rejected the whole response. Every integer in a proxied body is now kept byte-exact.

A child latch's mount overrides gain a headersAppend field, merged over the parent mount's own upstream headers with the child's value winning per header name. This is for chained mounts: when a mount's upstream is another Latch, the parent used to hold one shared authorization header for that second hop, so every child was attributed and rate-limited as the parent there. Each child can now carry its own token for the hop and be attributed as itself. Header names and values are validated on save, the change applies on both the standard and the enclave venue without resealing, and the credential Latch adds for the mount's secret always takes precedence over an override of the same header. The inherited-mounts panel in the editor has a matching upstream-headers control per mount. Creating an extended latch through the API also now persists its mount overrides, which were previously only saved on a later edit.

An Encrypted (TEE) latch created by extending another latch inherits the parent's sealed credential slots. Rotating that credential in place used to re-seal only the parent, so its extended latches kept sending the previous credential upstream until they were re-created. The rotation now reaches every extended latch in the chain — children and grandchildren alike — and each one's re-seal status is reported next to the parent's. Credential re-seals in general (a rotation, a credential swap on a latch, or an OAuth token refresh) now also carry the latch's sealed policy over as is instead of compiling it again: they are much faster, and an extended latch keeps enforcing the policy it inherited from its parent even after its credential changes.

A rate-limit filter's window used to top out at 24 hours and its count lived in memory, so the most it could express was a daily cap that reset on every redeploy. Each filter now has a counting mode. Rolling is the default: a sliding window counted in memory, up to 24 hours — a filter that does not set the mode behaves exactly as before. Fixed is new: a clock-aligned window counted in the database, so the count survives a restart or redeploy and stays correct across several server instances, with windows up to 100 years. Fixed windows reset on clock boundaries rather than from a caller's first request; a window at the ceiling never rolls over in practice — keyed by latch on an inherited mount, for example, that gives every extended child latch its own lifetime count. The latch editor has the mode switch and shows every window in readable units.

Several web frameworks rewrite a request's verb from an override header, so a POST carrying X-HTTP-Method-Override: DELETE runs as a DELETE. Latch's method filter authorizes the verb actually on the wire, so those headers — X-HTTP-Method-Override, X-HTTP-Method, X-Method-Override and X-Rest-Method — are now dropped before a request is forwarded, on both the standard and the enclave path. If your upstream depends on one of them, send the real verb instead. A _method field inside a form body or query string is left alone: Latch forwards bodies byte-for-byte and never reads them.

A response filter's rules no longer share one redaction mode: each rule redacts the paths it declares with the mode it declares, so a rule that nulls one field and a rule that removes another can sit in the same filter. Previously the last rule to name a mode set it for every path in the filter. A maximum response size of 0 — or a blank field — now means no limit instead of blocking every response, both on the standard path and inside the enclave. The rule editor handles several rules at once, with the status-code and size gates grouped ahead of redaction, and the simulator now says outright that a response filter cannot be simulated because it runs against the live upstream response rather than reporting a bare skip.

A single-upstream latch's destination URL and its injected credential are both editable after creation. Pick a different stored secret, or paste a new credential and have Latch store it as a reusable secret for you. On an enclave-backed latch a credential change reseals the policy automatically; changing only the destination needs no reseal, since the URL was never sealed. Converting a multi-mount latch back to a single upstream also works now — supply the destination and credential in the same edit and it saves, rather than leaving you with a latch you could not finish configuring.

Every docs page now has an assistant that answers questions about Latch, grounded in the documentation itself and citing the pages it drew from.

Entries for features still in preview stay out of the public changelog until the feature is released, then appear automatically with their original dates.

The secure-enclave host now allows 60s of execution per request (up from 30s), so a TEE latch's configurable timeout window is 10–60s and a newly created latch with no explicit timeout gets the full 60s. Existing latches keep their stored value — including the old 30s default — until you edit the timeout.

The product tour runs on offline sample data; an Insights page left open behind it kept refreshing against that sample data and could go blank until reload. It now keeps its last real numbers on screen for the tour's duration. Opening /insights while signed out also now takes you to sign-in like every other app page, instead of rendering with a not-found status.

A live arena where AI agents race through hidden tracks by asking yes/no questions. Each racer's oracle calls go through a Latch, so the model key stays behind the Latch instead of inside the app, and paid tracks charge the racer's Sigil per question.

Spend caps on a multi-mount latch nest: the latch-level cap is the overall daily ceiling and each mount's cap is a sub-limit within it, metered on its own counter. Previously a latch-level cap took precedence over per-mount caps, and mounts shared one daily counter. Mount-scoped requests now also return x-latch-cost-mount-limit/used headers, and the self-introspection budget endpoint lists each mount's sub-limit with live spend.

A quickstart, task guides, and a full filter reference now live at /docs, next to a generated REST reference for the proxy API and this changelog. No sign-in needed.

When creating a latch, choose OAuth connect and sign in to the upstream in a browser popup — Latch discovers the provider's endpoints, registers or uses your client credentials, stores the tokens as a secret it refreshes automatically, and injects a live access token on each proxied request. The secret's connection health is visible wherever it's used, with one-click re-connect if a provider revokes it.

Front several upstream services from one token: each mount routes a path prefix to its own upstream, secret, and pipeline.

A child extension can remove an inherited mount or add filters on top of it, without touching the parent.

Retire an enrolled agent key permanently, so a decommissioned machine can never present a valid slip again.

Give a latch a mount table: each mount routes a path prefix to its own upstream, with its own secret and its own filter pipeline. One lat_ token, many services, one audit trail.

One less decision on the way to a working latch.

API and proxy calls are no longer 301'd to the canonical host, and redirected traffic is counted correctly.

New signups are approved automatically once their email is verified.

Daily usage attributed to the owner, so you can see who is actually using what.

Added a Linux host enrollment card alongside the macOS one.

Length bounds on the payload filter now evaluate correctly.

Reference a cached policy instead of re-shipping the WASM on every call.

The proxy no longer applies application/json to a body that is not JSON.

Cedar policies evaluate inside the enclave, compiled only for Cedar latches.

Identity, then the REX enclave, then attestation, then upstream. Traced per request.

A stateful filter cannot be meaningfully replayed in a dry run.

Onboarding, proxy, and spend instrumentation exposed for scraping.