Wiki · Concept · Last reviewed June 25, 2026

Common Expression Language (CEL)

Common Expression Language is an embeddable expression language for small, inspectable decisions inside larger systems.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: CEL, Kubernetes, policy as code, admission control, AI governance

Definition

Common Expression Language, or CEL, is a general-purpose expression language designed to be fast, portable, safe to execute, and embedded inside larger applications. The CEL project describes it as useful for declarative configurations, list filters, validation constraints, authorization rules, and other cases where a host application needs more expressive conditions without accepting arbitrary program execution.

In Kubernetes, CEL is used directly in the API server for validation rules, policy rules, constraints, and conditions. That makes it part of the infrastructure where model-serving systems, agent sandboxes, tool gateways, and evaluation jobs are often admitted, labeled, blocked, or reshaped.

How It Works

A CEL expression is not a standalone application. The host system defines the environment: available variables, types, and functions. The expression is parsed, checked against that environment, and evaluated with concrete input values. The CEL overview describes a common pattern where expressions are parsed and checked on a configuration path, stored as an abstract syntax tree, and evaluated repeatedly at runtime.

Kubernetes makes that embedding explicit. Each API field that accepts CEL documents its available variables. CustomResourceDefinition validation rules commonly expose values such as self and oldSelf. Admission policies expose request and object data according to their API fields. Kubernetes also supplies domain libraries for lists, regular expressions, URLs, IP addresses, CIDR blocks, authorization checks, string formats, quantities, and semantic versions.

CEL's safety posture matters. Kubernetes documentation says CEL is non-Turing complete and uses resource constraints to limit execution time and protect the API server from excessive evaluation cost. Kubernetes also applies runtime cost budgets and, for some resources, estimated cost checks before expressions are stored.

Agent Context

Agent infrastructure often turns high-level intent into API objects. A deployment bot may create a Job for an evaluation run, a Pod for a browser worker, a Deployment for a model endpoint, or a custom resource for a tool server. CEL gives platform teams a way to put narrow, inspectable rules close to that conversion point.

Examples include requiring owner and data-classification labels, rejecting privileged pod shapes, limiting which namespaces may run tool servers, checking that a runtime class is present for untrusted code, or verifying that a custom resource includes a review ticket before rollout. Those are local governance choices. CEL does not decide whether a model is safe or a workflow is appropriate; it evaluates the expression supplied by the platform.

Governance Use

A governance-grade CEL record should preserve the expression, host resource, API field, available variables, library functions used, author, reviewer, version, rollout date, affected namespaces, test cases, denial or warning message, failure behavior, parameter resources, and example objects that pass and fail. The record should also say which control owns the expression: a CustomResourceDefinition rule, ValidatingAdmissionPolicy, MutatingAdmissionPolicy, authentication configuration, authorization configuration, or another embedding.

For AI workloads, connect the expression to the platform boundary it protects. A rule about labels may serve auditability. A rule about runtime class may serve sandboxing. A rule about image patterns may serve supply-chain review. Without that stated purpose, small expressions become difficult to retire or improve.

Limits

CEL is deliberately smaller than a general programming language. That is part of its appeal, but also a limit. It is not the right place for network calls, database lookups, human approval workflows, registry scans, proprietary risk models, or complex multi-step reconciliation. Those tasks usually belong in admission webhooks, controllers, CI pipelines, or external policy services.

Short expressions can still be hazardous. A broad admission rule can deny many cluster writes. A mutation rule can change objects humans expected to remain unchanged. A partially typed expression may accept a field reference that only fails under certain resource shapes. CEL should therefore be reviewed like production policy code, not treated as a harmless string.

Source Discipline

Claims about CEL's design should cite the CEL project site and specification repository. Claims about Kubernetes embedding, API-server evaluation, resource budgets, available libraries, ValidatingAdmissionPolicy, and MutatingAdmissionPolicy should cite Kubernetes documentation. Claims about AI relevance should be framed as deployment analysis: CEL governs API and policy objects, and the AI relevance follows when AI systems are deployed through those objects.

Spiralist Reading

Spiralism reads CEL as the grammar of a small refusal. It is not a constitution. It is a sentence placed at the gate: this object may pass, that one may not, this field must be named.

Its virtue is inspectability. When automation accelerates, institutions need rules that can be read, tested, reviewed, and blamed by name.

Sources

Return to Wiki