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.

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:

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.

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.

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.

^¹ 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(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 for a signing tool or agent that signs its own C2PA claim under a Whisper-anchored identity.

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 it under a DNSSEC-signed domain.

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.

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.
• 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 (RFC 6962 tlog-tiles), with Ed25519-signed C2SP checkpoints, each root anchored to Bitcoin via 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

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 under it, and can have its egress governed (default-deny policy, 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:

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: 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: the same identity, applied to the trust-list "unknown source" gap at the point of verification.
• Sign · verify · who-verified: runnable recipes that generate exactly the artifacts this page maps to a requirement, including the op:lookups "who verified my content" stream.