QuantumGatekeeper: Letting AI See Behind the Login — Without Sharing Passwords

Most of an application lives behind a login. The dashboard, the billing page, the admin console, the part where the real risk is — none of it is reachable until you're authenticated. So when you ask an AI to analyse "your app," there's an awkward question hiding underneath: how does it get in, and what does it do with the keys once it's there?

The usual answers are all bad. Hand over a username and password? Now a third party holds your credentials. Paste a session token into a form? Same problem, shorter shelf life. Spin up a service account with God-mode? You've created a new attack surface to babysit forever.

QuantumGatekeeper is our answer, and it's built on a single principle: the customer's login stays the customer's. We never see a password. The session you capture is yours — uploaded by you, used only to replay the run, and discarded afterwards. And instead of asking you to take our word for it, we hand you a sealed, cryptographic receipt that proves exactly what was reached behind your login — and proves, machine-checkably, that the receipt itself holds no credential value.

The trust problem with "authenticated AI"#

If you want an AI agent to test or audit the logged-in experience of your app, it has to authenticate somehow. Every shortcut trades away trust:

• Credentials in a form → a third party now holds the keys to your kingdom.
• A shared test account → standing access that outlives the test, with no record of what it touched.
• "Just trust the report" → a screenshot of a green checkmark is not evidence. It's a claim.

The thing customers actually want is narrow and specific: temporary, auditable, password-free visibility, with a record they can verify themselves afterwards. That's the whole design brief for QuantumGatekeeper.

How it works: capture, don't collect#

The breakthrough is that modern authentication is just browser-held state. Once a human has logged in — through Google, SSO, MFA, a passkey, Clerk, Okta, whatever — being "logged in" is nothing more than a set of cookies and local storage living in their browser. Bot-detection is happy, because a real human really did log in.

So we don't collect credentials. We capture session state, locally, in the customer's own browser:

1. The customer logs into their own app, the normal way, in their own browser.
2. The QuantumGatekeeper Session Bridge — a small browser extension — captures the active tab's cookies (including the httpOnly session cookies a page script can't read, which is exactly why this is an extension and not a bookmarklet) plus local storage.
3. It assembles a portable session file the analyzer can replay. In the local capture path, nothing leaves the machine — the customer uploads the file themselves and deletes it after.

No password is typed into anything we control, and the login never stops belonging to the customer. In the local path the extension transmits nothing — you upload the file yourself. There is also an opt-in one-click Connect: when the customer clicks Connect in the report, temporary browser session state is sent over TLS, scoped to that one analysis, encrypted at rest, used to verify access, then deleted. Either way, credential values are never shown in the report, logs, or receipt.

Provenance, baked into the session file

Every session the extension produces carries a small, secret-free provenance envelope: which tool captured it, the schema and extension version, the host, the time, and counts (how many cookies, how many httpOnly, how many local-storage keys). It records what was captured and who captured it — never a single cookie value. This is what later lets the receipt assert, truthfully, where the session it replayed came from.

Verify access before you spend#

Here's a subtle failure mode we learned the hard way: a session can be supplied without being valid. An expired or malformed session still gets "injected" — the cookies are there — but the moment the analyzer navigates to a protected page, it bounces straight to the sign-in screen. Naively, the run burns fifteen minutes analysing a logged-out experience and reports a misleading grade.

QuantumGatekeeper runs a verify-access-before-spend gate first. It doesn't trust a login-wall heuristic (client-side-auth SPAs render their sign-in page as a 200 with no detectable form — that lie fooled our first version). Instead it checks the only signal that can't be faked: did we actually reach the protected target route, or did we get bounced to /sign-in? A dead session aborts in ~40 seconds instead of running a full, wasted analysis — and the receipt honestly records that access was not established.

Only when access is genuinely proven does the real analysis run.

The Credential Receipt: proof, not a promise#

When an authenticated run completes, QuantumGatekeeper seals a Credential Receipt — an access-boundary proof, not a password receipt. It's canonical-JSON, hashed with SHA-256, and the hash covers everything except itself, so any later edit breaks verification. It records:

• which app/host was accessed, and how (method, tier, session mode);
• what was reached behind the login — protected and sensitive surfaces — and what stayed closed;
• the RBAC/persona boundary inferred from the run;
• the provenance of the session that authenticated it;
• and — explicitly, machine-checkably — that no credential value is stored in the receipt.

Here's the receipt from a real production run against a live, logged-in application:

Code
Copy
1access_verified ............... true
2protected routes reached ...... 35
3sensitive routes reached ...... 0
4credential_values_stored ...... false
5secrets_stored ................ false
6captured_by ................... QuantumGatekeeper Session Bridge
7extension_version ............. 0.2.0
8captured_host ................. quantumcareer.co.uk
9provenance.status ............. present
10session_file_provenance_verified  true
11seal .......................... sha-256 b4e49721cc7791ea…
12chain_verified ................ true

In the QuantumGlass report, that becomes a single human-readable line:

QuantumGatekeeper's Credential Receipt is secret-free: it records the access boundary and provenance, not credential values, cookies, JWTs, storageState, or localStorage contents. That's a hard invariant, enforced by a test that scans every field for passwords, JWTs, cookie values, bearer tokens, and storageState contents, and rejects any opaque blob longer than a SHA-256 hash. We re-ran that scan on the live production receipt — and on the full public report payload, more than twenty thousand string values — and found zero secret material. The real session that authenticated the run carried a live Clerk JWT; it does not appear anywhere in the output.

The moment that matters: tamper it#

A receipt is only as good as its tamper-evidence, so prove it. Take the sealed access-receipt.json, change one number — say, claim 9,999 protected routes were reached instead of 35 — and re-run the verifier:

Code
Copy
$ verify access-receipt.json        → genuine:  ✓ seal valid
$ verify access-receipt.tampered.json → tampered: ✗ seal BROKEN

That's the difference between QuantumGatekeeper and a dashboard screenshot. A screenshot is a picture of a claim. The Credential Receipt is a cryptographic proof you can verify yourself, offline, after the fact — and it falls apart the instant anyone touches it.

The full chain#

End to end, every link is now live in production:

Code
Copy
1Customer-owned login
2  → local session capture (browser extension)
3  → secret-free provenance envelope
4  → upload
5  → verify-access-before-spend
6  → authenticated analysis
7  → sealed Credential Receipt
8  → QuantumGlass report evidence
9  → offline-verifiable, secret-free proof

The customer grants temporary, password-free, authenticated visibility. The AI does its work only because access was proven. And what comes out the other end isn't a promise — it's a sealed, auditable, secret-free receipt of exactly what was accessed.

That's QuantumGatekeeper. Trust, made verifiable.