Security FAQ

Encryption & Key Management

What encryption does VeriProof use for data at rest?

VeriProof applies three layers of encryption to stored data:

1. Infrastructure layer — Azure-managed Transparent Data Encryption (TDE) on PostgreSQL (AES-256) and server-side encryption on all Blob Storage
2. Application layer — Captured AI session content is additionally encrypted with AES-256-GCM before it ever reaches the database. Each tenant’s encryption key is derived from a master key in Azure Key Vault using HKDF-SHA256
3. One-way hashing — API key plaintext is never stored; only the SHA-256 hash is persisted. There is no way to recover an API key after initial creation

See Encryption at Rest for the full architecture.

Who holds my encryption keys?

By default, VeriProof manages all encryption keys in Azure Key Vault on your behalf. The application accesses Key Vault via Managed Identity — no key material ever appears in configuration files or environment variables.

Enterprise Federated customers can bring their own Customer-Managed Key (CMK). In this configuration, VeriProof’s Managed Application identity is granted get, wrapKey, and unwrapKey permissions against a key in your own Azure Key Vault. VeriProof never stores the key material itself.

Can I rotate my encryption keys?

Yes. Key rotation does not require downtime. The system re-wraps the data encryption key with the new master key; existing data remains accessible throughout. API keys can be rotated at any time from the Customer Portal — the old key is invalidated immediately upon rotation.

What happens to encryption keys if I terminate my VeriProof account?

All encryption keys associated with your tenant are deleted from Azure Key Vault as part of the account closure process. Once the deletion propagation period (typically 7 days for soft-delete-enabled vaults) has elapsed, the key material is unrecoverable and your data is cryptographically inaccessible. This is the mechanism underlying GDPR cryptographic erasure for the Standard Tier.

Is data encrypted in transit?

Yes. All external communication uses TLS 1.3 (TLS 1.2 also supported for compatibility; 1.1 and below are disabled). This covers: SDK-to-Ingest API, portal browser sessions, webhook deliveries, internal Function App communication, and database connections.

See Encryption in Transit for full details.

Blockchain Anchoring

What exactly gets written to the blockchain?

Only a 32-byte cryptographic commitment (a SHA-256 Merkle root) is anchored on Solana. No session content, no prompts, no responses, no metadata that could identify a user is ever written to the blockchain. The commitment is computed in the Notary service from the full session record; the session record itself stays in your PostgreSQL database.

Can someone use the blockchain record to reconstruct my data?

No. The Merkle root is a one-way commitment — you can verify that a session record matches a given root, but you cannot derive the original data from the root alone. It functions exactly like a cryptographic hash: computationally irreversible.

Is blockchain anchoring mandatory?

Anchoring is enabled by default and happens automatically within approximately 30 seconds of session ingest. You cannot disable anchoring for individual sessions through the API, as the anchor is what makes the tamper-evidence guarantee meaningful. Enterprise customers who have questions about custom anchoring cadences should contact their account manager.

How much does blockchain anchoring cost?

Each session anchor costs approximately $0.000035 on Solana. For most customers, the total blockchain cost across all sessions is negligible. See Blockchain Anchoring for a full cost model.

Can I verify a blockchain record independently?

Yes. You can independently verify any session anchor without using VeriProof’s APIs:

1. Retrieve the proof from the Customer Portal or API
2. Reconstruct the Merkle root from your session data using proof generation
3. Query the Solana transaction directly using any Solana explorer or RPC endpoint

This is one of the key properties that distinguishes blockchain anchoring from a signature-based approach — the record is independently verifiable by any third party who has access to the Solana network.

Trusted Execution Environments

What is a Trusted Execution Environment and why does VeriProof use one?

A Trusted Execution Environment (TEE) is a hardware-isolated computing environment where code runs in encrypted memory that even the cloud provider cannot inspect. VeriProof runs the Notary service — the component that computes Merkle roots and signs session commitments — inside a TEE (AMD SEV-SNP via Azure Confidential Containers).

This means that even if an attacker gained full administrative access to VeriProof’s Azure subscription, they could not tamper with or observe the Notary’s processing. See Trusted Execution Environments for details.

How do I know the Notary is actually running in a TEE?

Every session record includes an attestation token issued by Azure’s attestation service (MAA). This token is a signed JWT from a Microsoft-operated endpoint that certifies:

• The exact code image running inside the TEE (via a launch measurement hash)
• That the hardware is genuine AMD SEV-SNP
• That the environment has not been modified since boot

You can verify this token independently using the Azure MAA public key and the ARM64 container image digest published in our release notes. See Attestation for a verification code example.

Tenant Isolation

How is my data separated from other tenants?

VeriProof enforces tenant isolation at multiple layers simultaneously:

• Application layer: Every database query is filtered by CustomerId via an EF Core global query filter — a missing or wrong tenant ID returns zero rows, not another tenant’s data
• Database layer: Row-Level Security policies on PostgreSQL enforce the same tenant filter at the database engine. Even a misconfigured query cannot bypass it
• Encryption layer: Each tenant’s content is encrypted with a key derived from their own tenant-specific master key. A key compromise in one tenant does not expose any other tenant’s content

See Multi-Tenant Isolation for the detailed architecture.

Can VeriProof staff see my session data?

VeriProof staff use a separate Staff Portal backed by a separate database context that does not apply tenant-level row filtering. This is necessary for support operations.

Staff access is:

• Role-based (only roles with ViewSessions permission can query raw session data)
• Logged in a tamper-resistant audit trail
• Subject to VeriProof’s internal data handling policy

Enterprise Federated customers run the Notary in their own Azure subscription. VeriProof staff have no network path to that environment.

Authentication & API Keys

What is a compound API key and how does it work?

A VeriProof API key has the format vp_live_{tenantId}_{secret}. When you present this key, the Ingest API extracts the embedded tenantId prefix, looks up the stored hash for that tenant’s keys, and compares the SHA-256 hash of the presented secret. If the hash matches, the request is authenticated.

This design means a database dump of hashed API keys cannot be used to authenticate API requests — the plaintext secret is never stored. See API Authentication for the full model.

What API key scopes exist?

Scope assignment is immutable after key creation. To change a key’s scope, create a new key and revoke the old one.

Data Retention & Deletion

How long is my data retained?

The default retention period depends on your plan:

Blockchain anchors on Solana are permanent by nature — the commitment cannot be removed from the distributed ledger. However, without the session data to reconstruct the Merkle root, an anchor on its own proves nothing.

What happens to my data when I delete an organisation or account?

Deleting an organisation immediately removes the session data and queues the encryption keys for deletion. The cryptographic erasure process — which destroys the keys rather than the data — means the content becomes permanently unreadable even before physical deletion completes. Physical data deletion from all storage systems finishes within 72 hours.

Compliance Certifications

Is VeriProof SOC 2 certified?

VeriProof’s SOC 2 Type II audit is in progress. The controls assessed include the security, availability, and confidentiality Trust Service Criteria relevant to the VeriProof platform. See SOC 2 for current status and what controls are in scope.

Does VeriProof sign Data Processing Agreements?

Yes. Standard DPA terms are available in the Legal section. Enterprise customers may negotiate customised DPA terms as part of their contract. Contact legal@veriproof.app for Enterprise DPA requests.

Is VeriProof HIPAA-compliant?

VeriProof can be used in a HIPAA-regulated context under a Business Associate Agreement (BAA). VeriProof does not default to storing Protected Health Information — what data is captured is entirely determined by what your SDK adapter instruments. If your AI pipelines process PHI and you send it to VeriProof, a BAA is required before you go live. See HIPAA for guidance on PHI handling and BAA availability.

Reporting Security Issues

How do I report a vulnerability?

Email security@veriproof.app with reproduction steps. See Responsible Disclosure for our full policy, response SLAs, and coordinated disclosure timeline.

Next Steps

• Responsible Disclosure — reporting policy
• Penetration Testing — authorised testing policy
• Architecture Overview — system security architecture
• Compliance — detailed compliance coverage