Security

Last updated: June 2026

Cryptographic Design

Ed25519 (EdDSA) only — no HS256, no symmetric signing, no shared secrets
SHA-256 hash-chained receipts — each receipt links to its predecessor; any modification breaks the chain
RFC 8785 (JCS) — JSON Canonicalization Scheme for deterministic serialization before signing
Merkle tree batching — inclusion proofs for individual receipts within batch roots
Base L2 on-chain anchoring — Merkle roots committed to Base mainnet for long-term immutability

Authorization Path

Zero LLM in the trust path. The authorization gateway is fully deterministic — policy evaluation uses allowlist, resource scope, and rate limit rules. No AI model can influence an authorization decision. AI (Gemini) is used only for compliance analysis, support, and recommendations — never for allow/deny decisions.

Infrastructure

Google Cloud Run — auto-scaling, managed TLS, DDoS protection
Google Cloud Firestore — encryption at rest (AES-256), encryption in transit
Google Secret Manager — Ed25519 signing keys stored in hardware-backed secret storage
Vertex AI — Gemini calls processed within Google Cloud data residency boundaries

Authentication

API keys are SHA-256 hashed before storage — raw keys are never persisted
All API requests require the X-API-Key header
Tenant isolation: all queries are scoped by tenant ID
Rate limiting enforced per plan (429 on exceeded)

Verification

Receipt chains can be independently verified by anyone with the public key (GET /v1/public-key or GET /v1/engine/public-key). On-chain anchors can be verified on BaseScan. No trust in Verigate is required for verification.

Responsible Disclosure

Report security vulnerabilities to security@verigate.cloud. We will acknowledge within 24 hours.