Verdra · Security architecture
How an Evidence Package is signed and sealed.
Verdra Record's integrity model is designed so a Verdra Evidence Package is admissible and tamper-evident without requiring trust in Verdra. Capture happens inside the customer's environment; signing keys are customer-held; storage is customer-controlled WORM; tamper-evidence is content-addressed and time-stamped by an external authority.
In plain English
Three guarantees you don't have to take Verdra's word for: (1) the record is signed by your company's own keys, not Verdra's, so no one at Verdra can sign anything on your behalf; (2) the record lives in storage you own and lock down (an S3 bucket with retention rules, for example), so Verdra has no way to alter or delete it; (3) a third-party timestamping service stamps each record at the moment of capture, so no one — not Verdra, not you — can backdate it after the fact.
The rest of this page is the technical version of those three guarantees, written for your security team.
1. Threat model
The system protects against four families of threat:
- Post-hoc tampering with the record after the disputed action.
- Reconstruction of state at the time of action from inferior logs.
- Repudiation by either party of what the agent was configured to do.
- Vendor capture: any architecture in which Verdra has the technical ability to alter the record unilaterally.
The integrity model places Verdra outside the trust boundary for record contents. The customer's keys sign; the customer's storage holds; an external timestamp authority countersigns; the schema and rulebook are public.
2. Capture flow
Single-action capture · client-side
1. Action dispatchagent runtime hook
↓
SDK intercepts at runtime hook. No agent code change; instrument LangGraph, LangChain, AutoGen, CrewAI, Semantic Kernel, OpenAI/Anthropic/Google, or a custom runtime.
2. Strata captureS(a) S(b) S(c) S(d)
↓
Four strata sealed in <25 ms: transaction, configuration, behavior, capability. Configuration is captured by reference (prompt hash, tool inventory, model version) so the Evidence Package stays compact.
3. Content addressBLAKE3-256
↓
Package gets a content-addressed identifier. Any modification produces a different ID; references that resolved at capture time fail to resolve if anything was changed.
4. Customer signaturecustomer-held keys
↓
Customer-held key signs the package. Verdra never sees the private key; KMS integration via AWS KMS, GCP KMS, Azure Key Vault, or HSM at customer election.
5. RFC 3161 timestampexternal TSA
↓
External timestamp authority countersigns. RFC 3161 token from a third-party TSA establishes the record existed at the captured moment, independent of Verdra and of the customer's own time.
6. WORM storagecustomer-controlled
·
Write-once storage. S3 Object Lock, GCS retention policies, Azure Blob immutability, on-prem WORM, or a customer-elected equivalent. Verdra has no write path.
3. Integrity primitives
Hashing
BLAKE3-256
Content-addressed identifiers. Faster than SHA-256 with equivalent collision resistance; package ID is the BLAKE3 of the canonical-serialized package.
Signing
Ed25519 (default)
Customer-held signing keys. ECDSA P-256 supported for FIPS-bound environments. Signing happens in-process via KMS integration; private keys never leave the customer boundary.
Timestamping
RFC 3161
External timestamp authority countersigns each package hash. Establishes tamper-evident time of existence independent of Verdra and the customer.
Storage
WORM, customer-held
Write-once-read-many storage chosen by the customer. AWS S3 Object Lock, GCS retention policies, Azure Blob immutability, or on-prem appliance.
Transport
TLS 1.3 + mTLS
Telemetry and operational signal transit over TLS 1.3. Customer-elected mTLS for endpoint authentication on inbound flows.
Schema
Public & versioned
Evidence Package schema is public, versioned per the Verdra Rules. Adjudicators of any venue can verify integrity without access to Verdra systems.
4. What Verdra cannot do
The architecture is designed so these claims hold without trusting Verdra in good faith:
- Verdra cannot read Evidence Package contents in normal operation. Packages live in customer storage. Verdra reads a package only when the customer's authorization scopes a specific dispute or audit.
- Verdra cannot sign on the customer's behalf. Signing keys live in the customer's KMS; Verdra has no derivation path.
- Verdra cannot backdate. RFC 3161 timestamps are issued by an external TSA; the timestamp chain is verifiable end-to-end without Verdra in the loop.
- Verdra cannot delete a package. Storage is customer-controlled; retention is a customer policy.
- Verdra cannot mutate the schema retroactively. Schema versions are pinned at capture time and re-deriving any prior version is deterministic.
5. Disclosure and engagement model
Production-stage deployments include a Data Processing Agreement scoping the customer/Verdra role under GDPR / Quebec Law 25 / CCPA, key-management responsibilities, retention defaults, and incident-notification windows. The DPA is shared at engagement; request the security packet for security-team review.
6. Roadmap
Forward commitmentsSOC 2 Type I report (Q4 2026), Type II window opening (Q2 2027). ISO 27001 certification on the same track. Cross-platform Evidence Package interoperability test suite (open source) targeted Q3 2026. Independent cryptographic review of the integrity model targeted Q2 2026 ahead of the first production design partner.
This page is a preview-stage description of Verdra Record's intended architecture. Specific control implementation, KMS integration patterns, and audit evidence are scoped per engagement.