Trust & Security
Production C2PA claim signing is designed around HashiCorp Vault Transit: the private key is generated inside Vault and every signature is produced by Vault itself. The signing service sends digests in, gets signatures out — no process outside Vault can read the key material.
Krusade signs all customer content under a single Krusade certificate. You never manage certificates, CSRs, or key rotation — manifests read as signed by Krusade as the claim generator. We are not a certificate authority — we do not issue certificates today. Bringing your own certificate (which we then manage) is planned on Enterprise.
Local and current deployments sign with a development certificate, so verifiers report the issuer as untrusted. A CA-issued C2PA certificate (chained into the C2PA Trust List) is the next milestone on our public roadmap; when it lands, custody moves to Vault Transit on day one.
Manifest construction runs in a dedicated Rust service built on c2pa-rs (the Content Authenticity Initiative's reference implementation), reachable only from the API over TLS with a shared service credential — never exposed to the internet.
API keys, session tokens, and identity bindings are stored as SHA-256 hashes or provider-bound WorkOS identities — no passwords are stored at all. A database leak does not yield usable credentials.
Your krsd_ API key is displayed a single time at creation or rotation. We cannot recover it — only replace it.
Google and GitHub sign-in use state validation and PKCE, and require verified email addresses. No fake or placeholder login flows.
Card details go directly to Stripe. Webhook events are verified with constant-time HMAC signature checks and replay-window enforcement; credit grants are idempotent, so a replayed event can never double-credit or double-charge.
Public traffic terminates at a hardened reverse proxy with automatic certificates; internal API-to-signer traffic is TLS as well.
Only the API and site are publicly routed. The database, cache, metrics, and Vault are internal-only with no public ports. Intrusion detection (CrowdSec) fronts the proxy.
The signing service runs with hard memory, CPU, and process limits, and upload sizes are capped — a malicious or malformed file cannot exhaust the host.
Metering reserves quota or credits before signing and refunds on any failure. You are only ever charged for signatures that succeeded.
Signed files carry standards-compliant C2PA manifests — plus IPTC, EXIF, CAWG, PLUS, and XMP metadata where you add it — that verify in Adobe Content Credentials, c2patool, and any other conformant verifier. No Krusade software needed to check authenticity.
Anyone can verify any file against our public verify endpoint without an account. Provenance you can't check freely isn't provenance.
Browser verification loads the current C2PA signing and timestamp trust anchors from /api/trust-list. Responses use ETag and max-age caching, so browsers reuse an unchanged list and revalidate it efficiently. An out-of-band service refreshes the mounted anchors from a reviewed, commit-pinned source; the isolated claim generator never fetches trust lists from the internet.
Signing and verification are built on c2pa-rs, maintained by the Content Authenticity Initiative, and exercised by an internal conformance test harness on every build.
Security review, compliance questionnaire, or architecture deep-dive — talk to us directly.
Contact security support