Deploy Sidecars
Choose your deployment platform.
Architecture
This page provides a comprehensive overview of the GLACIS architecture, including all major components and how they interact.
System Overview
GLACIS consists of four main layers:
┌─────────────────────────────────────────────────────────────────┐│ CLIENT LAYER ││ Applications, AI Services, Sidecars │└─────────────────────────────────────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────────────┐│ ATTESTATION LAYER ││ Witness Service, Receipt Service, Merkle Trees │└─────────────────────────────────────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────────────┐│ COMPLIANCE LAYER ││ Control Library, Evidence Management, Gap Analysis │└─────────────────────────────────────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────────────┐│ INTELLIGENCE LAYER ││ Certification Wizard, CTE, Auto-Remediation │└─────────────────────────────────────────────────────────────────┘Component Architecture
Full System Diagram
┌─────────────────────────────────────────────────────────────────┐│ CLIENT APPLICATIONS ││ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ││ │ Dashboard UI │ │ API Clients │ │ Sidecars │ ││ │ (SvelteKit) │ │ (REST/SDK) │ │ (Proxy) │ ││ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │└─────────┼──────────────────┼──────────────────┼──────────────────┘ │ │ │ ▼ ▼ ▼┌─────────────────────────────────────────────────────────────────┐│ COMPLIANCE PLATFORM (SvelteKit + D1) ││ ┌──────────────────────────────────────────────────────────┐ ││ │ REST API Layer │ ││ │ ├─ Management API (controls, evidence, compliance) │ ││ │ ├─ Wizard API (interview, milestones) │ ││ │ ├─ CTE API (frameworks, gaps, conflicts) │ ││ │ └─ S3P API (witness, epochs, sampling) │ ││ └──────────────────────────────────────────────────────────┘ ││ ││ ┌──────────────────────────────────────────────────────────┐ ││ │ Business Logic Layer │ ││ │ ├─ Wizard (Interview + Generator) [Claude AI] │ ││ │ ├─ CTE (Topology Engine) [Embeddings] │ ││ │ ├─ Compliance (Scoring + Snapshots) │ ││ │ ├─ Evidence (Collection + Audit) │ ││ │ └─ Export (OSCAL + SOA) │ ││ └──────────────────────────────────────────────────────────┘ ││ ││ ┌──────────────────────────────────────────────────────────┐ ││ │ Data Layer (Cloudflare D1 SQLite) │ ││ │ ├─ Control Library (184 ISO 42001 controls) │ ││ │ ├─ Organization Data (multi-tenant) │ ││ │ ├─ Evidence & Attestations │ ││ │ └─ Audit Log (immutable) │ ││ └──────────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────────┘ │ │ │ ▼ ▼ ▼┌─────────────────────────────────────────────────────────────────┐│ ATTESTATION SERVICES ││ ┌──────────────┐ ┌──────────────┐ ││ │ Witness Svc │ │ Receipt Svc │ ││ │ (Epochs) │◀─────────▶│ (Merkle) │ ││ └──────────────┘ └──────────────┘ ││ ││ ┌──────────────────────────────────────────────────────────┐ ││ │ Core Cryptography (packages/core) │ ││ │ ├─ CBOR Canonicalization (RFC 8949) │ ││ │ ├─ HMAC-SHA256 Commitments │ ││ │ ├─ Ed25519 Signatures │ ││ │ └─ Merkle Tree Proofs │ ││ └──────────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────────┘Component Details
Sidecars
Purpose: Intercept AI requests and generate attestations
Deployment Options:
| Platform | Cold Start | Best For |
|---|---|---|
| Cloudflare Workers | <1ms | Global edge, low latency |
| Google Cloud Run | ~200ms | GCP environments |
| AWS Lambda | ~100ms | AWS-native stacks |
| Kubernetes | 0ms (always on) | On-prem, strict security |
Key Responsibilities:
- Obtain bearer tokens from witness
- Forward requests to AI providers
- Generate L0/L2 attestations
- Send attestations to receipt service
- Return responses to applications
Witness Service
Purpose: Coordinate epochs and issue bearer tokens
interface WitnessService { // Get current epoch and bearer token heartbeat(req: HeartbeatRequest): Promise<{ epochId: string; bearerToken: string; expiresAt: number; witnessId: string; }>;
// Get epoch metadata getEpoch(epochId: string): Promise<EpochMetadata>;}Key Properties:
- Runs on Cloudflare Workers (global edge)
- Bearer tokens valid for current epoch only
- Maintains witness-derived binary identity
- Enforces epoch currency
Receipt Service
Purpose: Validate attestations and issue Merkle proofs
7-Phase Validation Pipeline:
┌─────────────────────────────────────────────────────────────┐│ Receipt Service Validation Pipeline │├─────────────────────────────────────────────────────────────┤│ Phase 1: Schema validation (fail fast) ││ └─ Reject malformed attestations immediately │├─────────────────────────────────────────────────────────────┤│ Phase 2: Epoch validation (strict current epoch) ││ └─ Verify attestation is within valid epoch │├─────────────────────────────────────────────────────────────┤│ Phase 3: Binary identity verification ││ └─ Verify sidecar identity matches signature │├─────────────────────────────────────────────────────────────┤│ Phase 4: Co-epoch network attestation ││ └─ Cross-verify with witness service │├─────────────────────────────────────────────────────────────┤│ Phase 5: Monotonic counter validation ││ └─ Ensure ordering within epoch │├─────────────────────────────────────────────────────────────┤│ Phase 6: Atomic transparency log append ││ └─ Add to Merkle tree (Durable Objects) │├─────────────────────────────────────────────────────────────┤│ Phase 7: Receipt persistence ││ └─ Store attestation and return proof │└─────────────────────────────────────────────────────────────┘Compliance Platform
Purpose: Dashboard, APIs, and compliance management
Technology Stack:
- Framework: SvelteKit 2.5
- Database: Cloudflare D1 (SQLite)
- ORM: Drizzle
- AI: Anthropic Claude API
- Hosting: Cloudflare Pages
Database Schema (key tables):
-- Control library (184 ISO 42001 controls)iso42001_controls (id, domain, code, name, description, guidance)
-- Organization-specific control statuscontrol_applicability (org_id, control_id, applicable, status, owner)
-- AI system inventoryai_systems (id, org_id, name, description, risk_tier, status)
-- Evidence linked to controlscontrol_evidence (id, control_id, type, content, attestation_id)
-- Attestation cache from sidecarsattestation_cache (id, org_id, epoch_id, level, commitment, signature)
-- Immutable audit logaudit_log (id, org_id, action, actor, timestamp, details)Certification Wizard
Purpose: AI-powered compliance interview and artifact generation
Components:
┌─────────────────────────────────────────────────────────────┐│ Certification Wizard │├─────────────────────────────────────────────────────────────┤│ Interview Engine (interview.ts) ││ ├─ Claude-powered conversation ││ ├─ 5-stage flow: welcome → systems → context → frameworks ││ ├─ Prompt injection detection ││ └─ State integrity verification (HMAC-SHA256) │├─────────────────────────────────────────────────────────────┤│ Generator (generator.ts) ││ ├─ AI system registry entries ││ ├─ Impact assessments ││ ├─ Gap analysis reports ││ ├─ Policy templates ││ └─ Control implementation guidance │├─────────────────────────────────────────────────────────────┤│ Security ││ ├─ Rate limiting (10 req/min per org) ││ ├─ Input size limits (2,000 chars/message) ││ ├─ 30-message history limit ││ └─ Zod schema validation on outputs │└─────────────────────────────────────────────────────────────┘Compliance Topology Engine (CTE)
Purpose: Multi-framework analysis and gap detection
Capabilities:
- Framework requirement mapping
- Cross-framework conflict detection
- Coverage metrics calculation
- Vector similarity search (embeddings)
- Knowledge graph traversal
Data Flow
Attestation Flow
1. Application Request App ──────────────────────▶ Sidecar
2. Epoch Binding Sidecar ─────────────────▶ Witness Service ◀───────────────── Bearer Token + Epoch ID
3. AI Provider Request Sidecar ─────────────────▶ OpenAI/Anthropic ◀───────────────── AI Response
4. Attestation Generation Sidecar generates L0 (always) or L2 (if sampled)
5. Receipt Submission Sidecar ─────────────────▶ Receipt Service ◀───────────────── Merkle Proof
6. Dashboard Update Receipt Service ─────────▶ Compliance Platform (via webhook)
7. Response Return Sidecar ─────────────────▶ AppCompliance Scoring Flow
1. Evidence Collection Attestations + Documents + Links │ ▼2. Control Mapping Map evidence to ISO 42001 controls │ ▼3. Status Calculation Per-control: Not Started → In Progress → Implemented │ ▼4. Domain Scoring Calculate percentage per domain (A.2, A.4, etc.) │ ▼5. Overall Score Weighted average across domains │ ▼6. Snapshot Store historical score for trendingSecurity Architecture
Defense in Depth
┌─────────────────────────────────────────────────────────────┐│ Layer 1: Network Security ││ • TLS 1.3 for all connections ││ • IP allowlisting (optional) ││ • DDoS protection (Cloudflare) │├─────────────────────────────────────────────────────────────┤│ Layer 2: Authentication ││ • API key authentication (glc_...) ││ • Session tokens (Argon2id hashed) ││ • Bearer tokens (epoch-bound) │├─────────────────────────────────────────────────────────────┤│ Layer 3: Authorization ││ • Organization isolation ││ • Role-based access control ││ • Resource-level permissions │├─────────────────────────────────────────────────────────────┤│ Layer 4: Data Protection ││ • Zero-egress design (commitments only) ││ • Field-level encryption (XChaCha20-Poly1305) ││ • Audit logging (append-only) │├─────────────────────────────────────────────────────────────┤│ Layer 5: Cryptographic Integrity ││ • Ed25519 signatures on attestations ││ • Merkle proofs for ordering ││ • HMAC-SHA256 state integrity │└─────────────────────────────────────────────────────────────┘Zero-Egress Design
┌─────────────────────────────────────────────────────────────┐│ Your Infrastructure ││ ┌─────────────────────────────────────────────────────┐ ││ │ Evidence (request, response, PII, etc.) │ ││ │ NEVER LEAVES │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ ▼ Commitment (SHA-256 hash) │└───────────────────────────┼─────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────────┐│ GLACIS Services ││ ┌─────────────────────────────────────────────────────┐ ││ │ Commitment Hash Only │ ││ │ (Cannot reverse to get original data) │ ││ └─────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────┘Deployment Topology
Cloud Deployment
┌─────────────────────────────────────────────────────────────┐│ Cloudflare Network (300+ PoPs) ││ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ││ │ Witness │ │ Receipt │ │ Dashboard │ ││ │ Worker │ │ Worker │ │ Pages │ ││ │ (edge) │ │ (edge) │ │ (edge) │ ││ └─────────────┘ └─────────────┘ └─────────────┘ ││ │ │ │ ││ └────────────────┴────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ Cloudflare D1 (SQLite) │ ││ │ • Read replicas at edge │ ││ │ • Write to primary │ ││ └─────────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────────────┘Kubernetes Deployment
apiVersion: apps/v1kind: Deploymentmetadata: name: glacis-sidecarspec: template: spec: containers: - name: sidecar image: ghcr.io/glacis-io/sidecar:latest env: - name: GLACIS_ORG_ID valueFrom: secretKeyRef: name: glacis-secrets key: org-id---apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: glacis-zero-egressspec: podSelector: matchLabels: app: glacis-sidecar policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 ports: - port: 443 # GLACIS services onlyNext Steps
API Reference
Explore the full API documentation.