Testing brief

Everything you need to test this without asking anybody a question first. Written to be read once, top to bottom, in about ten minutes.

The whole product in one sentence. Lyntway sits between your applications and the AI they call, records what was in the traffic as classes and counts, and signs that record — so somebody who trusts neither you nor us can check later what happened.

Start here: five minutes

No account needed for any of this.

# 1. Send something through and read the receipt
curl -s https://lyntway.com/v1/demo -H 'Content-Type: application/json' \
  -d '{"content":"email priya@acme.co.uk, card 4111 1111 1111 1111"}' | jq .

# 2. Install the tools
brew install lynt-x-global/lyntway/lyntway

# 3. Check that receipt yourself, offline
curl -s https://lyntway.com/.well-known/lyntway-keys.json -o keys.json
lyntway-verify -keys keys.json receipt.json

Step 3 is the product. It runs with no account, no network call back to us and no permission from anybody. If it did not, none of the rest would be worth anything: evidence you need the issuer's cooperation to check is worthless at exactly the moment the issuer is the party in dispute.

What to actually test

Detection

Try to get sensitive data past it, and try to make it cry wolf. Both directions are bugs.

Card numbers, IBANs, emails, phone numbers, API keys — in the formats people really write them, with spaces, hyphens, line breaks, inside JSON, inside markdown tables.
Ordinary business writing that should not trip anything. A version string is not an IP address; a long number is not a card.
Prompt injection: instruction overrides, persona changes, attempts to extract the system prompt.
Non-English content, mixed scripts, and very long inputs.

The gateway

client = OpenAI(
    base_url="https://lyntway.com/gw/openai",
    api_key=LYNTWAY_KEY,
    default_headers={"X-Provider-Key": OPENAI_API_KEY},
)

Streaming, tool calls, large bodies, timeouts, an upstream that returns an error. The question behind all of it: does anything reach the model that the receipt does not account for?

The command-line tools

lyntway login
lyntway init      # shows what it found, asks before changing anything
lyntway status
lyntway undo      # must put the machine back exactly

undo is the one to be unkind to. Every file it touches is backed up first; if anything is left changed after an undo, that is a serious bug and worth reporting immediately.

The console

Sign up, run the readiness check on Overview, work through Connect, Traffic, Blind spots, Risk score, Team, Usage, Settings. Look for anything that claims more than it can know, any dead end, any control that does nothing, and any screen that shows a raw identifier where a person's words belong.

The rule everything is judged against

A receipt must never claim more than actually happened. If you find a case where it does, that is the most valuable bug you can file, above a crash.

Three fields carry it, and absent always reads as the weakest possibility:

Field	Values	Meaning
`evidence.provenance`	observed / attested / asserted	we watched the bytes · another system told us · the caller described itself
`governance.mode`	full / degraded / bypassed	everything ran · some of it did · none of it did
finding `detector`	empty / named	a rule matched, reproducible · a model judged, maybe not

Verifying a receipt from scratch

Do not trust our tool for this — write your own and see whether it agrees. The full recipe, including the domain separator that is easy to miss, is in the documentation. Roughly thirty lines against any standard crypto library.

Check issuer.key_attestation against the published root key. Prepend lyntway-key-attestation-v1\x00 before the canonical bytes.
Check the receipt itself against key_attestation.public_key. No prefix here.
Change one character anywhere and confirm it fails.

Known limits — please do not file these

AWS Bedrock and Google Vertex cannot be proxied. They sign every request in a way that breaks when anything sits in the path. Use the LiteLLM callback; it is the only vantage point that exists for them.
JetBrains AI Assistant cannot be redirected anywhere. lyntway status says so for that reason.
No password reset by email. Recovery codes at /recover, deliberately.
No SOC 2, no ISO certificate, no penetration test. We produce evidence an auditor can use; we are not ourselves audited.
Single region, no service level.
Test-mode payments. Checkout works and bills nothing real.

Reporting

Useful reports contain, in order:

What you sent — the exact payload, and how you sent it.
What came back — the receipt, whole.
What you expected instead, and why.

The receipt is the useful part. It carries the ruleset version, the policy version, the detector components and the mode, which together say what was running when it happened.

If you are using Claude Code

The repository has a CLAUDE.md at its root written for exactly that. It carries the honesty rule, the layout, the local run instructions, the traps, and a list of real defects this project has shipped and how each was found — so an agent starts with the failure modes rather than discovering them.

Two conventions worth knowing before you send a pull request: the root Go module has no third-party dependencies and CI enforces it, and comments explain why rather than what.

Where things are

Production	lyntway.com
Tools and their source	lyntway-tools
Install	`brew install lynt-x-global/lyntway/lyntway`
Python	`pip install lyntway`
Verify in a browser	/verify
Documentation	/docs

Documentation · Terms · Privacy · Verify a receipt