# Content compliance: EU AI Act Article 50, C2PA & ISO 22144

EU AI Act Article 50 is the forcing function: providers must mark AI-generated or manipulated content in a *machine-readable* way, and C2PA Content Credentials are the leading mechanism for that mark. A verifiable, revocable *signer* identity strengthens that mark, but it is a feature and a piece of evidence, not a compliance certificate.

This page is the honest map. A C2PA manifest signed by an X.509 cert that a verifier can only trust if it sits on a gate-kept Trust List answers "was this signed?" It does not, on its own, answer "by whom, provably, without a curated allow-list, and can you revoke that signer per-unit?" A routable, DANE-provable, one-call-revocable IPv6 `/128` for the signer answers that second question and produces the verification analytics and the tamper-evident issuance trail a standards or procurement reviewer wants as evidence. It is also honest about where it does *not* fit: it is not Trust-List membership, not a conformity route, and provenance is not truth.

> **How to read this page.** We grade every requirement into one of three verdicts and never blur them. **DIRECT-ADDITIVE**: Whisper produces evidence that maps to the requirement (as one input, never the whole framework). **COMPLEMENTARY**: the standard defines the C2PA manifest, its Trust List, or an identity assertion; Whisper is a pluggable trust source alongside it and can DANE-anchor the signer, but does *not* replace it or grant membership in it. **DO-NOT-CLAIM**: things a valid signature simply does not prove; we list them so nobody over-claims. The per-standard ● / ◐ / ○ / ✗ column in the map is the glance grade behind those verdicts.

## What every framework is really asking

Read Article 50, the C2PA Trust Model chapter, the CAWG identity assertion and ISO 22144 side by side and the same three questions surface, phrased in four vocabularies:

- **Marking**: is this synthetic or manipulated content marked in a machine-readable format that the public can detect, using an accepted technique?
- **Signer identity**: who signed the Content Credential, and can a verifier confirm that signer *without* trusting your word for it, and without a gate-kept, per-cert-fee allow-list?
- **Response & audit**: when a signing key is compromised or a disclosure must be provable, can you revoke that one signer fast, and show a non-repudiable record of what was signed and when?

The first question is C2PA's job, and Whisper never claims otherwise: the "this is AI" assertion lives in the manifest. The second and third are exactly where the C2PA spec names its own dependency: it says trust rests on *"an identity ecosystem substantiating that the signing key belongs to the Signer,"* and it provides the signature format and a curated CA list, not that public ecosystem. A DNSSEC/DANE-anchored, publicly resolvable signer identity *is* such an ecosystem. That is the whole of Whisper's honest role here.

## Three verdicts, stated up front

Before a single row of the map, here's the grading rule: a content-compliance page that claimed to "make you EU AI Act compliant" or "put you on the C2PA Trust List" would be lying. Whisper is a network primitive. Against a given requirement it does exactly one of three things, and we mark which:

- **DIRECT-ADDITIVE**: Whisper produces the evidence, as one input to your package: Art.50(2) marking · Art.50(4) disclosure · Recital 133 · verification analytics.
- **COMPLEMENTARY**: a pluggable trust source that DANE-anchors the signer but never replaces it: the C2PA claim signer · the C2PA Trust List & Conformance Program · CAWG Identity Assertion 1.2 · ISO 22144.
- **DO-NOT-CLAIM**: what a signature does not prove, said plainly: provenance ≠ truth · not deepfake detection · survives no manifest-stripping re-encode · no product makes you "compliant".

The honesty rule is the whole point of this page: a network primitive earns a verdict per requirement, and we mark `DIRECT-ADDITIVE`, `COMPLEMENTARY` or `DO-NOT-CLAIM` so a creator, a trust-and-safety reviewer and a procurement officer all read the same thing.

## The evidence: real, and shipped

Everything this page grades DIRECT-ADDITIVE rests on primitives that exist and answer *today*. Each is checkable with `dig`, `curl`, or one control-plane call over the public API: `POST https://graph.whisper.security/api/query` with your `X-API-Key`.

> **Shipped & live.** The signer-derived `/128`, `op:lookups` (who verified your content), one-call `revoke`, the Merkle transparency log and the attribution graph are in production. The **Splunk**, **Microsoft Sentinel** and **OpenCTI** connectors ship. Everything grouped under *roadmap* (a STIX/TAXII feed, a first-class typed CLI flag, and any submission into the C2PA Conformance Program) is labelled as such; nothing here is described as working unless you can reproduce it.

### A signer-derived `/128` identity

A C2PA claim signer is an X.509 **end-entity** cert (the only kind the spec allows for signing), and it already holds a key. Whisper derives a deterministic IPv6 `/128` from that key's *public* `SubjectPublicKeyInfo`, with the signer's identifier as the domain separator: the **signer cert serial** for a tool/device signer, or a **CAWG identity** for an org/creator. The address is tenant-bound (unlinkable across signers to an outsider), DNSSEC-anchored, DANE-EE `3 1 1` pinned, and RDAP-registered. Re-deriving from the same key and identifier yields the same `/128`; the private key never leaves the signer, only its public SPKI is an input, and there is nothing new to store that a scraper could steal to forge it.

```
# Provision a signer identity from the key it already holds (control plane, live).
# identity_public_key is the base64 SPKI of the C2PA claim-signer's EE key.
CALL whisper.agents({op:'connect', args:{
  tier:'wireguard',
  identity_public_key:'<base64 SPKI of the signer key>',
  device_id:'0A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D'   // the C2PA signer cert serial
}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error
# -> deterministic /128 + a WireGuard config. Same key + serial -> same /128 (idempotent).
#    A different serial on the same tenant -> 409; a non-string device_id -> 400. Never a 500.
```

> `0A1B…4C5D` is a placeholder cert serial. No real signer or CA is implied. The `device_id` argument is generic: pass the **signer cert serial**, a **CAWG identity**, or the `cawg.web_site` URI of the org that controls the domain. A first-class `--signer` CLI flag is **on the roadmap**; provision via the control-plane call above today, which **is** live. To publish the DANE/TLSA record under your *own* DNSSEC-signed domain, so a verifier reads "signed by `press.example-news.org`", use the shipped BYOD flow (`op:'domain'` then `op:'verify'`).

### Who verified your content: `op:lookups`

C2PA verification needs *no* network call: the signer's cert chain travels in-band in the COSE header (`x5chain`, RFC 9360), so a signer normally has **zero** visibility into who checked their content. The only network events are OCSP/CRL and the TSA. That flips the moment the signer identity is DNS/DANE-anchored: a verifier that confirms your DANE-pinned signer resolves your PTR/AAAA/TLSA records (and may hit your RDAP object), and `op:lookups` surfaces exactly those resolutions. It is a capability C2PA structurally cannot give a signer: *who verified my content, and when*.

```
# Reverse observability: WHO resolved this signer's PTR/AAAA/TLSA, or hit its RDAP object
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:c2::51', window:'30d'}})
curl -s https://whisper.online/ip/2a04:2a01:c2::51/lookups | jq   # same view, keyless

# The signer's OWN outbound activity, if it is a live signing agent: per-event records
CALL whisper.agents({op:'logs',    args:{agent:'2a04:2a01:c2::51', kind:'conn', from:'-24h'}})
```

### One-call, per-unit revoke

Containment is a single call. A C2PA-signing device fleet learned the cost of coarse revocation the hard way in 2025, when a camera vendor had to suspend its authenticity service and revoke its *entire* set of C2PA device certs after a security flaw: a fleet-wide off-switch, not a per-unit one. Whisper's `revoke` tears down one signer's `/128`, its PTR and its DANE record worldwide at DNS-TTL speed, and the teardown is provable with the same public tools that proved the identity.

```
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:c2::51'}})
# after the TTL:
dig -x 2a04:2a01:c2::51 +short                          # -> empty
curl -s https://whisper.online/verify-identity/2a04:2a01:c2::51   # -> {"is_whisper_agent": false}
```

### The attribution graph

When a manifest carries a signer you distrust (an impostor cert claiming to be a wire service, a suspicious host distributing "signed" fakes), turning that into "known-bad" or "clean" is a read-only query against the public graph API. Attribution survives IP rotation because it fingerprints the operator and the tooling (ASN and hosting genealogy for cloud rotation, a `JA4/JA3` client fingerprint for a residential-proxy swarm), not the ephemeral egress IP.

```
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  --data-urlencode "q=CALL whisper.identify('185.220.101.1')"
# -> what the address is, who operates it, threat-intel reputation, relationships:
#    a reproducible, replayable JSON evidence chain a fact-check desk or a court dossier can replay.
```

The read-only verbs (`identify`, `origins`, `walk`, `variants`, `history`) run the same way, over an infrastructure-and-threat-intelligence graph of billions of nodes.

## The map, at a glance

Each row is a framework or standard, what it asks, a glance **fit** grade, our verdict, and the shipped evidence behind it. Read the verdict column first: it is the load-bearing part. Fit legend: ● strong · ◐ partial · ○ stretch · ✗ not applicable.

| Framework · requirement | What it asks for | Fit | Verdict | Whisper evidence (shipped) |
|---|---|---|---|---|
| **EU AI Act Art.50(2)**: provider marking | Mark AI-generated / manipulated output in a machine-readable, interoperable, robust format | ● | DIRECT-ADDITIVE | A C2PA-signed output is a machine-readable mark; a public DNSSEC/DANE signer anchor advances the interoperable/robust bar |
| **EU AI Act Art.50(4)**: deployer disclosure | Disclose deepfakes and AI-generated public-interest text | ● | DIRECT-ADDITIVE | A publicly verifiable signer proves *who* disclosed *what*, *when*; `op:lookups` evidences the disclosure was checked downstream |
| **EU AI Act Recital 133** | Names acceptable techniques, incl. "cryptographic methods for proving provenance"; detection accessible to the public | ● | DIRECT-ADDITIVE | Cryptographic provenance is an enumerated technique; a public DNS/DANE anchor is exactly the "accessible to the public" verification path |
| **C2PA claim signer** (COSE_Sign1 / `x5chain`) | An X.509 EE cert; trust anchors are pluggable validator config | ◐ | COMPLEMENTARY | Derive the EE signer's `/128` from its key; DANE-anchor it as a legitimate alternative trust source: additive, never a fork |
| **C2PA Trust List + Conformance** | A C2PA-managed list of X.509 anchors; assurance levels 1/2 via a security submission | ○ | COMPLEMENTARY | A pluggable anchor today; a Conformance submission and the CAWG `signer_payload.sig_type` route are *proposed*, **not** Trust-List membership |
| **CAWG Identity Assertion 1.2** | Bind a human/org creator; `did:web` issuer + `cawg.web_site` URI are DNS-native | ◐ | COMPLEMENTARY | A DNSSEC-anchored domain is a first-class `did:web` root; DANE-bind the `cawg.x509.cose` cert to turn "well-formed" into "trusted" |
| **ISO 22144** (DIS): Content credentials | Standardises the C2PA architecture into procurement / regulatory language | ◐ | COMPLEMENTARY ¹ | Raises demand for accessible signer identity; the same DANE-anchored signer serves an ISO-22144-framed procurement |
| **US: NO FAKES / COPIED / FTC** | Digital-replica right; provenance-standard direction; impersonation liability (bills + a rule) | ○ | COMPLEMENTARY | Attributable signed provenance aids takedown/licensing and a defensible "what we did/didn't emit" record: softer, still emerging |
| **Provenance = truth** | N/A | ✗ | DO-NOT-CLAIM | A signature proves *who* + integrity, never that a claim is true: a valid sig can sit on a photographed deepfake-on-a-screen |
| **Deepfake detection** | N/A | ✗ | DO-NOT-CLAIM | Whisper is not a classifier; it anchors the signer, it does not judge the pixels |
| **Surviving a manifest-stripping re-encode** | N/A | ✗ | DO-NOT-CLAIM | Signing cannot prevent stripping (that is watermarking / soft-binding's job); analytics can only *hint* at it |
| **"Makes you Art.50 / C2PA compliant"** | N/A | ✗ | DO-NOT-CLAIM | The AI Act is technology-neutral and its harmonised standards are still being written: we "evidence/strengthen", never "guarantee" |

¹ ISO/DIS 22144 is a *draft*, pre-publication, derived from C2PA 2.1; some sources cite the final designation as **ISO/IEC 22144**. Verify ISO vs ISO/IEC against the ISO catalogue before quoting it in a procurement document. See the caveats below.

## DIRECT-ADDITIVE: EU AI Act Article 50

Where Article 50 asks a question the shipped primitives help answer, Whisper is a concrete input to your evidence, never the whole obligation. The Act is technology-neutral: it names goals and enumerates techniques, and leaves the "how" to harmonised standards and the AI Office's Code of Practice, both still being drafted through 2026. Read every claim below as "strengthens/evidences," not "satisfies."

Article 50's machine-readable mark is the C2PA manifest's `digitalSourceType` assertion; Whisper anchors the *signer* of that manifest so the mark is bound to a real, publicly resolvable identity: the interoperable, public verification path Recital 133 describes. The pipeline: an AI output flows into a C2PA manifest carrying `c2pa.created` + `digitalSourceType: trainedAlgorithmicMedia` (the machine-readable "this is AI" mark); the manifest's claim is signed under a Whisper-anchored signer whose `/128` is DNSSEC + DANE-EE pinned (the "who signed it" layer); any verifier confirms both the mark and the signer publicly. Whisper never asserts "this is AI": that assertion is the manifest's; a bare signature proves only *who* + integrity. And `op:lookups` shows who verified this output, and where the disclosure was checked.

### Article 50(2): machine-readable marking of AI output

Art.50(2) obliges providers of generative-AI systems to ensure outputs are *"marked in a machine-readable format and detectable as artificially generated or manipulated,"* with solutions *"effective, interoperable, robust and reliable as far as technically feasible."* A C2PA Content Credential (a `COSE_Sign1` claim signature over assertions that include a hard binding to the asset bytes) is exactly such a machine-readable mark, and the "this is AI" content is the manifest's `c2pa.created` action plus a `digitalSourceType` of `trainedAlgorithmicMedia`. What Whisper adds sits on the *interoperable / robust* half of that bar: when the signer is anchored in public DNSSEC/DANE, any verifier can confirm the signer with no gatekeeper and no CA phone-home. That's a more open, more robust verification path than a curated allow-list. See [Sign agent outputs](/docs/sign-outputs) for a signing tool or agent that signs its own C2PA claim under a Whisper-anchored identity.

> **The honest limit.** A bare signature proves *who signed* and that the bytes are intact. It does **not**, by itself, declare content AI-generated. The "this is AI" claim must ride in the C2PA manifest's assertion; Whisper anchors the signer under it. We never present the signature as the AI mark.

### Recital 133: an enumerated technique

Recital 133 is the most quotable line for this page. It lists acceptable techniques *"such as watermarks, metadata identifications, cryptographic methods for proving provenance and authenticity of content, logging methods, fingerprints…"* and says detection methods should be *"made accessible… to enable the public to effectively distinguish AI-generated content."* Cryptographic provenance is therefore an *enumerated* technique, and "accessible to the public" is precisely what a public DNSSEC/DANE anchor plus keyless verification answers, versus a private, curated allow-list a member of the public cannot consult. This is the strongest honest alignment on the page; it is still alignment with a *recital* (interpretive guidance), not a binding conformity test.

### Article 50(4): deployer disclosure, made provable

Art.50(4) requires deployers to disclose deepfakes and AI-generated text published to inform the public on matters of public interest. A publicly verifiable signer turns that disclosure into a durable, non-repudiable record: *who* disclosed *what*, and *when*. It's anchored to a resolvable identity rather than a claim in a CMS. And because verification of a DANE-anchored signer generates lookups, `op:lookups` gives you evidence the disclosure was actually checked downstream.

```
# A signer proves its disclosure identity to a regulator or platform: keyless, no shared secret
whisper verify --trustless 2a04:2a01:c2::51
✓ DNSSEC chain valid to the IANA root   ✓ DANE-EE (TLSA 3 1 1) matches the signer's key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32   identity: VERIFIED (our API never trusted)

# Evidence the disclosure was checked downstream: who resolved the signer, and when
curl -s https://whisper.online/ip/2a04:2a01:c2::51/lookups | jq
```

Out of scope, by design: Art.50(1) (AI-interaction disclosure) and Art.50(5) (timing/manner of delivery) are not identity-signer requirements, and we do not map to them. Timeline: the Act entered into force 1 Aug 2024; Art.50 applies 2 Aug 2026; a provisional legacy grace (to ~2 Dec 2026 for models already on the market) is under discussion in the 2026 AI Omnibus. Treat it as a short reprieve to watch, not settled law. Fines under Art.99 reach €15M or 3% of worldwide turnover.

## COMPLEMENTARY: alongside C2PA, never a fork

The C2PA ecosystem defines the manifest, its Trust List, and the CAWG identity assertion. Whisper does not, and must not claim to, *be* any of those. It complements them: it fills C2PA's own stated dependency on an identity ecosystem, it is a **legitimate pluggable trust source** (the spec makes trust lists and anchors config inputs to the validator, so a DANE/DNSSEC anchor is an alternative source, not a fork), and where a certificate is in play it can [DANE-anchor](/docs/dane) it under a DNSSEC-signed domain.

C2PA lets a validator plug in *any* trust source. A manifest's claim signature identifies a signer EE cert by serial, and a verifier trusts it through one of two pluggable sources: the gate-kept **C2PA Trust List** (commercial certs ~$289/yr, a small recognized-CA coalition, off-list certs display "unknown source"), or a **Whisper DANE anchor**: a TLSA record under the signer's own DNSSEC-signed domain, self-verifying with no gatekeeper and per-unit revocation at DNS-TTL. Both feed the verifier; the Whisper path also emits an `op:lookups` event: who verified your content. It is a complementary source, not a competing standard.

### C2PA Trust List & Conformance Program

A C2PA verifier trusts a signer if its cert is on an explicit allowed list or chains to a trust anchor on a configured list. Crucially, **C2PA does not mandate any particular list or PKI**: trust lists and anchors are pluggable configuration inputs to the validator. That is the honest hook: a DANE/DNSSEC anchor is a legitimate *alternative* trust source, not a modification of C2PA. The official C2PA Trust List and Conformance Program (launched mid-2025) is a C2PA-managed list of X.509 anchors gated by a Product Security Architecture submission and assurance levels. And it is where the ecosystem's "no Let's Encrypt for C2PA" gap bites: no free, automated path exists for an independent creator, a small newsroom, or an AI agent to get a recognized cert; commercial signing certs run about $289/yr; the recognized-CA set is a small coalition.

> **Where we honestly stand.** A Whisper-anchored signer is a pluggable trust source *today*, and it slots into CAWG's already-DNS-native identifiers (below). It is **not** official C2PA Trust-List membership, and this page never says it is. A Conformance-Program submission and a CAWG `signer_payload.sig_type` for a DANE-anchored credential are *proposed*: a route we are pursuing with the standard, labelled roadmap, never presented as approved.

### CAWG Identity Assertion 1.2

CAWG's Identity Assertion (v1.2, DIF-ratified 2025-12-15) binds a human or organisation creator (distinct from the tool/device claim signer) by having a credential holder sign a `signer_payload` that hash-references the manifest's assertions, via `signer_payload.sig_type`. Two of its identifiers are already DNS-native, which is where Whisper fits cleanly:

- The identity-claims-aggregation VC `issuer` is a **`did:web`** in real deployments, and `did:web` resolves through DNS + HTTPS. A Whisper DNSSEC-anchored domain identity is a first-class `did:web` root, so you can run your *own* issuer that verifiers resolve via DNS rather than depending on a third-party aggregator. See [did:web & VCs](/docs/did-web).
- `verifiedIdentities[]` carries a required **`cawg.web_site`** URI: a domain the actor controls. DANE-binding that domain (and the `cawg.x509.cose` org cert) turns CAWG's *"well-formed but unrooted"* state into *"trusted"* without an S/MIME CA.

For CAWG, `device_id` is the CAWG identity itself. This is the seam a DNSSEC/DANE signer slots into with the least friction: an org identity you own, resolvable by anyone, revocable in one call.

### ISO 22144, Authenticity of information: Content credentials

The C2PA 2.1 architecture is being standardised as **ISO 22144, "Authenticity of information: Content credentials,"** currently at **ISO/DIS** (draft, pre-publication). That matters commercially: an ISO number pulls Content Credentials into procurement and regulatory language, dovetails with the AI Act's marking goal, and raises demand for an *accessible* signer identity: the same DANE-anchored signer serves an ISO-22144-framed procurement unchanged. Because the standard is still a draft, we cite it as forthcoming and flag one thing to verify: some sources give the final designation as **ISO/IEC 22144**. Confirm ISO vs ISO/IEC against the ISO catalogue before quoting a clause number in a contract.

## DO-NOT-CLAIM: what a signature does not prove

The most useful rows on a compliance page are often the ones a vendor omits. These are the claims a valid signature does not support. We state them plainly so nobody plans against an over-claim, and so a skeptical reviewer trusts the rest of the page:

- **Not official C2PA Trust-List membership.** A pluggable trust source is not a coalition slot. Off-list, a strict validator may still show "unknown source" until it is configured to consult the DANE anchor.
- **Not a C2PA-conformance or EU-AI-Act-conformity route.** No product "makes you compliant." The AI Act is technology-neutral and its harmonised standards and Code of Practice are still being written; we evidence and strengthen, we never guarantee.
- **Provenance is not truth.** A signature proves *who* signed and that the bytes are intact: never that the content is real. A perfectly valid signature can sit on a photograph *of a deepfake on a screen*. The first-mile capture gap is real and unsolved by signing.
- **Not a deepfake detector.** Whisper anchors the signer; it does not classify pixels or audio. Detection is watermarking, forensic, and human-review work: adjacent, not ours.
- **Does not survive a manifest-stripping re-encode.** A screenshot or a transcode can drop the manifest entirely; signing cannot prevent that (durable watermarking and soft bindings are that job). A public anchor can only *hint* at stripping: a sharp drop in verifications of content you know is circulating is a signal, not proof.
- **Privacy is a design constraint, not an afterthought.** Embedding a verified *personal* identity can endanger a journalist, a source, or a whistleblower. Anchor at the *org/domain* level, and support pseudonymous signer identities: never force a creator to dox themselves to be verifiable.

## Nothing signed in the dark: the transparency-log audit trail

Every identity mint and every revocation lands in a public, append-only [Merkle transparency log](/docs/transparency) (RFC 6962 `tlog-tiles`), with Ed25519-signed C2SP checkpoints, each root anchored to Bitcoin via [OpenTimestamps](/docs/opentimestamps). For a regulated content operation that is something a database row cannot give: a *non-repudiable* answer to "when was this signer commissioned, and when was it revoked," provably not back-dated, provably in order. It pairs naturally with C2PA's own tamper-evidence (the hard binding) and with Art.50(4)'s disclosure trail.

```
# A signer's ordered lifecycle (issuance, any rotations, revocation), keyless
curl -s https://whisper.online/ip/2a04:2a01:c2::51/transparency | jq

# The signed log checkpoint + its Bitcoin anchor: the tamper-evidence root
curl -s https://whisper.online/checkpoint
# -> a C2SP signed note; the root is OpenTimestamps-anchored to Bitcoin
```

> **Honest status.** The log is tamper-evident, Ed25519-signed and Bitcoin-anchored *today*, but it is **not yet independently witnessed** (our two authoritative nodes co-signing is availability, not independence). It already speaks the C2SP `tlog-witness` protocol, so an external witness can co-sign; until one does, treat the guarantee as tamper-*evident*, not third-party-attested. It is GDPR-compatible: leaves are salted opaque commitments with selective disclosure, so erasing the salt renders a leaf's meaning unrecoverable while the proofs stay valid, which matters when a signer identity touches a real person.

## Evidence you can hand a standards or procurement reviewer

The point of every primitive above is that the reviewer does not have to trust Whisper. Each artifact is reproducible from the internet's own records with stock tools: the same `--trustless` walk any resolver could run. A signer-identity evidence bundle for an Art.50 file, a C2PA vendor assessment, or an ISO-22144-framed procurement looks like this, and every line is checkable without an account:

```
# SIGNER IDENTITY: genuine and current, verified to the IANA root (no Whisper API trusted)
whisper verify --trustless 2a04:2a01:c2::51

# THE MARK: the address is the signer; forward-confirmed reverse DNS names it
dig -x 2a04:2a01:c2::51 +short
signer-0a1b2c3d.press.example-news.org.

# VERIFICATION ANALYTICS (Art.50(4)): who checked this signer, and when
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:c2::51', window:'90d'}})

# NON-REPUDIATION: the timestamped lifecycle leaf (commissioned, rotated, revoked)
curl -s https://whisper.online/ip/2a04:2a01:c2::51/transparency

# CONTAINMENT: revoke one compromised signer worldwide, at DNS-TTL, provably
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:c2::51'}})
```

And because a signing tool or agent can bind its forge-proof `/128` and [sign its outputs](/docs/sign-outputs) under it, and can have its egress governed (default-deny [`policy`](/docs/egress-governance), `firewall` and `budget` for a live signing agent), the reviewer gets the full arc a lifecycle assessment expects: a signer that is issued, verifiable by anyone, watchable, governable, and retired on `revoke`.

## Verification analytics & export

The evidence above is pullable now via `op:lookups`, `op:logs` and the graph API, and it exports to **Splunk** today as signed, replayable JSON mapped to CEF / ECS fields, useful for a platform running verification at ingestion scale. Broader connectors are on the roadmap, labelled honestly so nobody plans against vapour:

| Destination | Status |
|---|---|
| Splunk (signed JSON → CEF / ECS) | **Shipped** |
| Microsoft Sentinel connector | **Shipped** |
| OpenCTI | **Shipped** |
| STIX 2.1 / TAXII feed | Roadmap |
| C2PA Conformance submission · CAWG `sig_type` route | Roadmap · proposed |

Until the roadmap items land, the same records are already reachable: the exports are a convenience layer over evidence you can pull today.

## What this is, and is not

Whisper anchors **one** thing: the identity of the *signer* at the DNS/transport boundary. It is deliberate about what it does not touch.

- It is **not** the C2PA manifest, the watermark, or the "this is AI" assertion. Those stay in the Content Credential where they belong. Whisper anchors *who signed*, and complements the manifest; it never replaces it.
- It does **not** reach inside the first-mile capture, the durable watermark, or the pixels. Those keep their own mechanisms; a Whisper DANE-anchored signer complements them at the identity layer without cross-signing.
- These framework mappings are *proposed* and interpretive, not vendor- or regulator-endorsed, and no organisation is named as a breach victim: the incidents referenced (a 2025 device-cert revocation; the trust-list equity gap) are drawn from public research at the class level only.

Everything described as working is checkable, today, with `dig`, `curl` and one control-plane call. Everything on the roadmap is labelled as such. That is the whole contract of this page.

## Next

- [Signer & C2PA identity](/docs/industries/content/signer-identity): how the signer-derived `/128` is computed from the C2PA claim-signer's key, and why the cert serial (or CAWG identity) is the natural domain separator.
- [Provenance-gap cure](/docs/industries/content/provenance-gap-cure): the same identity, applied to the trust-list "unknown source" gap at the point of verification.
- [Sign · verify · who-verified](/docs/industries/content/content-recipes): runnable recipes that generate exactly the artifacts this page maps to a requirement, including the `op:lookups` "who verified my content" stream.