Lyntway Keys
Your applications hold one Lyntway key. We hold the provider keys, sealed for your account, and put the right one on each request.
Governance is what people discover they already have. The same request that picked up a key was inspected on the way through, and the receipt says what was found — as classes and counts, never the values.
OpenAI, Anthropic, Gemini, Mistral, xAI — or a gateway, an MCP server, anything the gateway reaches. Each key is sealed for your tenant and never shown again. Give it an expiry date if it should have one, and a note so the next person knows what it is.
Point the base URL at us and drop the provider key from the environment. A request that arrives carrying no key of its own gets the stored one on the way out. A request that does carry one keeps it — changing which credential a running service uses is not a decision made on your behalf.
Which agent made the call, which Lyntway key it presented, which upstream it named, and the host the bytes actually went to. Ed25519 over a canonical form, independently verifiable, and yours to hand to whoever asks.
OPENAI_BASE_URL=https://lyntway.com/gw/openai/v1 OPENAI_API_KEY=$LYNTWAY_KEY # the provider key is stored with us; nothing else to carry
The receipt
Four fields carry it. The agent that acted, the upstream it named, the host the bytes reached, and how we know — which for gateway traffic is observed, because this service handled every byte in both directions.
The provenance colours on this site mean one thing only. Green is observed, amber is attested by another system, red is asserted by the caller. A receipt never reads stronger than what happened.
What you get
A stored key can carry the date it stops being used. Past it, a request that relies on the stored key is refused before anything is governed and before any receipt is written — there is nothing to record, so nothing is. The refusal names the upstream, the date, and where to fix it.
A new value in, the old one stops existing. Nothing else changes: the applications keep their one Lyntway key and never learn a provider key was swapped underneath them.
Remove a stored key and every application relying on it stops reaching that provider at once, from one place. A key sent on a request still wins, so a team mid-migration is not cut off by somebody else's cleanup.
Beside each key: calls, bytes, tokens, when it was last used, which agents and which callers used it, and which hosts it reached. First-hand counts are shown apart from reported ones, because they are not the same kind of fact — and token figures are always the provider's report, labelled as such, never something we counted.
An agent reaching a destination it had not reached before. A caller nobody had seen. A volume spike against an upstream. An agent refused for being unregistered or revoked. An expired key still being relied on. Each with the receipts behind it.
A Lyntway key may be limited to the upstreams it names. Anything else is refused before it is governed, with a signal rather than a receipt, because nothing left. A key with no list reaches everything, and an absent list is never read as a restriction.
Register a public key against a Lyntway key and every request from it must carry an RFC 9421 signature over the method, path and body. The receipt's actor is then recorded as verified rather than asserted. An unsigned request on that key is refused, not quietly accepted.
Set a line — refusals in an hour, a multiple of the usual volume, a destination never seen — and a key that crosses it is held: refused, not revoked, with a signal and an alert, until somebody releases it.
Usage and signals are read from your account's recent feed, and every answer says exactly how many events it read and the window they span. Nothing here is labelled a month unless the source covers one.
Stated rather than left to be discovered
We do not mint new keys at OpenAI or Anthropic on your behalf. What exists is replace, expiry with a date, and revoke. If a provider's console is where new keys come from, that is still where you get them.
Each key is encrypted with AES-GCM under a key derived, for your tenant alone, from the deployment's master seed. The service can open it — that is how it puts the key on a request. Anyone who tells you their gateway injects a key it cannot read is describing something that does not work.
Run the same binary in your own estate and the master seed, the sealed keys and the signing key all stay with you. That is the answer for a review that needs it, and the reason self-hosting exists.
lyntway keys sign writes the private key to disk under mode 0600. On macOS, --keychain keeps a copy in the login keychain as the backup of record; the file stays, because the SDKs read the file. It is not in a secure enclave, and a copy of it signs just as well. A verified signature proves the request came from something holding that file, and no more than that.
The counters behind an automatic hold live in the memory of the process that saw the traffic. They reset on restart and are counted per replica, so a threshold is crossed later than the total across a deployment would suggest.
The figures beside a key come from a bounded feed of your most recent events. They tell you what is using a key now. They are not a bill, and the page says so.
Which providers, editors and gateways this reaches — and which it does not — is set out on one page.