Home Privacy architecture Tenant isolation Evidence integrity Engineering practice Assurance What we never build Try it yourself Request pilot →
Live status  ·  Updated as things ship

Built, building,
and never.

Most vendors publish a security page listing only what works. This one lists the gaps too. A seed-stage company claiming a complete security posture has either not looked or is not telling you — and any reviewer worth their salary knows it. What follows is the real state of the system.

Live
0
Building
0
Planned
0
Never
0
Why publish the gaps? Because you will find them anyway, and finding them ourselves is the only version of this that builds trust. Everything marked Building or Planned is not available today and should not be counted on in an evaluation. If a control matters to your decision and it is not marked Live, ask us for the date.
Live in production now Building in progress Planned scoped, not started Never deliberately excluded
01 — Privacy

Privacy architecture

Structural rather than procedural — enforced by the database, not by policy.

Live
Identity documents cannot be retained
A database constraint rejects any write attempting to store a raw identity payload: CHECK (raw_payload_retained = false). Application code cannot override it.
Live
No names, emails or identity documents stored
No candidate-facing table has a name or email column. Candidates are opaque references that only the employer can resolve.
Live
Candidate references are hashed for every lookup
The employer's reference is SHA-256 hashed, and the hash is what every session, template and continuity record is keyed on. A readable copy is stored alongside it so a recruiter can recognise their own candidates in a list — it is the employer's own job reference, never a name or contact detail, and it is never the key anything is matched against. An earlier version of this page said the reference was “never held in its original form”. That was inaccurate, and we have corrected it rather than quietly reworded it.
Live
One face record per candidate, ever
Every re-check is compared against the original anchor and discarded. Twelve interviews still produce exactly one stored template.
Live
Legacy image storage retired
An early version of the product wrote webcam snapshots to a storage bucket. The current design streams the second camera live and stores nothing, but the bucket and one image from April survived — reachable by the anonymous browser role, and contradicting the claim above. Removed on 7 August 2026: the policies granting anonymous access were dropped by migration, then the image and the bucket itself were deleted. The account now holds no storage buckets of any kind, so “we retain no images” is no longer a policy we follow — it is a thing the system cannot do. We are listing it rather than quietly deleting it, because a page that only shows what went right is not worth reading.
Live
Provider deletion is tracked, not assumed
Purge is a state machine with retry, backoff, terminal-failure states and an attestation record — not a request fired into the dark.
Live
Template encryption at rest
AES-256-GCM envelope encryption, switched on in production on 7 August 2026. Verified by direct query on both databases after live capture runs: each stored template carries a ciphertext, an initialisation vector and a version marker, and the plaintext field is empty. A continuity check then decrypted a stored template and matched it against a fresh capture on each database, so the round trip is proven rather than assumed — encryption that cannot be reversed would look healthy right up until verification silently stopped working. Both databases were emptied before the switch, so no legacy plaintext template exists anywhere; not one unencrypted record predates it. One key covers the service today — per-tenant keys in a managed key service remain Planned, below.
Planned
Per-tenant encryption keys in a KMS
One key per customer, managed in a key service with documented rotation, so no single key exposes more than one tenant.
Planned
Automated retention enforcement
Expiry dates are recorded on every record today, but nothing acts on them automatically yet. Scheduled deletion with proof-of-deletion receipts is scoped.
Planned
A non-biometric verification route
Consent given in an employment context is not freely given in the legal sense, and some jurisdictions bar making biometric consent a condition of a hiring process. An equivalent non-biometric path is a requirement, not an option.
02 — Isolation

Tenant isolation

Keeping one customer's data away from another's — and being precise about what enforces it today.

Live
Tenant ownership on every record
Every session-scoped table carries an employer identifier, indexed, with foreign keys enforcing that sessions point at employers and recruiters that actually exist.
Live
Every recruiter route checks whose data it is, enforced by a build-failing test
A route that verifies a login has authenticated the caller, not authorised them. On 8 August 2026 an internal review found five routes that verified the session token and then discarded its claims — proving the caller was a recruiter without ever asking which. All five are now scoped to the caller's own employer. The more durable part is the check: a test scans every route on each build and fails if one authenticates a recruiter without using the employer claim, so the next route written cannot repeat it. Found in synthetic data before any customer held an account.
Live
Row-level security enabled, default deny
Enabled on all tables with no permissive rules, so the database refuses non-privileged access by default.
Live
Default public-role permissions revoked
The database platform grants broad default permissions to the anonymous API role — the role behind the key that ships in browser code. Revoked in production on 7 August, along with the default that would re-grant them on any table created later, and a database-level trigger that strips them from anything new. A build-failing check now runs against both databases on every deployment. It was deliberately merged before the fix, so it failed loudly and enumerated every affected table first — a check nobody has watched fail is not evidence that it works.
Building
Isolation enforced by the database, not the code
Today separation is enforced by application code consistently filtering on the tenant identifier, with the database groundwork in place. Moving enforcement into the database itself — so a missed filter cannot leak — is the largest single piece of work on the roadmap, staged table by table.
Planned
Per-request authenticated database access
Requests execute as the user's identity rather than a service key, confining the privileged key to background jobs and migrations.
Planned
Cross-tenant test suite
An automated proof that an authenticated user of one tenant cannot read another's data by identifier, by reference, or by export.
03 — Evidence

Evidence integrity

The record is the product. These are the controls that make it defensible — and the ones that do not exist yet.

Live
Decisions record the rule they were judged against
Every continuity result stores the threshold, model and alignment method in force at the time. Tighten the standard later and past decisions remain interpretable on their own terms.
Live
Tamper-evident deletion receipts
Receipts carry a hash and signature; altering one breaks the seal visibly.
Live
A receipt cannot exist without the verification it attests to
A seal that anyone can apply is not a seal. On 8 August 2026 an internal review found the endpoint that records a completed identity check had no authentication: a valid, correctly signed receipt could be minted for a session that had never existed. Completion is now refused unless the session is real and its face anchor was already captured — the order the product claims, enforced rather than assumed. Repeated calls return the original receipt instead of issuing another. Found and closed in synthetic data, before any real candidate had been processed.
Live
A browser can only report what a browser can observe
The evidence record accepts telemetry from the candidate's device — setup progress, camera state, session end. It previously accepted any event name, which meant a browser could write a record of a decision the server never made. Reported events are now checked against a fixed list of things a client can legitimately witness; anything a server authors — identity outcomes, continuity results, human overrides — is refused with the attempt logged.
Live
Receipts signed with a key that does nothing else
Receipts were signed with our identity provider's API credential doing double duty as a signing key — so rotating a vendor secret for ordinary reasons would have silently invalidated every receipt ever issued, and the same key existed in more than one environment. Signing now uses a dedicated per-environment key that signs nothing else. Signatures record which key made them, so a key can be replaced without stranding the receipts issued before it.
Live
Human approval required to begin a session
An authorised recruiter must actively approve. This is a step in the flow, not a configuration flag.
Building
Independently verifiable receipts
Receipts today are sealed with a shared secret, meaning only Verlinko can verify them — which is most of the point of a receipt. Moving to public-key signatures, so your own legal team can verify without us, is scoped.
Planned
Append-only, hash-chained audit trail
Today the audit record is protected by access control rather than by structure. Chaining each entry to the last makes silent alteration detectable rather than merely prohibited.
Planned
Authorization decision log
Recording not only who accessed evidence but who was permitted to — a claim no hiring tool currently makes.
04 — Practice

Engineering practice

How changes reach production, and how mistakes get caught.

Live
Database structure is version-controlled code
Every schema change is a numbered, replayable file. The database can be rebuilt from the repository alone — which is also what makes provisioning a new customer possible.
Live
Staging environment at parity
A full copy of the system at the identical schema version. Changes are applied there first, always.
Live
Automated drift detection against production
Every schema change compares the live database against what the repository says it should be, and fails if they disagree — on the pull request against staging, and again on merge against production. It has already caught a real divergence — storage rules named "authenticated" that in fact granted anonymous access.
Live
Cryptographic code tested on its failure paths
The encryption module is tested by trying to break it: tampered data rejected, wrong key rejected, missing key throws rather than silently writing plaintext. Testing that something fails correctly is rarer than testing that it works.
Live
Matching performance measured, not assumed
Separation between same-person and different-person populations is measured on our own pipeline and published, including the sample size. You can reproduce it on your own face.
Building
Multi-subject threshold calibration
Current measurements come from a small sample. Calibration across many faces, with false-match and false-reject rates stated at a chosen operating point, is in progress.
Planned
Server-side template computation
Face templates are currently computed in the browser. Moving computation server-side removes the possibility of a tampered client submitting a fabricated template.
Planned
Rate limiting on public endpoints
Not currently implemented.
Planned
Monitoring, alerting and incident response
There is no alerting today. Detection, an on-call path and a documented 24-hour breach-notification commitment are scoped together.
Planned
Second-angle enforcement
Candidates are guided to position the second camera between 110° and 120° during setup, and the interviewer sees both feeds live. Automatic measurement and enforcement of that angle is not built.
05 — Assurance

Assurance & compliance

The honest state of the paperwork a procurement team will ask for.

Live
Outside the EU AI Act's high-risk category
One-to-one identity verification is expressly excluded from the Act's high-risk classification, which covers systems that evaluate candidates. Verlinko verifies identity and does not assess people — and the boundaries below are what keep it that way.
Building
Data protection impact assessment (DPIA)
Mandatory for systematic biometric processing. In preparation, and it will be shareable so your privacy team can adopt rather than reconstruct it.
Planned
SOC 2 Type II
Not held. The observation window is 6–12 months of elapsed time and cannot be compressed. We will say plainly where we are in that window rather than imply otherwise.
Planned
ISO 27001
Not held. Sequenced with SOC 2, and prioritised if European buyers require it first.
Planned
Independent penetration test
Not yet performed. Planned inside the audit window so the results form part of the evidence pack.
Planned
Presentation-attack testing (ISO/IEC 30107-3)
The recognised standard for liveness and spoof resistance, tested by accredited laboratories. Not yet undertaken.
Planned
EU data residency
All data is currently hosted in the United States (US-East). A European region is a prerequisite for any EU pilot, and is scoped rather than merely intended.
Planned
Demographic performance reporting
Measuring whether accuracy differs across groups, and publishing it. Where a vendor supplies a tool used in hiring, this is increasingly the vendor's responsibility and not only the employer's.
06 — Boundaries

What we will never build

Not a backlog. Each was considered and rejected in writing, and each rejection is load-bearing — several are what keep the system outside the regulatory categories above.

Never
Emotion, attention or engagement inference
Inferring emotional state in workplace and education contexts has been prohibited under the EU AI Act since February 2025, with penalties reaching 7% of global turnover. We will not build it, and any monitoring feature is constrained by this line.
Never
One-to-many face search
Searching a face against a database is remote biometric identification. It is also what turns a verification tool into a surveillance tool. Verlinko compares one person only to their own earlier self.
Never
Automated rejection of a candidate
A failed check routes to a human. The system holds no mechanism to reject anyone, which is both the correct design and what keeps it an advisory tool rather than a decision-maker.
Never
Session recording
Creates exactly the retention liability the product exists to eliminate.
Never
Storing candidate names or contact details
Employers contact their own candidates. Verlinko never learns who they are.
Never
Selling or sharing biometric data
Templates exist to answer one question for one employer, and are deleted on schedule.
07 — Sequence

The order this
is being built.

Dates are shared with pilot customers rather than published, because a date on a public page ages badly and we would rather be exact with you than approximate with everyone.

Phase 0Stop the bleedingIn progress

Encryption switched on. Default platform permissions revoked. Legacy access paths closed. Paid infrastructure tiers so the service cannot pause. Secrets management.

Phase 1Identity and accessNext

Roles and permissions. An interviewer view that shows the session but not the trust signals. A company-admin surface so customers manage their own users. Rate limiting.

Phase 2Database-enforced isolationPlanned

The largest and most careful piece: moving tenant separation from application code into the database, table by table, with a full verification run after each. Highest risk, and not rushed.

Phase 3Key management and evidence integrityPlanned

Per-tenant keys. Audited break-glass access. Hash-chained audit records. Public-key receipts. Retention enforcement with proof of deletion.

Phase 4+Enterprise readinessPlanned

Single sign-on and directory sync. Resilience, monitoring and tested restores. EU region. SOC 2 observation window running in parallel from Phase 1 onward, because it is elapsed time rather than engineering time.

If you are evaluating Verlinko: ask for the current state of any row above and you will get a straight answer, including the ones that have slipped. We would rather lose a deal on an honest gap than win one on a claim that fails a second look.

Request pilot access →