Technical Glossary

A reference for the security and infrastructure terminology used throughout the Lucid Platform.

Core Concepts

TEE (Trusted Execution Environment)

Hardware-based isolation that protects code and data from the host operating system and other processes. Also commonly referred to as an "Enclave."

Attestation

The process of cryptographically proving that a specific piece of software is running inside a legitimate, untampered TEE.

AI Passport

The end-product of a Lucid audit. A signed cryptographic bundle containing model inputs, outputs, auditor decisions, and hardware attestation evidence. Passports can be displayed to end users via banners, floating widgets, dedicated pages, or the browser extension. See AI Passports for full documentation.

Passport Display Mode

How an AI Passport is shown to end users: banner (top/bottom bar), floating (corner widget), page_only (dedicated URL), or browser_extension (toolbar icon via Lucid Passport Verifier extension).

RATS (Remote ATtestation procedureS)

An IETF standard (RFC 9334) for remote attestation. Lucid's architecture (Attester, Verifier, Relying Party) is modeled after this framework.

Components

Attester (The Workload)

In the RATS architecture, this is the entity being verified. In Lucid, it is your AI workload running inside a TEE sidecar.

Verifier (The Judge)

The service that appraises the evidence produced by the Attester to ensure it meets the required security and logic policies.

Relying Party (The Consumer)

Any system or user that consumes the AI results and verifies the AI Passport to ensure it was produced by a trusted source.

CoCo (Confidential Containers)

A CNCF project focused on bringing TEE support to Kubernetes. Lucid integrates with CoCo to provide hardware roots of trust.

Hardware Endorser Devices

Endorser (RATS)

In the RATS architecture, an entity that provides statements about the trustworthiness of an Attester. In Lucid, hardware endorser devices (DC-SCM, FlexNIC) provide cryptographically signed evidence that can be correlated with TEE attestations.

DC-SCM (Datacenter Secure Control Module)

An OCP standard for baseboard management providing hardware root of trust, power telemetry, and tamper detection. Uses PUF-bound keys for signing.

FlexNIC

A programmable SmartNIC that operates in shadow mode to monitor network traffic patterns. Detects distributed training collectives and potential data exfiltration.

PUF (Physical Unclonable Function)

A hardware-based security primitive that generates unique cryptographic keys from manufacturing variations. Keys cannot be extracted without destroying the device.

CoRIM (Concise Reference Integrity Manifest)

An IETF draft standard for representing reference values (golden measurements) from hardware manufacturers. Used to verify that endorser device firmware is genuine.

Multi-Signal Verification

The process of correlating independent signals (kernel structure, network patterns, power profile, memory behavior) to detect workload misrepresentation. All signals must be mutually consistent.

EAT (Entity Attestation Token)

IETF RFC 9711 standard for attestation tokens. Lucid AI Passports are EAT-inspired, using similar claim structures (iss, iat, exp).

Deployment Modes

Serverless Mode (Lucid-Managed)

The default deployment mode where customers deploy to Lucid's shared infrastructure pools. Provides instant deployment with the same TEE security guarantees as self-hosted. Customers connect directly to TEE pods — Lucid controls deploy-time (Operator) but never sees plaintext data at request-time. Can be used via CLI (lucid apply --app X --model Y) or Observer GUI.

Self-Hosted Mode

Deployment mode where customers run the Lucid platform in their own Kubernetes cluster. Provides full infrastructure control using LucidEnvironment YAML configuration and lucid apply -f env.yaml.

Environment Config

A serverless environment configuration specifying app, model, auditor profile, and data residency. Created via lucid apply --app X --model Y or the Observer GUI.

Shared Pools

Pre-deployed pools of models, auditors, and apps from the Lucid catalog. Serverless environments route traffic to these shared resources. TEE memory isolation ensures equivalent security to dedicated infrastructure.

Auditor Profile

A predefined collection of auditors optimized for specific use cases. Profiles include coding (for code agents), chat (for conversational AI), workflow (for agent builders), customer (for customer support), and default (basic protection).

Data Residency

Geographic constraint on where data can be processed. Serverless supports us, eu, apac, and any (no restriction). Enforced by routing to region-specific shared pools.

Operational Modes

Mock Mode

A simulation mode for local development that uses standard ECDSA signatures instead of hardware-specific TEE quotes.

Production Mode

The real-world deployment mode where auditors and models run inside actual hardware TEEs (SGX, SEV, Nitro).

Endorser Mock Mode

Development mode that simulates endorser device behavior (power telemetry, network flows) without real hardware. Used for testing multi-signal correlation logic.

Shadow Mode

An enforcement mode where policies are evaluated and logged but not enforced. Used for testing new policies in production without affecting traffic.

Policy-Driven Architecture

Claim

An observation or measurement produced by an auditor. Claims are facts (e.g., "toxicity score is 0.7") without decisions. The PolicyEngine evaluates claims against rules to make decisions.

ClaimsAuditor

A base class for auditors that only produce claims (observations) rather than making decisions directly. Part of the policy-driven architecture that separates measurement from policy enforcement.

PolicyEngine

Evaluates claims against declarative policy rules defined in YAML. Returns decisions (PROCEED, DENY, WARN) based on rule conditions.

DynamicPolicyEngine

A PolicyEngine wrapper that automatically refreshes policies from a PolicySource at configurable intervals. Enables policy updates without auditor redeployment.

PolicySource

An abstraction for fetching policies. Implementations include VerifierPolicySource (fetches from Verifier API) and FilePolicySource (loads from local YAML files).

PolicyConfig

Configuration values embedded in a policy (thresholds, feature flags, etc.) that can be referenced in rule conditions via config.* syntax. Enables dynamic threshold adjustments without rule changes.

LPL (Lucid Policy Language)

The safe expression language used in policy rule conditions. Supports claim access (claims['name'].value), config access (config.threshold), comparisons, and logical operators.

Extended Deployments & Workflows

Deployment Type

A classification that determines which components a deployment provisions. One of full (model + app + auditors), model (headless API + auditors), app (frontend only), or bridge (protocol adapter + auditors). Set via the deployment_type field in the environment spec. See Deployment Modes.

Workflow

A JSON graph that composes typed deployments into a single logical application. Nodes reference deployments, edges define intent-based routing conditions. Workflows compile to an orchestrator system prompt and MCP tool registrations -- the LLM is the router, with no external runtime engine. See Workflows.

Workflow Compilation

The process of converting a workflow JSON graph into an orchestrator system prompt and a set of MCP tool registrations. The compiled output runs on a standard LLM -- no LangGraph, Temporal, or custom runtime required.

Intent Routing

The mechanism by which a workflow orchestrator LLM directs user requests to the appropriate downstream deployment. The orchestrator reads routing conditions from its system prompt and calls MCP tools to dispatch requests. Routing is driven by LLM reasoning, not by code-level if/else branching.

Bridge

A deployment type (deployment_type: bridge) that acts as a protocol adapter between an external system and the Lucid platform. Example: the Chatwoot Bridge translates Chatwoot webhook payloads into OpenAI-compatible chat completion requests and proxies them to a downstream model deployment.

MCP (Model Context Protocol)

A protocol for exposing service capabilities as LLM-callable tools. Every Lucid service publishes MCP tools at /mcp with discovery metadata at /.well-known/mcp. MCP is used for workflow routing (orchestrator calls downstream deployments via tools) and for external integrations (clients access auditor capabilities through the MCP Gateway). See MCP.

MCP Gateway

A federation layer that aggregates MCP tools from all Lucid services into a single entry point. External clients authenticate via OAuth 2.1; internal services use mTLS. The gateway handles tool discovery, routing, and access control. See MCP.