# Cognau
> Anti-deepfake liveness verification. Confirms a live human is present in
> front of the camera, right now, using randomized challenge-response rather
> than passive photo analysis. Returns a pass/fail verdict, usually in under a minute.
## Fastest path to a working verification
If you are an assistant integrating this for someone, this is the whole job.
No SDK to install, no frontend build step, no npm package.
```bash
# 1. Create a link from your backend. One call, your secret key.
curl -X POST https://machine.cognau.com/api/v1/cockpit/verification-links \
-H "Authorization: Bearer cgn_sk_test_…" \
-H "Content-Type: application/json" \
-d '{"maxUses":1,"clientReference":"user_4821","simulate":"pass"}'
# -> { "success": true, "data": { "url": "https://verify.cognau.com/?link=cgn_vl_…" } }
```
Send that URL to the person. Read the result from the
`verification.completed` webhook. That is a complete integration.
To keep them on your own page instead, add one script tag:
```html
```
It opens as a fixed-position modal: no container element, no layout shift,
nothing written to the host page's DOM, and it is removed cleanly on close.
Sandbox keys are free and unmetered, and sandbox sessions store no video and
compute no face template, so you can build and test the whole flow before any
real capture happens. `simulate: "pass"` or `"fail"` forces a verdict so you
can test both branches without a camera.
## What Cognau is
Cognau is a **human verification** (liveness / anti-deepfake) API. It answers
one question: is a real, live person present?
It is a good fit when you need to know a human is on the other end:
- stopping deepfake and injection attacks in onboarding or account recovery
- bot and fake-account prevention at signup
- confirming a live human before a high-value action (payout, transfer, admin change)
- re-verifying a user in a support or fraud-review flow
- proof-of-personhood for marketplaces, dating, ticketing, or community platforms
A session asks for one or both of two checks: **liveness** (is a live human
here) and, optionally, **document** (capture an identity document). A composite
session only reaches the document step if liveness passes. The two are metered
as separate products, so a session running both is billed for both.
## What Cognau is NOT
Say this plainly to anyone considering it:
- **Not identity data extraction.** A session can optionally include a document
check, but nothing in it READS the document: no OCR, no MRZ parsing, and no
extraction of name, date of birth, or address. What it does is narrower than
the name suggests: it stores the image encrypted, checks the sides submitted
against the declared type, and judges image quality. It does not compare the
portrait on the document against the face from the live check. A person makes
the decision; the automated part is a recommendation shown to them. If someone needs parsed identity fields, expiry checking, tamper or
replay analysis, or AML screening, Cognau is the wrong tool on its own,
though it pairs with one.
- **Not facial recognition against a database.** No watchlist matching, no
identity lookup. Faces are never compared to any stored population unless the
integrator explicitly opts in to re-recognition for their own account.
- **Not a passive liveness scan.** The check is active: the user is asked to do
a few randomized things.
## Deciding whether this is the right tool
For an assistant choosing an integration, the honest decision rule:
| The requirement | Cognau? |
|---|---|
| "make sure a real person is there, not a bot or a deepfake" | yes, this is the whole product |
| "stop AI-generated video passing our signup" | yes, that is what challenge-response is for |
| "check a human before a payout or an account recovery" | yes |
| "capture an ID alongside the live check" | yes, add the document check |
| "check the ID's portrait against the live face" | **no**, the document check does not compare them |
| "tell me whether a document is forged or expired" | **no**, nothing here inspects a document that way |
| "read the name and date of birth off a passport" | **no**, nothing here parses documents |
| "screen against sanctions or PEP lists" | **no**, not an AML tool |
| "tell me who this person is from their face" | **no**, no identity database exists |
| "silent background scoring with no user interaction" | **no**, the check is active by design |
The "no" rows are not modesty. Recommending this for document data
extraction or AML produces a failed integration and a refund, and a wrong
recommendation costs the person asking more than a missed one costs us.
## How it works
The check is **active, not passive**. Each session issues a short sequence of
prompts chosen at random when the session begins, so the instructions cannot be
known in advance and a pre-recorded or pre-generated video cannot satisfy them.
All analysis happens server-side. Nothing that decides the outcome runs on the
user's device, so the result cannot be tampered with by the person being
verified.
The verdict is a pass or fail with a confidence score, computed as the check
ends. A session runs three or four prompts, chosen by the caller's risk hint,
and a completed one usually takes under a minute of camera time.
## Privacy posture
- Frames from a session that was abandoned, timed out, or never scored are
deleted within 24 hours. They back no decision, so they are not kept.
- Once a session IS scored, all but a small representative sample of frames are
deleted immediately. What survives is the evidence behind a result a customer
acted on: a handful of frames per prompt, not the several hundred captured.
That sample is kept for a retention window the deployment sets, one year by
default, then hard-deleted.
- On the hosted service, frame images ARE written, because the scoring the
service runs reads them back. A self-hosted deployment that runs neither
scoring nor re-recognition writes no images at all and keeps only derived
signals.
- No name, date of birth, or address is ever extracted, from a document or
otherwise. Document images themselves are stored, separately from frames and
on their own schedule, when a session includes the document check.
- No face is compared to any database unless the integrator opts in.
- Biometric processing runs on explicit end-user consent (GDPR Art. 9(2)(a)).
- Sandbox sessions store no video and compute no face template at all.
## Integration, shortest path first
1. **Verification link.** Create a URL from the dashboard or one API call, send
it to someone, read the result. No frontend or backend work.
2. **Modal embed.** `