Skip to main content
Agentgateway uses CEL (Common Expression Language) throughout the request processing pipeline. CEL expressions give you fine-grained, programmable control over authorization, header transformations, rate limiting selectors, and log/trace fields — all evaluated at runtime without restarting the proxy.

What is CEL?

CEL is a fast, safe expression language designed for evaluating user-defined conditions at runtime. Unlike Lua or WASM, CEL is sandboxed and cannot perform I/O or side effects — this makes it predictable, safe to use in a high-performance proxy, and straightforward to reason about. A simple MCP authorization expression:

Where CEL is used

How expressions are evaluated

Expressions are compiled at configuration load time (not per request). During compilation, Agentgateway extracts which context variables the expression references. At request time, only the referenced data is collected — you only pay for what you use.
This is especially important for expensive fields:
  • request.body — causes the body to be buffered in memory (expensive)
  • request.headers — header map allocation (moderate cost)
  • llm.prompt / llm.completion — large string copies for LLM traffic
Accessing request.body or response.body in a CEL expression causes the full body to be buffered in memory before the expression is evaluated. Avoid this for large payloads unless necessary.
Variable extraction uses static analysis. It handles request.body correctly, but not dynamic access patterns like request["body"]. Stick to dot notation for reliable optimization.

Context reference

The following variables are available in CEL expressions. Availability depends on where in the pipeline the expression runs — for example, response is not available in request-phase transformations.

request — incoming HTTP request

The request object contains attributes about the incoming HTTP request.Examples:
The response object is available in response-phase expressions (e.g., response transformations, access logs).Examples:
The jwt object contains claims from a verified JWT token. It is only present when the JWT authentication policy is enabled and a valid token is provided.Examples:
jwt is only available after the JWT policy has verified the token. If authentication fails, the request is rejected before authorization expressions run.
The mcp object contains attributes about an MCP request. It is available when the route handles MCP traffic.Examples:
The llm object contains attributes about an LLM request or response. It is only present when using an ai backend.Examples:
The source object contains attributes about the downstream connection.Examples:
The backend object contains information about the backend selected for the request.Examples:
These objects are present when the corresponding authentication policy is enabled and credentials have been verified.Examples:
The env object exposes a curated subset of well-known environment attributes. It does not expose raw process environment variables.Examples:

Authorization policy examples

CEL expressions are most commonly used in authorization (authz) policies. Here are practical examples:

Authorization guide

Complete guide to setting up CEL-based authorization policies

MCP proxy guide

Proxy MCP servers with tool-level access control