Your assistant says done. It never opened the app.
One flow, recorded once, in the browser you already have open.
It opens your app in a browser window - local, or a deployed address like a Lovable URL. Click through one flow and close it. It writes a real Playwright spec you can open and read.
Let the assistant work. A refactor, a new feature, a fix - whatever you were going to do anyway.
It replays the flow in a real browser against your app and says in plain English what broke.
When the change was the point, take the new state as the baseline and carry on from there.
A page that loads is not a page that works
No stack trace and no screenshot to squint at. Three facts, in the order you would ask for them.
A failure names the step it died on and quotes what it was looking for, instead of handing you a stack trace and a screenshot.
Every pass is written to a history file, so a failure can say the flow was fine eight minutes ago - which tells you it was the last change, not the one before.
Console errors and failed requests are compared against the last good run, so you are shown what is new rather than everything the page prints.
Your tests and the assistant rules live in your project. The record of every run lives in ~/.kryptheon on your machine, so it never lands in your git history. All of them are plain files you can open. Delete any of them and it starts again from what is left.
In your project: the recording, as a plain Playwright spec
In your project: the rule that makes an assistant check before it says done
In ~/.kryptheon: one line per run, so a failure knows when it last passed
In ~/.kryptheon: the URL and title a passing flow landed on
In ~/.kryptheon: the screenshot of the last failure
It copies the shape of your Supabase or Postgres database - tables, columns, the rules about who may see what - never a row. It attacks the copy with four questions, tells you in plain English what got through, and deletes it.
Every report ends with what was not tested, and why. Finding nothing is never called safe - it is called these attacks, this time, lost.
npx kryptheon-night
Add the MCP server and your assistant gets all of it as tools: record a flow with you, check it after every change, scan the database. It is told not to call a change done until the check passes.
Once, before anything else: install Node.js, the LTS version. Then pick the tool you use.
{
"mcpServers": {
"kryptheon": {
"command": "npx",
"args": [
"-y",
"kryptheon-mcp"
]
}
}
}Replace the command line with these two:
"command": "cmd", "args": ["/c", "npx", "-y", "kryptheon-mcp"]
Add your Supabase connection string next to "args". Never paste it into the chat - that puts the password to your whole database in a transcript.
"env": { "KN_DATABASE_URL": "postgresql://..." }“Check my app.”
Or: “record my app at https://my-app.lovable.app”. Lovable, Bolt, v0, ChatGPT and Claude.ai in the browser only accept hosted servers, so Kryptheon cannot be added to them yet.
Your assistant changes the app while you sleep. One rule it rewrites, one view it opens, and every customer's rows are readable by anyone with the address. Kryptheon attacks a copy of your database every night and tells you in the morning - before somebody else finds it.
For trying it on your own app, today
Runs from your terminal - no account needed
1 project, scanned when you run it
For the builder shipping one to three apps
Billed monthly - cancel any time
3 projects
For the freelancer and the small studio shipping for clients
Billed monthly - cancel any time
15 projects
Pro and Studio are coming soon, at the prices shown, in Indian rupees with taxes included. Nothing is charged until they open. See the refund and cancellation policy. Create your account and it will be ready on the day they open.
It is Playwright underneath, and the file it writes is an ordinary spec you can open and edit. What it adds is the recording, the baseline it keeps after a pass, and a failure report written in plain English instead of a stack trace.
Nothing from your project. It records in a browser on your computer, replays against your app, and keeps its history in a folder on your machine. There is no API key and the tools talk to no server of ours. The one thing we hold is an account, if you choose to make one: your name and your email, kept by Supabase, which runs our sign-in. When Pro opens, its nightly report will send us a summary of what the night found - the kind of each problem and the table it is on, never a row - and only if you turn it on.
A value typed into a password field is never written into the spec. It is replaced with an environment variable reference and the run tells you which variable to set in your .env file, which stays out of git.
That is enough. Open a terminal and run npx kryptheon@latest record with your app's address. It sets up a folder for the recordings itself - from your home folder it makes one called kryptheon-tests - and tells you where it is. After each change, run npx kryptheon check from that folder.
That is the point. Add the MCP server and your assistant gets the tools directly: it records with you, checks after every change, and is told not to call a change done until the check passes. Without MCP, npx kryptheon setup-ai writes the same rule into CLAUDE.md, AGENTS.md and .cursorrules, and npx kryptheon check --quiet keeps the output short.
No. It reads the shape of your database - table names, columns and the rules about who may see what - rebuilds that shape in a throwaway schema, attacks the copy, and deletes it afterwards - also when the scan fails partway. None of your rows is read, changed or copied.
Postgres, including any Supabase project you own. It needs your project's connection string. In Supabase, press Connect at the top of your project, choose Session pooler (port 5432), copy the URI and put your database password where it says [YOUR-PASSWORD]. Then, in your terminal, set it as KN_DATABASE_URL and run npx kryptheon-night. Never paste it into a chat, a website or a file you commit - it holds your database password. An app on Lovable Cloud - Lovable's built-in backend - does not hand one out, so the scan cannot reach it yet.
It will never say so. Nothing found means these attacks, this time, lost. Every report ends with what was not tested and why, because an attack that never ran looks exactly like one that was refused.
It says so and exits zero. A fresh project with no recordings is not a failure, and reporting it as one only sends an assistant off trying to fix something that is not broken.