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. Production signing now uses the SSL.com-issued Oprindo credential under Hamsa Software LTD, chaining to the C2PA Trust List, with an RFC 3161 timestamp chaining to the C2PA TSA Trust List. The private signing key remains in AWS KMS. Early Production Access continues while the operational work for general availability is completed. Check it yourself with Adobe's public verifier or c2patool. Expected result: a readable Content Credential with the AI-generated indication, signer Hamsa Software LTD / Oprindo, a trusted signing credential, and a trusted timestamp. This is a deliberately AI-declared test fixture; credential validation does not establish whether the depicted content is true.

c2patool-report.json — output of the current c2patool (c2pa-rs) against that file with the C2PA CA and TSA trust lists: signingCredential.trusted, claimSignature.validated, timeStamp.trusted, and timeStamp.validated, with no validation failures. The sample applies signed metadata; no imperceptible watermark is applied.

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 when its fields or links do not match. Try it: flip one character in the CSV and run it again. Establishing that an export is complete also requires checking its boundaries against a trusted checkpoint.

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. It rejects untrusted sample credentials or timestamps and is included in the production website deployment workflow. Run it yourself: node verify-proof-bundle.mjs https://oprindo.com https://api.oprindo.com.

• Production signing: trusted. Supported JPEG/PNG claims use the SSL.com-issued Oprindo credential and a trusted timestamp. Check the current deployment at signing-info. Every signing response, verification report, and evidence record discloses its trust state.
• Development and test use: the separate development deployment remains pre-conformance. Test-key manifests carry a visible sandbox marker. Older claim structures can receive a pre-conformance credential; use JavaScript SDK 1.0.0 or later, or Python SDK 1.0.1 or later, and inspect the returned trust state.
• 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. Product conformance and an individual asset's signature, credential, and timestamp validation are separate checks.

• 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 with a separate execution role — 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: release checks include HIGH/CRITICAL advisory scans (dependency audit and OSV); 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.