← back to Trust Center

Security questionnaire prefill

Status: pre-filled answers to the questions enterprise procurement teams ask most often. Use this as a starting point for any vendor security questionnaire (SIG Lite, CAIQ, custom). Update specifics before sending; the boilerplate text is current as of 2026-05-19.

Company and product

Q. What does the product do? Prova is the AI control plane. Every consequential AI invocation (model call, agent run, tool use, autonomous decision) flows through or mirrors to Prova and gets a tamper-evident receipt. Customers use Prova for audit (the Audit Vault), enforcement (the Policy Engine with 19 built-in policies + custom JSON-DSL), detection (5 inline detectors), inventory (passive + active + network-layer discovery), and risk scoring.

Q. Who owns the product? Cobound. Prova is the product; Cobound is the legal entity.

Q. Where is the company incorporated? United States.

Hosting and data residency

Q. Where is customer data stored? The default production deployment runs on Vercel (frontend / API gateway) and Supabase (Postgres) in the US East region. Self-hosted deployments (deploy/docker-compose.yml, deploy/helm/) let customers run Prova in their own VPC including air-gapped environments.

Q. Can data be pinned to a specific region? Yes, via the self-hosted bundle. For the managed offering, multi-region options ship on the Enterprise plan; contact sales for the specific region you need.

Q. Is there a multi-region failover story? The managed offering is single-region today. The Enterprise plan SLA allows for documented multi-region build-out as a contracted scope of work; this is not a stock feature.

Encryption

Q. Encryption in transit? TLS 1.2+ on every external interface. HTTPS-only for the dashboard and API. HSTS enabled.

Q. Encryption at rest? AES-256 at the storage layer (Supabase Postgres + Supabase Storage, inheriting AWS RDS encryption). Customer secrets (API keys) are hashed with SHA-256 before storage and never recoverable in plaintext.

Q. Signing keys? Receipt integrity is enforced by Ed25519 signatures. Production signing keys can be backed by a customer KMS / HSM via the sidecar contract at deploy/signer-sidecar/README.md. Without KMS, keys are configured via the PROVA_SIGNING_KEY_PEM env var and rotation is operator-driven.

Authentication and authorization

Q. Authentication method for end users? Email + password or magic link via Supabase Auth. SSO via SAML / OIDC is on the roadmap for Enterprise; not yet wired.

Q. API authentication? Bearer API key with a per-key role (developer / contractor / security / audit). Keys are 256-bit random, prefixed prv_, stored as a SHA-256 hash. Key roles map to a permission matrix at lib/auth/roles.ts.

Q. RBAC? Five roles (owner / developer / security / audit / contractor) with a documented permission matrix. Org members are stored in org_members, permissions enforced at every server action and API endpoint via lib/auth/guard.ts.

Q. Multi-factor authentication? Inherited from Supabase Auth's MFA support. Available on the customer's account at the auth-provider level.

Audit logging

Q. Is there an audit trail of admin actions on the platform? Yes. Every admin action (API key create / revoke, policy toggle, policy create / update / delete, member invite / role change / remove, audit export, risk config update, budget cap update, signing key rotation) emits a signed operational audit event. These rows live in the same audit_events table as customer AI decisions and are filterable on the audit dashboard by kind=operational.

Q. Can the audit trail be exported? Yes. GET /api/v1/audit/export returns the signed receipts for the requesting org. Available to API keys with the audit.export permission and to dashboard users with the audit.export role permission.

Q. Receipt integrity verification? Every receipt carries an Ed25519 signature over a canonical JSON of payload + findings. Verification works offline: fetch the public key from /api/v1/keys/{key_id} once, then verify any receipt's signature locally. Full walkthrough at /docs/audit.

Compliance

Q. SOC 2? We have not started a SOC 2 audit yet. We plan to begin SOC 2 Type 1 when we onboard our first design partner. Until then, our security documentation (this questionnaire, the DPA, and the subprocessor list) is available under NDA.

Q. EU AI Act readiness? The product is purpose-built to provide the audit and risk-management evidence the EU AI Act requires for high-risk AI systems. See /risk-score and /audit-vault for the supporting features.

Q. HIPAA / FDA / SEC? Prova does not handle PHI on the customer's behalf. Customers running healthcare workloads can ship Prova self-hosted in their HIPAA environment. The phi_in_prompt and medical_decision_no_hitl built-in policies are intended to help customers stay compliant in their own deployments.

Q. GDPR? Prova acts as a data processor for customer audit data. Data is deletable on request via the Trust Center contact at /trust. The DPA is at /trust/dpa.

Incident response

Q. Incident response plan? Sev 1 incidents (outage, suspected data exposure, signing key compromise) trigger paging within the on-call rotation, status page acknowledgement within 30 minutes, and direct customer notification within 2 hours of confirmation.

Q. Past incidents? Maintained on the status page at /status. Pre-launch incidents are documented internally; nothing customer-impacting at production scale as of {EFFECTIVE_DATE}.

Q. Vulnerability disclosure? security@cobound.dev per /.well-known/security.txt. Reports acknowledged within 72 hours. No bug bounty program at this stage.

Sub-processors

The current list of sub-processors is at /trust/subprocessors. Material adds are announced with at least 30 days notice via the Trust Center.

Self-hosted option

For customers who cannot use the managed offering, Prova ships a self-hosted bundle (deploy/docker-compose.yml for single-node, deploy/helm/ for Kubernetes). The self-hosted build runs entirely within the customer's environment, including air-gapped (no outbound network) with a KMS-backed signer. See deploy/README.md for the full procedure.

For anything not covered here, reach out to support@cobound.dev and ask. Our promise is that you will get a real answer in 48 hours, not a "we'll get back to you."