Technical Architecture

Built for the
age of autonomous
AI agents.

Veridex is the cryptographic authorization infrastructure beneath EYEspAI — a deterministic state machine that creates tamper-evident, pre-authorization receipts for every AI action inside your organization.

🔐 HSM-Backed Key Management
⛓️ Append-Only Audit Chain
📋 12 USPTO Provisionals
⚙️ SOC 2 · ISO 27001 · SEC · FDA Ready
System Overview
What makes Veridex
different by design.

Every enterprise AI governance tool records what happened. Veridex proves who authorized it — before it happened. That distinction is the entire compliance argument.

🔒

Pre-Authorization, Not Post-Log

The VX record is created at the moment of human authorization, before the AI action executes. Retroactive logs can be altered. A pre-authorization receipt cannot.

🧮

Deterministic State Machine

Every authorization event transitions the system through a formally defined, deterministic state sequence. Any deviation from the expected state is mathematically detectable.

🔑

HSM-Backed Key Architecture

Signing keys are generated and held inside Hardware Security Modules — keys never exist in software memory. Key-separated design means no single point of compromise.

📎

History-Preserving Revocation

Revoking an authorization does not delete the record — it appends a revocation event to the immutable chain. The full history is always preserved, including what was revoked and when.

🌐

Cross-Domain Vertical Architecture

The same core state engine powers distinct verticals: RAC (enterprise communications), VCAL (clinical AI), and Crypto Custody — each with domain-specific identity assurance tiers.

🔍

Independent Verifiability

Every sealed record can be cryptographically verified without platform access — the proof is in the hash, not in EYEspAI's continued operation. Your records are yours permanently.

The Core Insight

Jeremy Gomsrud was right: retroactive logs aren't enough for autonomous agents. When an AI agent takes an action autonomously, the compliance question isn't "did we log it?" — it's "can we prove a qualified human authorized this, before it happened?" Veridex answers that question with a cryptographic proof, not a database entry.

System Layers
The Veridex
authorization stack.

Six layers from human intent to cryptographic proof — each independently auditable, each formally specified.

L1

Identity Assurance Layer

Human identity is confirmed before any authorization is recorded. Three assurance tiers: L1 (session token), L2 (MFA + credential binding), L3 (biometric + hardware token). Clinical and regulated verticals require L2 minimum; custody and high-risk AI decisions require L3.

IAL
L2

Authorization State Machine

The deterministic core. Every authorization request enters as PENDING, transitions to CONFIRMED or DENIED based on identity verification outcome, and is permanently sealed. State transitions are one-directional and append-only — no record can be moved back to a prior state.

ASM
L3

Cryptographic Sealing Engine

On state confirmation, the engine binds: the authorization payload, the identity assurance level, the timestamp, the policy namespace, and the prior record hash — producing a SHA-256 chain hash that permanently links every record to its predecessor. Tampering with any field changes the hash of every subsequent record.

CSE
L4

HSM Key Management Layer

Signing keys are generated inside FIPS 140-2 Level 3 Hardware Security Modules. Keys never exist in application memory. The HSM signs the sealed record and returns only the signature — the key material is never exposed to the application layer. Key rotation and key ceremony logs are included in the audit chain.

KMS
L5

Namespace & Policy Registry

Every organization operates within a provisioned namespace that binds records to a specific policy version. Policy changes are themselves versioned and sealed — you can always prove which policy was in effect at the moment of any authorization. Supports multi-tenant enterprise deployments.

NPR
L6

Audit Export & Verification Layer

Records are exportable as structured audit bundles — JSON + signature files that can be verified independently using the public key registry. Formatted for SEC examination, FINRA investigation, FDA 21 CFR Part 11 submission, and EU AI Act documentation requirements. No platform access required for verification.

AEV
Record Structure
What a sealed VX
record contains.

Every authorization receipt is a self-contained, independently verifiable proof. Here is the canonical structure of a sealed Veridex record.

VX Authorization Receipt · JSON Schema
{
  "vx_record": {
    "record_id":
      "vxr_01HQZM7X...C6D5E0F1",
    "version": "2.1.0",
    "namespace":
      "org.massmutual.legal-ops",
    "policy_version":
      "pol_2025-Q1-v3",

    // Identity confirmed BEFORE action
    "authorizer": {
      "identity_id":
        "tony.curzio@massmutual.com",
      "assurance_level": "L2",
      // MFA + credential binding
      "role":
        "legal-ops-director",
      "auth_method":
        "TOTP+SESSION_BIND"
    },

    // What was authorized
    "action": {
      "type":
        "AI_COMMUNICATION_SEND",
      "domain": "RAC",
      "payload_hash":
        "sha256:a3f8e2c1...",
      "recipient_id":
        "ext_counterparty_001",
      "policy_tags": [
        "finra-compliant",
        "reg-bi-reviewed"
      ]
    },

    // Immutable state chain
    "state": "CONFIRMED",
    "prior_hash":
      "sha256:9b3c7f2a...",
    // links to previous record
    "sealed_at":
      "2025-03-15T14:22:07Z",

    // Cryptographic proof
    "proof": {
      "record_hash":
        "sha256:d7e4a9b2...",
      "hsm_signature":
        "sig_01HQZM7X...",
      "key_id":
        "hsm-key-2025-03",
      "algorithm":
        "ECDSA-P256-SHA256"
    }
  }
}
👤

Step 1 — Human Identity Confirmed

Authorizer authenticates at the required assurance level for the action type. Identity binding is confirmed and included in the record payload. No authorization without confirmed identity.

Step 2 — State Machine Transition

Record enters state PENDING. On identity confirmation, state transitions deterministically to CONFIRMED. The transition is logged with microsecond-precision timestamp. The state machine cannot be bypassed.

🔗

Step 3 — Chain Hash Computed

The sealing engine computes a SHA-256 hash binding the full payload to the prior_hash of the previous record. This creates an unbreakable cryptographic chain — altering any record invalidates every hash that follows.

🔐

Step 4 — HSM Signs the Sealed Record

The record hash is passed to the HSM for signing via ECDSA-P256. The signing key never leaves the HSM. The returned signature is appended to the record proof block. Record is now sealed and immutable.

📤

Step 5 — Audit Bundle Available Immediately

The sealed record is immediately available for export as a structured audit bundle. Any party with the public key can verify the record independently — no EYEspAI platform access required. Formatted for regulatory submission.

API Reference
Core authorization
endpoints.

RESTful API with webhook support. SDKs available for Python, Node.js, Java, and .NET. All endpoints require namespace-scoped API keys authenticated via mutual TLS.

Method Endpoint Description
POST /v1/authorize Create a new authorization request. Returns a record_id in PENDING state. Triggers identity assurance flow at the configured tier for the action type.
POST /v1/authorize/{id}/confirm Confirm a pending authorization after identity verification. Triggers state machine transition to CONFIRMED and initiates cryptographic sealing.
POST /v1/authorize/{id}/revoke Append a revocation event to an existing record. History-preserving — the original authorization and the revocation are both permanently retained in the chain.
GET /v1/records/{id} Retrieve a sealed record with full proof block. Includes chain hash, HSM signature, and verification instructions for independent validation.
GET /v1/audit/export Export a signed audit bundle for a specified time range and namespace. Returns ZIP containing JSON records, signature files, and public key certificate for independent verification.
GET /v1/verify/{hash} Verify a record hash against the chain without exposing the full record payload. Suitable for third-party auditor verification workflows.
GET /v1/policy/current Return the currently active policy version for a namespace, with its own sealed policy record — proving which policy governed all authorizations in a given period.
POST /v1/authorize · Example Request
// Create an authorization request
const response = await fetch(
  'https://api.eyespai.com/v1/authorize',
  {
    method: 'POST',
    headers: {
      'Authorization':
        `Bearer ${VX_API_KEY}`,
      'X-VX-Namespace':
        'org.massmutual.legal-ops',
      'Content-Type':
        'application/json'
    },
    body: JSON.stringify({
      action_type:
        'AI_COMMUNICATION_SEND',
      domain: 'RAC',
      assurance_level: 'L2',
      payload_hash:
        sha256(communicationContent),
      authorizer_id: currentUser.id,
      policy_tags: [
        'finra-compliant',
        'reg-bi-reviewed'
      ],
      metadata: {
        recipient: recipientId,
        workflow_id: workflowId
      }
    })
  }
);

// Returns immediately
const {
  record_id,
  state,
  identity_challenge
} = await response.json();
// state: "PENDING"
Compliance Mapping
How Veridex satisfies
each framework.

Every VX record is structured at the schema level to satisfy specific control requirements — not retrofitted after the fact.

SOC 2 Type II

CC6.1 · CC6.3 · CC7.2

Logical access controls, authorization change management, and system monitoring. The VX chain provides continuous evidence for all three control families across the audit period.

ISO 27001

A.9 · A.12 · A.18

Access control, operations security, and compliance. HSM key management satisfies A.10 cryptographic controls. Namespace policy versioning satisfies A.18 information security review requirements.

SEC / FINRA

Books & Records · Reg BI

Cryptographically sealed records with identity-confirmed authorization satisfy SEC Rule 17a-4 electronic records requirements. Reg BI suitability determinations can be recorded as L2-authorized VX events.

FDA 21 CFR Part 11

Electronic Records & Signatures

VCAL vertical is schema-compliant with 21 CFR Part 11 electronic signature requirements. L3 identity assurance maps to FDA's "closed system" electronic signature definition.

EU AI Act

High-Risk AI Documentation

Human oversight records required by Article 14 are produced natively for every VX-governed AI action. Technical documentation required by Article 11 is generated automatically from the namespace policy registry.

Internal Audit

AI Policy Enforcement Evidence

Policy-linked records prove that AI governance policies are being followed in practice, not just on paper. Audit bundles cover any specified period with zero manual compilation required.

Intellectual Property
Patent-pending across
12 provisionals.

The Veridex architecture is protected by 12 USPTO provisional patent applications spanning core infrastructure, vertical applications, identity architecture, and energy/hardware systems.

🧱

Core Infrastructure

Veridex Core state machine, deterministic authorization engine, and cryptographic chaining architecture. The foundational patents covering the pre-authorization receipt primitive.

🏥

VCAL — Clinical Authorization

USPTO App #63/987,343 (filed 02/20/2026). Covers AI action authorization in clinical workflows — physician confirmation chains for AI-assisted diagnostic and treatment decisions.

📡

General Protocol Layer

USPTO App #63/987,350 (filed 02/20/2026). Cross-domain authorization protocol specification enabling Veridex to operate as horizontal infrastructure across any AI-governed workflow.

🔐

Crypto Custody Authorization

USPTO App #63/987,664 (filed 02/20/2026). Covers human authorization requirements for AI-assisted digital asset custody decisions — institutional-grade authorization infrastructure for crypto.

🪪

Identity & Data Sovereignty

RAC (Recipient Authority Confirmation), KSRS (Key-Separated Reality Storage), and behavioral intelligence patents covering persistent human identity and sovereign data storage.

Energy & Hardware

Thixotropic nanoparticle gel electrochemical energy storage (App #63/958,184, filed 01/11/2026). Manufacturing moat supporting hardware-rooted trust infrastructure.

IP Status

All applications are USPTO provisional filings establishing priority dates. Full utility applications in preparation with counsel at Polsinelli. Reference patent numbers and filing dates available under NDA for qualified enterprise evaluations and due diligence processes. Contact us to initiate a qualification call.

Ready to see it
live?

15-minute technical walkthrough. We'll show you the authorization chain in action and answer architecture questions directly.

Technical documentation available under NDA. · Patent-Pending · 12 USPTO Provisionals