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.

Verifiable Agent Pods (VAP)

Agent Identity

A first-class identity for an AI agent, consisting of an email address, handle, and AI passport. Agents are managed like team members -- shared with via existing tools (Google Docs, Slack, GitHub) using their email. Each agent identity is linked to at least one human Owner via the AgentAccess table. In the auth system, each identity also carries a SPIFFE ID (spiffe_id) and OAuth client fields (oauth_client_id) for autonomous authentication.

Agent Owner

A human accountable for an agent's existence, access, and behavior. Managed through the Share dialog with Owner/Editor/Viewer roles. Owners approve high-risk actions, connect credentials, and are recorded in the passport. If all Owners are removed, the agent is automatically suspended.

ScopedCredential

An org- or workspace-level credential record that cascades to agents through configurable sharing modes. Replaces the legacy per-agent Secrets Vault. Each ScopedCredential stores an encrypted OAuth token or API key and a sharing mode: inherit (agents receive it as a default, may supplement), enforce (agents must use it, cannot override), or isolated (not shared with child scopes). Managed via /v1/scoped-credentials.

ScopedToolInstall

An org- or workspace-level record that installs an MCP tool for a scope and declares a tool enforcement policy that cascades to agents: available (offered but not required), required (agents must have it, wizard pre-installs it), or blocked (forbidden for all agents in scope, install is rejected). Managed via /v1/scoped-tools.

SharingMode

The cascade behavior of a ScopedCredential. One of inherit (child scopes receive the credential as a default but can override it), enforce (child scopes must use this credential; OAuth DCR is skipped on MCP tool install), or isolated (credential is not shared with child scopes).

ToolEnforcement

The cascade policy on a ScopedToolInstall. One of available (agents may optionally install the tool), required (all agents in scope must have it and cannot remove it), or blocked (no agent in scope may install the tool).

Delegation Grant

A record tracking an active user-to-agent OBO delegation. Contains agent identity, user ID, service, granted scopes, expiry, revocation status, and usage count. Managed via /v1/agents/{agent_id}/delegations API. Expired or revoked grants block further token exchanges.

Dynamic Client Registration (RFC 7591)

An OAuth protocol for programmatically registering clients with an authorization server. Used when installing MCP tools to auto-register the agent as an OAuth client with the MCP server's authorization server.

HITL Approval (Human-in-the-Loop)

A flow where high-risk agent actions require explicit owner approval before execution. All Owners are notified (via Slack, Teams, or email). The first Owner to respond wins. The approval decision (who approved, when, risk level) is recorded as passport evidence. No response triggers escalation to workspace admin or denial by default.

Injection Method

An enum on CredentialRoutingRule controlling how credentials are provided to outbound requests. Values: sidecar (default, current behavior), client_credentials (agent obtains its own token via SPIFFE-SVID), token_exchange (sidecar performs RFC 8693 exchange for OBO delegation).

OBO Delegation (Auth Model 2)

An auth model where the agent acts on behalf of a human user via RFC 8693 token exchange. The composite token contains both sub (human) and act (agent) claims, enabling full audit trail. Requires an active DelegationGrant and Access Manifest approval.

OBO Grant (On-Behalf-Of)

A delegated access mechanism where an agent acts on behalf of a specific user using OAuth On-Behalf-Of flows. The agent sees what the user sees, nothing more. OBO tokens are scoped, time-limited (single request, 1 hour, or until revoked), and all access is logged with user attribution in the passport. Implemented via RFC 8693 token exchange, requiring an active DelegationGrant. Governed by Access Manifest account domain entries with allowed_scopes, denied_scopes, require_user_consent, and max_delegation_ttl_seconds.

Protected Resource Metadata (RFC 9728)

A discovery mechanism for MCP servers to advertise their authorization requirements. Lucid fetches this metadata when an MCP tool is installed to determine the server's authorization servers, token endpoint, and supported scopes.

Provisioned Credentials (Auth Model 3)

An auth model where a human stores a secret and the sidecar injects it at runtime. The agent never sees raw credentials. Includes per-user credential isolation, auto-refresh on 401, and optional Vault integration.

SPIFFE/SPIRE

A standard for workload identity in distributed systems. Each Lucid agent gets a SPIFFE ID (spiffe://lucid.ai/agent/{agent_id}) and an X.509-SVID certificate used for OAuth client assertions (RFC 7523) and mutual authentication. SPIRE is the runtime that issues and rotates SVIDs.

Token Exchange (RFC 8693)

An OAuth protocol for exchanging one token for another. Used in OBO delegation: the sidecar exchanges a user token (subject_token) and agent SPIFFE-SVID (actor_token) for a composite delegation token with an act claim. The exchange checks Access Manifest policies and DelegationGrant status.

VAP (Verifiable Agent Pod)

A TEE-attested container image with built-in governance for AI agents. Built on lucid-agent-base, a VAP automatically gets TEE execution, mTLS, Cedar enforcement, auditor chain, passport, owner binding, and credential injection. The Operator handles sidecar injection; the developer just writes agent logic.

Autonomous Identity (Auth Model 1)

An auth model where the agent acts as itself using SPIFFE workload identity and OAuth client_credentials grant. Used for cron jobs, A2A communication, and MCP server connections. The token identifies only the agent.

Bootstrap Token

A short-lived token issued by the Verifier after a successful VAP startup handshake. The agent presents its TEE quote during registration; the Verifier validates the hardware attestation and issues a bootstrap token scoped to the agent's identity. The token auto-refreshes via a heartbeat loop.

Trust Tier

A classification indicating the level of attestation assurance for a component in the audit chain. Three tiers exist: TEE-attested (hardware quote verified -- highest trust), mTLS-verified (certificate-based identity, encrypted in transit), and API-key (trust based on API key only -- lowest). Trust tier is recorded per component in the passport.

App Catalog

A browse-and-install store for agent capabilities. Installable categories include MCP servers, auditors, A2A agents, skills, and runtimes. Each entry has trust tier, required permissions, and auditor requirements. Installing an app updates the agent's MCP tool list, auditor chain, or A2A connections. Managed via /v1/app-catalog endpoints.

VAP Console

A live window into the agent's Verifiable Agent Pod, consisting of three panels: Log Stream (real-time structured logs via SSE), Subagent Tree (visual tree of active subagents with status), and Interactive Shell (Owner-only chat interface for debugging). Read-only for Viewers, log access for Editors, full access for Owners.

Chain Policy

The mechanism by which org and workspace admins enforce mandatory auditors and compliance frameworks. Chain policies cascade and merge (never subtract): system auditors (always on) + org-required + workspace-required + framework-required + user-selected = final audit chain. Enforced items appear locked in the Quick Deploy wizard.

Auditor Settings Cascade

The three-tier configuration hierarchy (org -> workspace -> agent) that controls auditor behavior. Security fields use deny-overrides (parent restrictions cannot be loosened). Configuration fields use inherit-override (child scopes can customize). Settings marked as enforced at a parent scope are locked at lower scopes. Each enforced field carries an enforcement mode that defines how the constraint is applied. See Enforcement Mode.

Enforcement Mode

A per-field constraint type that controls how enforced auditor settings are inherited through the cascade. Five modes exist:

Mode	Behavior	Example
Exact	Child must use the parent's exact value	pii_compliance_mode = "hipaa"
Floor	Child can raise but not lower a numeric value	injection_threshold >= 0.7
Ceiling	Child can lower but not raise a numeric value	max_tool_calls_per_session <= 50
Superset	Child must include all parent items, may add more	pii_types_enabled ⊇ [SSN, CREDIT_CARD]
Unlocked	No constraint (default)	log_level, otlp_endpoint

Enforcement modes replace the previous boolean enforced: true/false field. Existing enforced: true records are equivalent to enforcement_mode: exact.

Auditor Preset

A predefined bundle of Detection Rules (auditor settings) and Response Rules (Cedar policies) optimized for a specific risk tolerance. Each auditor supports three tiers: Starter (low false-positive rate, basic protection), Balanced (production-ready with moderate strictness), and Strict (maximum protection, suitable for regulated industries). Presets can be applied individually per auditor or as quick-start bundles that configure multiple auditors at once: Solo Builder, Production Team, and Regulated Enterprise. Applied via POST /api/v1/workspaces/{id}/apply-preset.

Quick-Start Bundle

A collection of auditor presets designed for a specific use case. Three bundles are available:

Bundle	Target	Auditors	Claims Monitored
Solo Builder	Individual developers	Guardrails, PII, Governance, Observability (all Starter)	~35
Production Team	Customer-facing teams with SLOs	7 auditors at Balanced tier	~65
Regulated Enterprise	Finance, healthcare, government	All 11 auditors, mostly Strict	~97

Claim Flow Navigation

A visual navigation pattern on the auditor detail page that represents the data flow through an auditor. Three clickable segments — Detection Rules (how the auditor observes), Claims (what observations it produces), and Response Rules (what actions to take) — serve as both an explanatory diagram and the primary tab navigation. Each segment is color-coded: blue/indigo for Detection Rules, neutral/gray for Claims, amber/orange for Response Rules.

Detection Rules

The tab (formerly called "Settings") that configures an auditor's measurement behavior — what it detects and how sensitively. Controls thresholds, entity lists, scan targets, feature flags, and other parameters that determine which claims get produced and at what confidence. Locked fields from parent scopes display enforcement mode badges.

Response Rules

The tab (formerly called "Policy") that defines actions taken when claims exceed thresholds. Uses the Cedar/IFTTT rule layer to map observations to decisions: deny, warn, redact, escalate, or proceed. Includes inherited rules from parent scopes and framework-required rules (e.g., GDPR, HIPAA, PCI-DSS).

Claim Setting Definition

A description of a detection parameter on a claim, auto-extracted from @claims decorator keyword-only arguments. Includes key, type, default value, and UI metadata (control hint, min/max, options). The Observer UI auto-generates detection settings panels from these definitions. See SDK Reference for details.

WorkspaceAPIKey

A renamed and scoped version of the former APIKey model. Workspace API keys are for human CLI and webhook use only -- agents never use these. Includes a purpose field to distinguish between different key uses (e.g., "CI/CD pipeline", "webhook integration").

Attestation Chain and WASM Core

Attestation Chain

A tamper-evident audit trail linking AttestationResult records across phases via ar_references (per RFC 9334 §3.2). Each AR carries an ar_hash (content hash), an ar_references list (hashes of causal predecessor ARs), and a chain_depth counter. The Nanobot acts as an Attester, producing signed Evidence bundles that reference prior ARs, forming a causal DAG where tampering with any entry invalidates all downstream references. Chain scope is per agent. Verified via GET /v1/attestation-chain/{ar_hash}.

Receipt Chain (Legacy)

The previous tamper-evident audit trail, replaced by the Attestation Chain. The legacy Receipt Chain used an ExtProc sidecar with hash-linked InteractionReceipt records. This has been superseded by ar_references-based chaining on AttestationResult, with the Nanobot as a first-class Attester producing signed Evidence bundles.

Chain Splice

When a pod restarts (new TEE, new Ed25519 key), the new chain's first AR references the last ar_hash from the old chain via ar_references, signed by the new key with a new attestation binding. The verification endpoint follows splices and validates both attestation reports.

InteractionReceipt (Removed)

Previously a per-request record in the Receipt Chain. Replaced by the Attestation Chain architecture where each AttestationResult carries ar_hash, ar_references, and chain_depth fields, and the Nanobot produces signed Evidence bundles linking phases causally.

WASM Sandbox

A WebAssembly execution environment used for cryptographic operations. WASM modules have no filesystem, network, or syscall access -- pure computation only. The Ed25519 signing key for the receipt chain lives inside the WASM sandbox and cannot be extracted by host code. The .wasm binary has a deterministic hash for TEE attestation.

lucid-wasm

A Rust workspace (packages/internal/lucid-wasm/) containing sandboxed WASM modules for cryptographic operations. Crates include lucid-crypto (shared primitives), lucid-wasm-receipt (receipt chain), and future modules for encryption, HMAC, Cedar evaluation, ZK proof verification, TEE quote parsing, and secret scanning.

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 --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 model, auditor profile, and data residency. Created via lucid apply --model Y or the Observer GUI.

Shared Pools

Pre-deployed pools of models and auditors 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.

Cedar Policy

The authorization policy language used by the Gateway to evaluate claims and make enforcement decisions (allow, deny, warn). Cedar policies are evaluated at the Gateway, not inside auditors. See Cedar Policies Guide.

PolicyEngine (Legacy)

Evaluates claims against declarative policy rules defined in YAML. Returns decisions (PROCEED, DENY, WARN, ESCALATE) based on rule conditions. Superseded by Cedar policies evaluated at the Gateway.

DynamicPolicyEngine (Legacy)

A PolicyEngine wrapper that automatically refreshes policies from a PolicySource at configurable intervals. Superseded by Cedar policies evaluated at the Gateway.

PolicySource (Legacy)

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

LPL (Lucid Policy Language) (Legacy)

The safe expression language previously used in YAML policy rule conditions. Superseded by the Cedar policy language. New deployments should use Cedar policies exclusively.

Deployments & Workflows

Deployment Type

A classification that determines which components a deployment provisions. Set via the deployment_type field in the environment spec. The model type provisions a headless API with auditors and a gateway. See Deployment Modes.

Workflow

A JSON graph that composes model 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 agent. 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.

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.