Proof & security

A marked asset, independently validated

sample-ai-image.marked.jpg — an AI-declared JPEG marked by the live backend used for controlled Early Production Access — the same infrastructure, keys, and evidence chain paying customers use. The generally available Production API is not yet launched, and signing remains pre-conformance. Signer: Oprindo, operated by Hamsa Software Ltd: C2PA manifest, KMS-held signing key, RFC 3161 trusted timestamp. Check it yourself with Adobe's public verifier or c2patool. Expected result: a readable Content Credential with the AI-generated indication and an "issuer not recognised" caution — which is the honest display for a pre-conformance certificate (see trust status below).

c2patool-report.json — output of the current c2patool (c2pa-rs) against that file: sole validation status signingCredential.untrusted, signature and timestamp valid.

A sample evidence export

evidence-sample.csv · evidence-sample.pdf — the production evidence export for the same asset above: its mark.output record carries the same final-output hash and manifest-store label as the downloadable file, while the paired mark record carries the source hash and embedded XMP instance ID — so the whole workflow — mark, validate, evidence — can be cross-checked end to end. Per-asset records (timestamp, content hash, manifest id, certificate serial, trust state, marking method) with the hash-chain fields visible, mapped to Code Section 1 measures. Not an officially prescribed report format — an implementation account, exactly as labeled.

What each hash means — three different values, by design:

• mark record asset_sha256: SHA-256 of the source bytes received for marking (before any manifest is embedded) — the same value the SDK claim-signing path binds.
• mark.output record asset_sha256: SHA-256 of the exact bytes returned to the customer — hash the downloaded file and it matches this record; its manifest_id is the signed output's actual manifest store label, matching the c2patool report's active manifest.
• The C2PA hard binding (c2pa.hash.data): an exclusion-range hash over the output's content computed inside the manifest itself — validated by c2patool, not equal to either value above.

verify-evidence.mjs — a standalone, zero-dependency verifier (the chain algorithm is specified in its header comment). Recompute every hash yourself: node verify-evidence.mjs evidence-sample.csv — it reports the first broken record on any alteration, reordering, or removal. Try it: flip one character in the CSV and run it again.

verify-proof-bundle.mjs — the deployment gate itself, published: it re-validates every relationship between these artifacts (file hash ↔ evidence, report label ↔ evidence, embedded instance id ↔ evidence, PDF contents, offline-verifier acceptance, live verify endpoint, and stale-CDN detection) against the live URLs. This exact script runs as a mandatory, blocking step of every production deploy — a release that breaks any relationship fails. Run it yourself: node verify-proof-bundle.mjs https://oprindo.com https://api.oprindo.com.

• Signing today: pre-conformance. Manifests are signed under a self-managed certificate; validators display an unrecognised issuer. Every signature, verify response, and evidence record carries its trust state — we never present pre-conformance as trusted.
• C2PA Conformance Program: conformant — deemed conformant 28 July 2026 as a Generator Product at Assurance Level 1, and listed on the Conforming Products List under record 019fa058-c512-7f87-a214-4d8cfbda73ce. Conformance covers generation and validation of image/jpeg and image/png against C2PA specification 2.2. Signing moves to a trust-list certificate by configuration once that certificate is issued — see the bullet above, which describes what we sign with today.

• Key custody: claim-signing keys are generated in AWS KMS (eu-central-1) as non-exportable ECC P-256 keys. No process — including ours — ever holds private key material; signing is an audited KMS API call. Only one small, auditable service holds the sign permission.
• The signing gate: the signer refuses anything outside a fixed assertion allow-list, validated on the actual bytes being signed. The platform can state "AI-generated"; it cannot assert authenticity, human origin, or third-party identity — by construction, and covered by adversarial injection tests.
• Untrusted media isolation: the only code that parses uploaded media runs as an isolated serverless function (per-invocation microVM) — read-only code filesystem, hard memory/time caps, no database or signing permissions, and storage access limited to transient staging objects — with pre-parse guards (magic bytes, dimension and size limits). A hostile-input corpus (decompression bombs, truncations, malformed structures) runs in CI; a parser crash is contained and surfaces as a generic error.
• Verify uploads: processed transiently for parsing and not retained; no accounts, no tracking of the public verifier beyond IP rate limiting.
• Evidence integrity: append-only at the database layer (the application role holds no UPDATE/DELETE on evidence), hash-chained, re-verified before every export — an export over a broken chain is refused, never silently repaired. The chain tip is additionally anchored daily: signed with a dedicated KMS key and written to write-once (S3 Object Lock) storage, so even a database-level compromise cannot rewrite history without contradicting prior checkpoints. A public checkpoint feed is planned.
• Dependencies: CI blocks any release with known HIGH/CRITICAL advisories (audit + OSV scan on every change); the C2PA parsing library is version-pinned and every upgrade re-runs the adversarial suite plus independent validation with the current c2patool.

A full Generator Product Security Architecture document (threats, objectives, controls, IAM boundaries) was submitted with our conformance application and passed the program's architecture assessment. It is available to prospective customers on request.

• No independent penetration test has been completed yet; one is planned before general availability.
• No SOC 2 / ISO 27001 certification; the security baseline above is the current, honest state.
• The status page runs live checks from the visitor's own browser and states our incident commitments; an independent external uptime monitor with public history is planned before general availability.

Found a vulnerability? Tell us — we commit to acknowledging reports and will not pursue good-faith research. Report via the form below (stored first-party only), and see security.txt.