How it works

What happens to a request between your app and the model.

Detect, decide, transform, sign. Four steps, in that order, on every call, and a receipt that says which of them ran.

Detect rules, then a model tierDecide policy per classTransform block · substitute · recordSign ed25519 · logged

One request, end to end

Six things happen to every call. In this order.

Your application changes one base URL.

The request leaves your code exactly as it did before, bound for lyntway instead of the provider. Nothing else in the application changes; the SDKs and the CLI are there for the cases where it should.

Detect: rules first, then a model tier.

Deterministic rules with check digits run on every byte: card numbers, Aadhaar, PAN, IBAN, account numbers, secrets. A model tier reads for names, addresses and the things a pattern cannot catch. Every finding says which tier found it.

Decide: your policy, per class, above ours.

Each class carries a decision: let it through and record it, substitute it, refuse the call, or hold it until a person approves. Payment routes are special: a card number is recorded and never substituted, because a replaced number turns a valid charge into a decline.

Transform: a look-alike in the same shape.

A substituted value is replaced by one from a range its issuer never uses, so the model still understands the document and the reply reads right. One-way deployments record redact, not tokenize, because the schema defines tokenisation as reversible.

The reply comes back through the same door.

The direction most products ignore is the one where a tool result is about to become the next prompt. The reply is governed on the way back, and where a substitute was issued, the real value is put back where it belongs.

Sign: a receipt that says which of these ran.

Digests of what passed, the decision, the rules version, the governance mode and the provenance, signed with ed25519, hash-chained to the receipt before, entered in the transparency log and timestamped by an outside authority.

Streaming

Governed as it flows, not after.

A streamed response is handled event by event. Text is held only as long as it takes to be sure a token is not split across a chunk boundary, then released. You keep the reason you wanted streaming; we keep the ability to act before something leaves.

Illustration

event 41 …the customer's card endingevent 42 4111 1111 1111held one chunk, until the boundary is knownevent 43 9999 3507 5774 0496 was charged onreceipt truncation: none · governance: full

The laptop problem

Where a proxy cannot go.

Most MCP servers run as a subprocess of the agent, over a pipe. There is no network hop, so a gateway, however well placed, is blind to them. When a developer asks their assistant why a customer's subscription is broken, the assistant calls a database tool, gets back a row with that customer's email and card details, and puts it straight into the next prompt.

lyntway-mcp spawns the server itself and governs the pipe. Detection happens on the machine. Only classes and counts leave, never content, so the receipt says attested.

The browser extension and the on-device agent

Two paths

Gateway alone

agent ── stdio pipe ── mcp serverno network hop; nothing reaches the gateway

With lyntway-mcp

agent ──▸ lyntway-mcp ──▸ mcp servergoverned on the machine; classes and counts attested

Verification

Thirty lines against any crypto library.

That is the whole algorithm, and it is documented so you can write your own verifier rather than use ours. The one we ship is Apache-2.0 with no third-party dependencies at all.

RFC 8785 canonical JSONRFC 9162 transparency logEd25519 signature

Verify a receipt Read the documentation

Canonicalise the receipt per RFC 8785

One byte sequence, whatever produced the JSON.

Verify the Ed25519 signature over those bytes

Any crypto library you already trust.

Check the key against the published attestation

So a valid signature from the wrong key still fails.