Core Concepts

This page explains the core concepts that power GLACIS. Understanding these concepts will help you make the most of the platform.

Attestations

An attestation is a cryptographically signed statement that proves something happened. In GLACIS, attestations prove that:

1. An AI request was made
2. Governance policies were evaluated
3. Specific results were produced

Attestation Structure

Every attestation contains:

interface Attestation {
  // Unique identifier
  id: string;

  // Time binding
  epochId: string;
  timestamp: number;

  // Request metadata
  blindedId: Uint8Array;      // 8 bytes, derived from PRF tag
  requestCommitment: string;  // SHA-256 hash of request
  encoderId: string;          // Identifies the sidecar

  // Cryptographic proof
  signature: Uint8Array;      // Ed25519 signature

  // For L2 only
  evidenceCommitment?: string;
  policyScores?: PolicyScores;
  prfTag?: Uint8Array;        // Full 256-bit PRF tag
}

L0 vs L2 Attestations

GLACIS uses a two-tier attestation system to balance coverage with storage costs:

L0 Attestations

Generated for every request

• Metadata only (no request content)
• ~200 bytes per attestation
• Proves request occurred
• Enables coverage verification

Contains: blindedId, requestCommitment, encoderId, signature

L2 Attestations

Generated for sampled requests

• Full evidence included
• ~2-10 KB per attestation
• Deep audit trail
• Policy score details

Contains: Everything in L0 + evidenceCommitment, policyScores, prfTag

Tip

The sampling rate for L2 attestations is configurable. A rate of 100 means 1 in 100 requests get full evidence capture.

Epochs

An epoch is a discrete time period (typically 1 hour) that bounds attestations. Epochs provide:

• Ordering: All attestations within an epoch are ordered
• Freshness: Bearer tokens expire with the epoch
• Batch verification: Auditors can verify entire epochs at once
• Sampling control: Sampling rates can change per epoch

Epoch Lifecycle

┌─────────────────────────────────────────────────────────────┐
│  Epoch Lifecycle                                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  t=0:00        t=0:30        t=1:00        t=1:30          │
│  ┌─────────────────────────────┐                           │
│  │        Epoch N              │                           │
│  │  • Bearer tokens issued     │                           │
│  │  • Attestations collected   │                           │
│  │  • Merkle tree built        │                           │
│  └─────────────────────────────┘                           │
│                                ┌─────────────────────────── │
│                                │        Epoch N+1          │
│                                │  (new epoch starts)       │
│                                └─────────────────────────── │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Bearer Tokens

Before generating attestations, sidecars obtain a bearer token from the witness service:

// Sidecar requests bearer token
const { bearerToken, epochId, expiresAt } = await witness.heartbeat({
  sidecarId: 'sidecar_123',
});

// Token is valid for current epoch only
// All attestations must include this epochId

Commitments

A commitment is a cryptographic hash that binds to specific data without revealing it. GLACIS uses commitments for:

Request Commitment

Binds the attestation to the original request:

const requestCommitment = sha256(
  canonicalize({
    model: 'gpt-4',
    messages: [{ role: 'user', content: 'Hello' }],
    timestamp: Date.now(),
  })
);

Evidence Commitment

For L2 attestations, binds to the full evidence:

const evidenceCommitment = sha256(
  canonicalize({
    request: { /* full request */ },
    response: { /* full response */ },
    policyScores: { /* evaluation results */ },
  })
);

Note

GLACIS uses CBOR (RFC 8949) canonicalization to ensure commitment consistency across different platforms.

Zero-Egress Architecture

GLACIS is designed so that sensitive evidence never leaves your infrastructure:

┌─────────────────────────────────────────────────────────────┐
│  Your Infrastructure (evidence stays here)                  │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Sidecar                                             │   │
│  │  • Full request/response available                   │   │
│  │  • Evidence commitment computed locally              │   │
│  │  • Only commitment hash sent externally              │   │
│  └─────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘
                    │
                    │ Commitments only (hashes)
                    ▼
┌─────────────────────────────────────────────────────────────┐
│  GLACIS Services                                            │
│  • Receives commitment hashes                               │
│  • Cannot reverse hashes to get evidence                    │
│  • Can verify proofs mathematically                         │
└─────────────────────────────────────────────────────────────┘

This architecture enables:

• Auditor verification without evidence access
• Compliance proof without data exposure
• Third-party trust without third-party data sharing

Merkle Trees

GLACIS uses Merkle trees to create ordered, verifiable logs of attestations:

                    Root Hash
                   /         \
              H(A+B)         H(C+D)
              /    \         /    \
           H(A)   H(B)    H(C)   H(D)
            │      │       │      │
           Att₁   Att₂    Att₃   Att₄

Merkle Proofs

When an attestation is added to the tree, a Merkle proof is returned:

interface MerkleProof {
  // Index in the tree
  index: number;

  // Sibling hashes needed to verify
  siblings: string[];

  // Root hash at time of inclusion
  root: string;
}

This proof allows anyone to verify that an attestation was included in the log without downloading the entire tree.

Policy Scores

L2 attestations include policy scores — evaluations of the AI interaction against governance policies:

interface PolicyScores {
  toxicity: {
    score: number;      // 0-1, higher = more toxic
    flagged: boolean;   // Exceeded threshold
    categories: string[];
  };

  pii: {
    detected: boolean;
    types: string[];    // 'email', 'phone', 'ssn', etc.
    count: number;
  };

  bias: {
    score: number;
    categories: string[];
  };

  custom: Record<string, unknown>;
}

Available Policies

Policy	Description	Default Threshold
toxicity	Harmful, offensive, or inappropriate content	0.7
pii	Personally identifiable information	Any detection
bias	Biased or discriminatory content	0.6
prompt_injection	Attempted prompt manipulation	Any detection

Signatures

All attestations are signed using Ed25519 digital signatures:

// Sidecar signs attestation
const signature = ed25519.sign(
  canonicalize(attestation),
  sidecarPrivateKey
);

// Anyone can verify
const valid = ed25519.verify(
  canonicalize(attestation),
  signature,
  sidecarPublicKey
);

Ed25519 provides:

• Non-repudiation: Sidecar cannot deny creating the attestation
• Integrity: Any modification invalidates the signature
• Speed: Fast signing and verification

Control Mapping

GLACIS automatically maps attestations to ISO 42001 controls:

┌─────────────────────────────────────────────────────────────┐
│  Attestation                                                │
│  • Type: L2                                                 │
│  • Policy: toxicity                                         │
│  • Result: score=0.1, flagged=false                        │
└──────────────────────────┬──────────────────────────────────┘
                           │
                           │ Auto-mapping
                           ▼
┌─────────────────────────────────────────────────────────────┐
│  Control A.6.2.6 - AI System Monitoring                     │
│  Evidence: 1,247 attestations                               │
│  Status: Implemented                                        │
│  Last Evidence: 2 minutes ago                               │
└─────────────────────────────────────────────────────────────┘

Summary

Concept	Purpose
Attestation	Cryptographic proof of an AI interaction
L0/L2	Two-tier system balancing coverage and detail
Epoch	Time-bounded period for ordering attestations
Commitment	Hash that binds to data without revealing it
Zero-egress	Evidence stays in your infrastructure
Merkle tree	Ordered, verifiable log structure
Policy scores	Governance policy evaluation results
Signature	Ed25519 proof of authenticity

Next Steps

Architecture Deep Dive

Explore the full system architecture.

Architecture →

Attestation Service

Learn about the witness and receipt services.

Attestation Service →