Reference implementer · H2A standard

Was this allowed?

Bridle governs the use of AI-generated likeness and voice. Consent becomes a live permission — checked at the moment of use, revocable at will, and provable after.

Point-of-use · never cached Fail-closed · verify or refuse Signed tamper-evident records
DECISION RECORD grant 3f9a·c21b PERMITTED_CONFORMANT chain_intact: true signed status list
Built on the open  H2A standard Fail-closed by design Never cached · checked live GDPR Art. 7(3) Conformance L1 → L3

The check is free and open; the guarantee around it is what Bridle sells. We have no revoke capability — here is the code →

The right question

Every synthetic-media tool answers "is this fake?" — after the fact. The question a performer, a union, and a general counsel actually need answered is "was this allowed — right now?"

Consent is not a checkbox at sign-up. It is a live permission, checked at the moment of use — and its withdrawal is provable. That is what Bridle enforces, and what it records: for every act of use, a signed, tamper-evident decision of whether it was conformant.

The moment

Withdraw permission. Watch it stop.

A render is running under a live grant. When the rights-holder withdraws consent, the next check refuses — and Bridle produces the signed receipt that proves it. Try it.

● Live render PERMITTED_CONFORMANT

Northbank — shot 14 · likeness ADG-001 (face, voice)

1,487

Issued by the rights-holder, at her own service. Bridle cannot revoke — it only reads the signed list.

Independent verification

Signed, tamper-evident — anyone can check it.

  • Issuer signature on the status list VALID
  • Revocation bit SET · list re-signed by the fiduciary
  • Revocation → halt latency 21 ms
  • Partial output DESTROYED · COMMITTED
  • Record chain INTACT — 0 MISSING

The record it produced

While the grant is live, each act signs an attestation. Withdraw consent and the next act becomes a signed decision record instead — this is the evidence.

attestation.json PERMITTED_CONFORMANT
{
  "h2a_version": "0.1",
  "attestation_id": "8f14e45f-ceea-467a-9ba3-8d1c2f7a91b0",
  "grant_id": "3f9a…c21b",
  "subject_ref": "urn:h2a:subject:ADG-001",
  "grantee_ref": "urn:h2a:grantee:northbank-studios",
  "output_hash": "sha256:9f2a…e7c1",
  "generator": { "adapter": "synthesia", "model": "express-1" },
  "status_check": {
    "result": "valid",
    "checked_at": "2026-07-18T11:45:28Z",
    "status_uri": "https://issuer.example/status/adg-001"
  },
  "alg": "ES256",
  "signature": "MEUCIQD…9f2a",
  "created_at": "2026-07-18T11:45:28Z"
}
output_hashThe output is bound by its SHA-256 hash — the record holds no media.
status_check.resultA live point-of-use check — never cached — returned valid.
subject_ref · grantee_refWho was involved, as opaque URNs. No names, no biometrics.
signature · algES256 — anyone can verify it independently.
created_atWhen the act happened, to the second.
L1 today The status-list signature is real ES256; Bridle's own record signatures land at L2 (Sprint 1). We say what's proven and what's planned — see the roadmap →
What the record includes
  • The act, bound to its grant
  • The output — by SHA-256 hash
  • The live point-of-use check + reason
  • Who: subject & grantee, as opaque URNs
  • When it happened
  • A signature anyone can verify (ES256)
What it deliberately does not
  • No raw media or copy of the output
  • No biometric template — faceprint / voiceprint
  • No personal data beyond opaque URNs
  • No revocation key — Bridle can't revoke
  • No cached checks — always live
  • No blockchain

additionalProperties: false — the record is exactly these fields. Nothing hidden, nothing extra. That is the whole schema.

How it works

One check, in order — and it fails closed.

Every use is re-evaluated live against the issuer's signed status list. Nothing is cached; anything Bridle can't verify is refused.

01

Grant

  • Scoped: purpose, territory, lease, cap
  • Two signatures: consent + issuance
  • Points at a signed status list
02

Point-of-use check

  • Verify signatures
  • Validity window
  • Fetch + verify signed status list
  • Scope · lease
Unreachable / unsigned / stale → refuse
03

Decision

PERMITTED REFUSED_*
  • Generation only on a fresh permit
04

Record

  • Attestation binds output to the check
  • Decision record — the evidence
  • Hash-chained · chain_intact
01
Authority

Grant

Bounded, revocable authority to use a subject.

02
Receipt

Attestation

Signed receipt of one act of use.

03
Evidence

Decision Record

The signed conformant / non-conformant decision.

04
Revocation

Status List

Static, signed artefact — the issuer's, not Bridle's.

For developers

Govern a generation in a few lines.

One SDK, one API, one MCP server — a generator is unreachable without a fresh permit, and every act leaves a signed record.

governed-generate.ts
import { BridleClient } from "@bridle/sdk";
import { governedGenerate } from "@bridle/adapters";

const bridle = new BridleClient(process.env.BRIDLE_URL);

// a generator is unreachable without a fresh permit
const r = await governedGenerate(bridle, grantId,
  { purpose: "promotional-video", territory: "GB" },
  synthesia, { script });   // your Synthesia / HeyGen adapter

if (r.permitted) ship(r.attestation);  // signed receipt
else refuse(r.decision);              // e.g. REFUSED_REVOKED
# Point-of-use check — live, never cached
curl -X POST https://api.kilbowieconsulting.com/v0/check \
  -H "authorization: Bearer $BRIDLE_TOKEN" \
  -H "content-type: application/json" \
  -d '{ "grant_id": "3f9a…c21b",
        "use": { "purpose": "promotional-video",
                 "territory": "GB" } }'

# → { "decision": "PERMITTED_CONFORMANT",
#     "chain_intact": true }
// Any MCP client (Claude, an agent) acts compliantly
{
  "tool": "check_grant",
  "arguments": {
    "grant_id": "3f9a…c21b",
    "use": { "purpose": "promotional-video",
             "territory": "GB" }
  }
}
// → PERMITTED_CONFORMANT  · else the generator is never called

What you get

  • Trust anchor. The issuer's public key — you hold no private key, and neither does Bridle.
  • API keys. Scoped M2M credentials (client id + secret) per environment.
  • @bridle/sdk + @bridle/adapters. From Bridle's private registry — the governed-generation seam.
  • MCP server. Governance tools for agentic clients — check, attest, audit.
  • Signed decision records. The tamper-evident evidence, designed to be insurable.
See plans & pricing

Where the power sits

No single party can forge or suppress a revocation. Bridle included.

Here's the math — three reasons to believe it, strongest first. Not "trust us": redundant, auditable power that survives a bad day.

1 · Incentives. Bridle makes more money when revocations are honoured, not fewer — the check is free, the guarantee is the product. No incumbent can copy that, because none can honestly build a tool whose output reduces its own revenue or worsens its liability. This is the structural reason, and it can't be faked.

2 · No key. Revocation authority is custody of the status-list signing key, and that key stays with the rights-holder's fiduciary — never the operator, never the vendor. Bridle holds only the public key: it fetches the signed list, verifies it, and fails closed.

3 · Auditability. You don't have to take our word for either. The check is open and re-runnable against the reference verifier, and the signed list is a static artefact with mirror URIs named in the Mandate. In honesty: today Bridle operates the issuer endpoint on the fiduciary's behalf under shared ownership — an acknowledged interim — and configures the trust anchor. Independent fiduciary custody and Foundation-governed anchors are on the roadmap, not yet the fact. We say which is which.

signed list → fetch · verify → TRUST DOMAIN · FIDUCIARY Issuer / Fiduciary Rights-holder · union · CMO Holds the signing key · publishes the signed list CAN REVOKE ON THE PATH Mirrored CDN Static signed artefacts · multiple URIs in the Mandate TRUST DOMAIN · OPERATOR Operator + verifier Studio · platform · agency Client-side verifier fetches the list, verifies, fails closed VERIFIER ON PATH — NOT BRIDLE OFF PATH H2A Foundation Anchor policy — which issuers count anchor policy operates endpoint · attests · records IMPLEMENTER · OFF PATH Bridle NO KEY · CANNOT FORGE OR SUPPRESS

The solid line is the runtime path; the dashed lines are parties that cannot block it.

"When a performer withdraws consent, the operator cannot pay Bridle to ignore it. Only the union can sign the list — and Bridle literally cannot."

The four powers

Revocation is four powers, not one — here's who holds each.

PowerWho holds itWhere Bridle stands
Sign a revocation The fiduciary, alone — rights-holder, union, or CMO. No key. Bridle cannot obtain one. This is the whole split.
Decide which issuers count The trust-anchor policy. Bridle-configured at v1 by default — nothing else exists yet. Moving to Foundation-governed policy; we won't pretend that's done.
Decide how the check behaves H2A Core & the conformance spec. Fail-closed is a conformance requirement, not a per-deployment vendor choice. We can't quietly fail open.
Serve the list Whoever hosts the signed artefact. Bridle operates the endpoint on the fiduciary's behalf — the one place we sit near the path. Mitigated: multiple mirror URIs, static signed artefacts (a suppressed mirror is detectable; a stale one fails the signature or the horizon check), and issuers move without moving credentials (§8.7).

Row four is the honest one — and it's what makes the first three credible.

For operators

This is a defence, not a veto.

When a revocation lands mid-generation, the gate halts and the decision record captures what was known, when, and what happened next — the artefact you hand your general counsel.

What you get

A signed, tamper-evident record that you halted when instructed — proof of a governed act, designed to be insurable.

What it records honestly

Including any downstream leg that did not honour the halt. We record the gap rather than paper over it.

A chain is only as revocable as its slowest gate; the effective horizon is the maximum of its links. You hold the grant. You govern. You never generate without one.

Not a claim to trust — a claim to falsify. The code is open, and the parties who could block a revocation are the ones drawn off the runtime path above. See the standard →

Who it's for

Built for the people who carry the risk.

Studios & platforms

Deploy synthetic actors and voices with proof each use was licensed — governance above whoever renders the pixels.

Unions & CMOs

Give performers withdrawal that actually takes effect — and a signed record when it does. GDPR Art. 7(3) as a running system.

Legal, compliance & underwriting

The artefact your procurement team — and an underwriter — actually relies on: admissible, tamper-evident evidence.


Where it's going

Honest today. Underwriter-grade next.

Conformance climbs L1 → L2 → L3. A live deployment is L1 today — we say what is proven and what is planned.

L1 · Now

Verifiable

Schema-valid grants, fail-closed checks, real ES256 status-list signatures.

L2 · Next

Attested

Real grant-signature crypto (Sprint 1) and a durable UK/EU store (Sprint 3).

L3 · Planned

Anchored

eIDAS timestamps + witness co-signature — the level an underwriter relies on.

See the full roadmap

See it live

Prove the use. In ten minutes.

A short walkthrough of the governed actor — issue, check, the live revoke, and the receipt an underwriter relies on.