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: application in preparation (Generator Product, Backend class, Assurance Level 1 target). On listing, signing moves to a trust-list certificate by configuration, and this page will link the Conforming Products List entry.

• 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) accompanies our conformance application and 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.