Redaktyn — Per-Project Secret Leak Blocking

Other tools guess. Redaktyn blocks the exact strings you registered — scoped per project, matched on your own device.

VISIT URL: https://redaktyn.com Other tools guess. Redaktyn knows. Every DLP scanner on the market plays a guessing game — regex for "looks like an API key", entropy scores for "looks random enough", heuristics for "looks like a password". Guess wrong and you either miss the real leak or drown your team in false positives until they switch you off. Redaktyn doesn't guess. You register the exact strings that matter — a production API key, a database password, a signing token, a customer identifier, any literal at all — once, from any browser on your team. From that moment no browser on that project can paste that exact string again. Not into ChatGPT. Not into a Jira ticket. Not into a public Gist. Anywhere. A KEY PER ENGAGEMENT, NOT ONE PER COMPANY This is the part no other tool on this shelf does, and it is why Redaktyn fits the way people actually work. Real teams are not one flat organisation. They are a build with contractors on it, somebody shared with the desk next door, and a project lead who knows exactly which twenty strings would end the engagement. So a project — the build, the migration, the piece of work — is the unit here. Its lead is its admin. Its secrets, its invites and its devices all belong to it. And it gets a key of its own: projectKey = HKDF-SHA256( ikm = your workspace key, salt = the project id, info = "redaktyn-project-key-v1", len = 32 bytes ) HKDF does not run backwards. A browser enrolled on one engagement cannot recover the workspace key, so it cannot derive a sibling project's key either — the fingerprints belonging to the team in the next room are bytes that machine cannot produce. Not a role it is missing. Not a database row a query forgot to filter. There is nothing on it to match with. You still remember exactly one passphrase. The derivation is what turns it into a key per project, so the thing that makes people give up on key management never appears. One invite link enrols one browser onto one project. Close the engagement and its fingerprints stop reaching every device on it at the next sync — no push channel, nothing to uninstall from a contractor's laptop that left in March. And if you never want to think about any of this: every workspace is created with one project already in it. A team that never opens the Projects page has one, and everything behaves the way it always did. EXACTLY HOW THE CRYPTO WORKS — READ THIS BEFORE YOU TRUST US WITH YOUR KEYS Your secrets and your passphrase never leave your device, in any form, ever. Here is the actual mechanism, not a marketing simplification of it. Passphrase to workspace key. Your admin sets one passphrase, once, on a page that belongs to the extension itself — never on our website, never in a form our servers can see. It runs through PBKDF2-SHA256 at 600,000 iterations, salted with your organisation id, to derive a 32-byte key. At 600,000 iterations a single guess costs an attacker 600,000 hashes. The key never leaves that browser's memory. Workspace key to project key. HKDF-SHA256, as above. One-way, domain-separated by a constant that a known-answer test keeps frozen — change a byte of it and every fingerprint ever registered would silently stop matching, so it is pinned rather than trusted. Secret to fingerprint, not to a copy. Each secret you register becomes an HMAC-SHA256 fingerprint — a 64-character hex digest — under its project's key, entirely inside your browser. One-way math: given the fingerprint there is no computation that recovers the secret. We store the fingerprint. We could not reconstruct your key from it if a court ordered us to. Matching happens locally, before the paste lands. The extension slides a window across the pasted text and compares against your cached fingerprints — in-browser, in under a millisecond, with no network round trip. A match blocks the paste before it reaches the page's input field. It therefore also works with your Wi-Fi off, on a plane, from the cached list. Multi-device without retyping the passphrase. The session key is protected on disk by a split-key scheme: half lives in extension storage, half is issued by our server per device. Neither half alone reconstructs anything, so a database breach on our end does not hand out your key. Asking for our half takes more than the storage file: the device signs a challenge with a key that was generated so it can never be read back, only used. And each request spends a one-time ticket and receives the next, so if two copies of one profile are both asking, the second one to arrive is holding a ticket we have already retired — we suspend the device and email the administrators. Recovery without us ever holding your passphrase. If an admin forgets it, recovery codes generated in advance and shown once decrypt a locally encrypted copy. The decryption happens in your browser. We only ever stored a ciphertext we cannot open. WHAT WE CAN PROVE WE NEVER HAVE, BECAUSE THERE IS NO COLUMN FOR IT ✗ Your actual secret values ✗ Your passphrase, in any form ✗ Any project key ✗ Anything you paste, or a hash of what you paste — only the label of a matched secret is logged, never the pasted text WHAT WE DO STORE, AND THE HONEST LIMITS OF THE MODEL We store the one-way fingerprints themselves and event metadata: the label you gave the secret, the destination host plus its first path segment, and a timestamp. Three limits worth reading before you decide: • Someone who steals our database and correctly guesses your passphrase could confirm a secret offline. The 600,000-iteration PBKDF2 wall is the only thing between a breach and that outcome, so choose a high-entropy passphrase. • Per-project keys separate project teams from each other. They do not separate a team from its own workspace owner, who holds the passphrase every project key is derived from and can therefore derive all of them. • The default project every workspace starts with carries the workspace key itself, which is exactly why anything enrolled before projects existed keeps working. It is a scope, not a boundary — and the dashboard labels it as one. Isolation begins at the first project you name. We are telling you all three because a vendor who gives you only the reassuring half of their threat model has not earned your trust. TRY IT WITH NO ACCOUNT Open the popup and choose "register fingerprints on this device only". Register any string with a passphrase, then try pasting it into an AI chat tool. Everything in this mode is local: the extension makes no network request at all until you join an organisation. WHY TEAMS SWITCH ✓ Zero false positives. A paste either contains a string you registered, or it does not. ✓ A key per project. Separation you can verify in the key schedule, not a permission checkbox you can misconfigure. ✓ Zero-knowledge, provably. Standard published primitives — PBKDF2-SHA256, HKDF-SHA256, HMAC-SHA256, AES-256-GCM. Nothing homegrown, nothing to take on faith. ✓ Works offline. Cached fingerprints mean the block still fires with no network at all. ✓ Fails closed. A locked session or a scan that cannot run blocks the paste and says why, rather than waving it through. ✓ Obfuscation does not help. Spaces added, case changed, zero-width characters wedged mid-key, base64 or hex wrapped around it — still the same fingerprint. ✓ Team-wide in minutes. Register once on the project; protected on every browser enrolled on it. ✓ Built for the AI era. The fastest-growing leak vector today is pasting a production key into a chat window, and that is the surface this starts on. WHAT IT DOES NOT DO • It does not guess. A string nobody registered is a string we have never seen, and we will not pretend otherwise. Run us underneath a scanner that guesses, not instead of one. • It does not read your clipboard. Detection uses the paste event already being delivered to the page, so no clipboard permission is requested. • It does not track your browsing. A page address is recorded only when a block actually happens, and only as protocol, host and first path segment. • It does not send the text you pasted anywhere. WHY IT ASKS FOR HOST ACCESS TO SPECIFIC SITES A secret leaves your device through an AI chat tool — not a random website. Host access is requested only for those AI-tool origins plus redaktyn.com (where secrets are enrolled), generated from one registry rather than hand- maintained, so it cannot drift from what the extension actually protects. Slack and webmail are not in that built-in list — asking every installer for Gmail and company Slack access was the most alarming line in the permission prompt for little extra value in an AI-tool DLP product. An administrator who wants those surfaces watched can name the domain in a policy; each teammate grants that specific site once from the extension popup via optional host permissions. That access lets the extension read the page you are already on. It is not network reach: the extension only ever communicates with one origin, redaktyn.com. Homepage: https://redaktyn.com Privacy policy: https://redaktyn.com/privacy