Vol. I · No. 001 Integrity Alliance Protected-Identity Infrastructure
A Cryptographic Standard for Vulnerable Subjects

Identity you can study,
never re-identify.

Sentinel is protected-identity data infrastructure for the people existing systems fail — built so that no one, not even its makers, can turn a record back into a name.

Discipline

Privacy engineering · applied cryptography · research-data stewardship.

Portfolio

The privacy pillar of the Integrity Alliance accountability portfolio.

Status

Backend standard fully built — 96 passing tests. Awaiting independent crypto audit.

The Problem

An ordinary database is a list of people who can be found.

Most systems are built to remember who someone is. For some people, that memory is the threat.

Consider a study tracking outcomes for children leaving foster care. A registry of trafficking witnesses cooperating with investigators. A reporting line for undocumented workers naming an abusive employer. A shelter intake list for survivors of domestic violence. Each of these is, on paper, a perfectly normal database — names, dates, identifiers, joined to outcomes over time.

And each one is a liability the moment it exists. A subpoena, a breach, a curious insider, a misconfigured export, a vendor with broad access — any of these can convert a research asset into a targeting list. The harm is not abstract. For these populations, being identified is the injury itself.

The usual answers are not enough. Encryption at rest protects the disk, not the person with the decryption key. Pseudonyms in a spreadsheet are reversible by anyone holding the crosswalk. "Anonymized" exports leak through quasi-identifiers and small cell sizes. And in every one of these designs, there exists at least one human being who can, with ordinary access, turn the data back into a name.

Sentinel starts from a different premise: that single point of re-identification should not exist at all. You should be able to study a population — count it, follow its outcomes, prove your findings — without ever holding a record that points back at a living person.

How It Works

Four mechanisms, one guarantee.

Sentinel separates the ability to study a subject from the ability to find them — and enforces that separation in cryptography, not in policy.

01 One-Way Tokens

Keyed HMAC tokenization

Raw identity is never stored. Each subject is reduced to a stable, deterministic token via a keyed HMAC. The same person always yields the same token — so you can link records and follow outcomes over time — but the function is one-way. There is no reversible record to steal, subpoena, or leak.

02 Split-Key Custody

Shamir-gated vault

When re-identification is genuinely warranted — a court order, a safety emergency — it happens through a separate custody vault sealed under Shamir's Secret Sharing. No single custodian holds the key. Re-identification requires a quorum of independent custodians to convene. Break-glass by design, never by accident.

03 Tamper-Evident Log

Append-only Merkle audit

Every token issued, every policy decision, every break-glass attempt is written to an append-only, Merkle-chained audit log. Entries cannot be altered or deleted after the fact without breaking the chain. The record of who looked, when, and under what authority is itself impossible to quietly rewrite.

04 Private Aggregates

Differential-privacy queries

Researchers still need answers — rates, trends, cohort comparisons. Aggregate queries run through a differential-privacy layer built on OpenDP, adding calibrated noise so that population findings hold while no individual can be inferred from the result, even across repeated queries.

Who It Protects

Built for the people who cannot afford to be identified.

Sentinel exists because the cost of a data breach is not measured in fines for everyone. For these populations it is measured in safety, in custody, in lives.

Population 01

Minors in outcome research

Children in foster care, juvenile-justice, and long-term welfare studies whose identities must be followed across years without ever assembling a findable registry of vulnerable kids.

Population 02

Domestic-violence survivors

People rebuilding their lives whose location, services, and case history must never resolve back to an address an abuser could obtain through a leak or a legal fishing expedition.

Population 03

Trafficking witnesses

Survivors and witnesses cooperating with investigations, for whom a single exposed record is not a privacy incident but a direct, physical threat to their safety.

Population 04

Undocumented workers

Workers reporting wage theft, unsafe conditions, or employer abuse who must be able to come forward without their participation becoming an enforcement or retaliation list.

Governance & Trust

The guarantee has to survive us, too.

No single person can re-identify a subject from internal access alone — including the founder.

Crypto, not promises

The protection is enforced by the structure of the system, not by a privacy policy or a trusted operator. There is no admin override, no master key, no "just this once."

Separation of powers

Tokenization, custody, audit, and policy are distinct layers under distinct authority. The people who can study the data are not the people who can unseal it.

Verifiable by design

Append-only Merkle logs and a documented open standard mean the guarantee can be inspected and tested by outside parties — not merely asserted.

Build Status

The backend standard is complete: tokenize, vault, custody, break-glass, aggregate + differential privacy, policy, and service layers — covered by 96 passing tests.

Next Gate

An independent, third-party cryptographic audit. We are not asking anyone to take the guarantee on faith — we are inviting it to be broken.

Request & Inquiry

Read the standard. Audit the claim.

Sentinel is open to funders building safer research infrastructure and to security partners willing to stress-test the cryptography. Both conversations start here.