zuplo 7.2.3 → 7.2.4

package/docs/ai-gateway/integrations/ai-sdk.mdx

@@ -44,8 +44,9 @@ the app you have configured in Zuplo.
 Models are referenced as `providerName/model`, where `providerName` is the
 provider name configured in your gateway. By default an app can reach any model
 offered by the providers configured for the Zuplo project. To limit it to a
-curated set, add the [Model Filtering](../policies/model-filtering.mdx) policy
-to the app—it applies separate rules to completions (`generateText`,
+curated set, add the
+[Model Filtering](../../policies/ai-gateway-model-filtering-v2-inbound.mdx)
+policy to the app—it applies separate rules to completions (`generateText`,
 `streamText`) and embeddings (`embed`), and rejects a capability it doesn't
 configure.
 

package/docs/ai-gateway/integrations/claude-code.mdx

@@ -69,5 +69,6 @@ ANTHROPIC_MODEL=anthropic/claude-sonnet-4-5-20250929
 ANTHROPIC_SMALL_FAST_MODEL=anthropic/claude-haiku-4-5
 ```
 
-The app's [Model Filtering](../policies/model-filtering.mdx) policy controls
-which models the app may use.
+The app's
+[Model Filtering](../../policies/ai-gateway-model-filtering-v2-inbound.mdx)
+policy controls which models the app may use.

package/docs/ai-gateway/integrations/codex.mdx

@@ -83,14 +83,16 @@ codex --config model_provider="zuplo"
 
 ### Choosing a model
 
-The app's [Model Filtering](../policies/model-filtering.mdx) policy controls
-which models the app may use. Codex names the model as `providerName/model`,
-where `providerName` is the provider name configured in your gateway:
+The app's
+[Model Filtering](../../policies/ai-gateway-model-filtering-v2-inbound.mdx)
+policy controls which models the app may use. Codex names the model as
+`providerName/model`, where `providerName` is the provider name configured in
+your gateway:
 
 ```bash
 codex --config model_provider="zuplo" --model "openai/gpt-5"
 ```
 
 A request with no model, or a model without that prefix, gets a `400`. Adding
-[Model Filtering](../policies/model-filtering.mdx) with an allow list also
-supplies a default, letting requests omit the model.
+[Model Filtering](../../policies/ai-gateway-model-filtering-v2-inbound.mdx) with
+an allow list also supplies a default, letting requests omit the model.

package/docs/ai-gateway/integrations/goose.mdx

@@ -65,9 +65,10 @@ configuration approaches depending on which version you choose.
 
 :::note
 
-The app's [Model Filtering](../policies/model-filtering.mdx) policy controls
-which models the app may use, so the model you enter here must be one that
-policy allows.
+The app's
+[Model Filtering](../../policies/ai-gateway-model-filtering-v2-inbound.mdx)
+policy controls which models the app may use, so the model you enter here must
+be one that policy allows.
 
 :::
 

package/docs/ai-gateway/integrations/langchain.mdx

@@ -77,6 +77,6 @@ Always name the model as `providerName/model`, where `providerName` is the
 provider name configured in your gateway. The gateway needs the prefix to know
 which provider to route to, and a request with no model, or a model without that
 prefix, gets a `400`. Adding the
-[Model Filtering](../policies/model-filtering.mdx) policy restricts an app to
-certain models, and an allow list also supplies a default so requests may omit
-the model.
+[Model Filtering](../../policies/ai-gateway-model-filtering-v2-inbound.mdx)
+policy restricts an app to certain models, and an allow list also supplies a
+default so requests may omit the model.

package/docs/ai-gateway/integrations/openai.mdx

@@ -45,9 +45,9 @@ Always name the model as `providerName/model`, where `providerName` is the
 provider name configured in your gateway. The gateway needs the prefix to know
 which provider to route to, and a request with no model, or a model without that
 prefix, gets a `400`. Adding the
-[Model Filtering](../policies/model-filtering.mdx) policy restricts an app to
-certain models, and an allow list also supplies a default so requests may omit
-the model.
+[Model Filtering](../../policies/ai-gateway-model-filtering-v2-inbound.mdx)
+policy restricts an app to certain models, and an allow list also supplies a
+default so requests may omit the model.
 
 ```typescript
 import OpenAI from "openai";

package/docs/ai-gateway/policies/overview.mdx

@@ -4,25 +4,11 @@ sidebar_label: Overview
 description: Every policy an AI Gateway app can run, and what each one does.
 ---
 
+import policies from "../../../policies.ui.json";
+
 The gateway's `config/policies.json` declares which policies apps may use, and
 each app picks from that menu in the order it wants. See
 [Policy Chains](../policy-chains.mdx) for how a chain executes and how options
 and secrets are inherited.
 
-| Policy                                                                | What it does                                                                                         |
-| --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
-| [API key authentication](./authentication.mdx)                        | Requires an app API key and resolves the calling app from it                                         |
-| [Model Filtering](./model-filtering.mdx)                              | Restricts the app to an allow list or block list of models, and supplies the default model           |
-| [Fallback Model](./fallback-model.mdx)                                | Adds a backup model for provider errors and timeouts, and a cheaper model for when a budget runs out |
-| [Budgets and Costs](./metering.mdx)                                   | Records usage and enforces the app's budgets for spend, tokens, and requests                         |
-| [Semantic cache](./semantic-cache.mdx)                                | Returns a cached response when a new prompt is close enough to one already seen                      |
-| [Akamai AI Firewall](./akamai-ai-firewall.mdx)                        | Scans prompts and completions with your Akamai configuration and blocks what it denies               |
-| [Comet Opik tracing](./comet-opik-tracing.mdx)                        | Sends a trace of each request and response to Comet Opik                                             |
-| [Galileo tracing](./galileo-tracing.mdx)                              | Sends a trace of each request and response to Galileo                                                |
-| [Configuration Executor](../policy-chains.mdx#configuration-executor) | Loads the app's configuration and runs its chain—this is what makes app chains work                  |
-
-The Configuration Executor and its companion Configuration Loader sit on the
-gateway's route rather than in an app's chain. API key authentication runs in an
-app's chain and protects that app alone. Any
-[custom policy](../custom-policies.mdx) you declare joins the menu alongside
-these.
+<PolicyOverview policies={policies} products={["ai-gateway"]} />

package/docs/ai-gateway/universal-api.mdx

@@ -54,9 +54,10 @@ console.log(response.choices[0].message.content);
 
 :::tip
 
-If the app's [Model Filtering](./policies/model-filtering.mdx) policy has an
-allow list, a request that omits `model` uses the first model in the list—so
-clients that can't set a model still work.
+If the app's
+[Model Filtering](../policies/ai-gateway-model-filtering-v2-inbound.mdx) policy
+has an allow list, a request that omits `model` uses the first model in the
+list—so clients that can't set a model still work.
 
 :::
 

package/docs/caching/custom-caching-policy.mdx

@@ -26,7 +26,7 @@ your row before writing anything.
 | A different TTL per route, or per response                  | The [`cacheConfig` function](./dynamic-cache-rules.mdx)                                                           |
 | Purge tags for targeted CDN invalidation                    | The CDN policy's `tags` option                                                                                    |
 | Cache GraphQL query results by query and variables          | [`graphql-cache-inbound`](../policies/graphql-cache-inbound.mdx)                                                  |
-| Cache LLM completions by prompt similarity                  | [`semantic-cache-inbound`](../policies/semantic-cache-inbound.mdx)                                                |
+| Cache LLM completions by prompt similarity                  | [`ai-gateway-semantic-cache-v2-inbound`](../policies/ai-gateway-semantic-cache-v2-inbound.mdx)                    |
 | Store an arbitrary JSON value with a TTL from your own code | [`ZoneCache`](../programmable-api/zone-cache.mdx)                                                                 |
 
 ## When custom code is the right answer

package/docs/caching/gateway-caching.mdx

@@ -298,9 +298,9 @@ the traffic they are built for:
 - [GraphQL Cache](../policies/graphql-cache-inbound.mdx) normalizes a GraphQL
   document and its variables before hashing, so two semantically identical
   queries share an entry even when their bodies differ.
-- [Semantic Cache](../policies/semantic-cache-inbound.mdx) matches requests by
-  meaning rather than exact text, which is what makes caching viable in front of
-  an LLM.
+- [Semantic Cache](../policies/ai-gateway-semantic-cache-v2-inbound.mdx) matches
+  requests by meaning rather than exact text, which is what makes caching viable
+  in front of an LLM.
 
 To cache a fragment of a response rather than all of it, or to drive the cache
 from your own code, see

package/docs/caching/overview.mdx

@@ -83,16 +83,16 @@ three above it in Zuplo.
 Find the row that matches the endpoint in front of you. The rows are ordered
 roughly by how much a hit saves.
 
-| Situation                                                                                      | Layer                  | Mechanism                                                                                  | Where to read                                                   |
-| ---------------------------------------------------------------------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------- |
-| A public catalog endpoint that returns the same body to everyone                               | CDN edge               | `cdn-cache-control-outbound` with an `edge` and a `client` TTL                             | [Cache at the CDN](./cdn-caching.mdx)                           |
-| An authenticated endpoint whose body is identical for every caller                             | CDN edge               | `cdn-cache-control-outbound` with `client.visibility: "private"` so only the CDN stores it | [Cache at the CDN](./cdn-caching.mdx)                           |
-| A mostly shared response with a small caller-specific slice                                    | Programmable           | Cache the shared fragment with the Cache API or `ZoneCache`, fetch only the dynamic part   | [Cache part of a response](./partial-response-caching.mdx)      |
-| A response whose cacheability depends on what it contains (empty results, error bodies, flags) | CDN edge, per response | A `cacheConfig` function that returns TTLs and purge tags for the response in hand         | [Per-response cache rules](./dynamic-cache-rules.mdx)           |
-| Caching rules no built-in policy expresses (a JWT-claim key, a size limit, an upstream TTL)    | Programmable           | A custom inbound and outbound policy pair built on the Cache API                           | [Build a custom caching policy](./custom-caching-policy.mdx)    |
-| Identical responses served to many callers, with no CDN in front of the gateway                | Gateway                | `caching-inbound` with an `expirationSecondsTtl`                                           | [Cache at the gateway](./gateway-caching.mdx)                   |
-| A GraphQL query repeated across callers, where the cache key is the query and its variables    | Gateway                | `graphql-cache-inbound`                                                                    | [GraphQL Cache policy](../policies/graphql-cache-inbound.mdx)   |
-| An LLM prompt worded differently each time but asking the same question                        | Gateway                | `semantic-cache-inbound`, which matches on prompt similarity rather than an exact key      | [Semantic Cache policy](../policies/semantic-cache-inbound.mdx) |
+| Situation                                                                                      | Layer                  | Mechanism                                                                                           | Where to read                                                                 |
+| ---------------------------------------------------------------------------------------------- | ---------------------- | --------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
+| A public catalog endpoint that returns the same body to everyone                               | CDN edge               | `cdn-cache-control-outbound` with an `edge` and a `client` TTL                                      | [Cache at the CDN](./cdn-caching.mdx)                                         |
+| An authenticated endpoint whose body is identical for every caller                             | CDN edge               | `cdn-cache-control-outbound` with `client.visibility: "private"` so only the CDN stores it          | [Cache at the CDN](./cdn-caching.mdx)                                         |
+| A mostly shared response with a small caller-specific slice                                    | Programmable           | Cache the shared fragment with the Cache API or `ZoneCache`, fetch only the dynamic part            | [Cache part of a response](./partial-response-caching.mdx)                    |
+| A response whose cacheability depends on what it contains (empty results, error bodies, flags) | CDN edge, per response | A `cacheConfig` function that returns TTLs and purge tags for the response in hand                  | [Per-response cache rules](./dynamic-cache-rules.mdx)                         |
+| Caching rules no built-in policy expresses (a JWT-claim key, a size limit, an upstream TTL)    | Programmable           | A custom inbound and outbound policy pair built on the Cache API                                    | [Build a custom caching policy](./custom-caching-policy.mdx)                  |
+| Identical responses served to many callers, with no CDN in front of the gateway                | Gateway                | `caching-inbound` with an `expirationSecondsTtl`                                                    | [Cache at the gateway](./gateway-caching.mdx)                                 |
+| A GraphQL query repeated across callers, where the cache key is the query and its variables    | Gateway                | `graphql-cache-inbound`                                                                             | [GraphQL Cache policy](../policies/graphql-cache-inbound.mdx)                 |
+| An LLM prompt worded differently each time but asking the same question                        | Gateway                | `ai-gateway-semantic-cache-v2-inbound`, which matches on prompt similarity rather than an exact key | [Semantic Cache policy](../policies/ai-gateway-semantic-cache-v2-inbound.mdx) |
 
 The intuitive answer is wrong in these cases:
 

package/docs/dedicated/akamai/ai-powered-applications.mdx

@@ -146,7 +146,7 @@ For more information, see the
 
 ## AI Firewall Protection
 
-The [Akamai AI Firewall](../../ai-gateway/policies/akamai-ai-firewall.mdx)
+The [Akamai AI Firewall](../../policies/akamai-ai-firewall-v2-inbound.mdx)
 provides enterprise-grade security for AI interactions:
 
 - **Prompt injection defense** - Detects and blocks attempts to manipulate the
@@ -217,7 +217,7 @@ Deployment options include:
   Akamai Connected Cloud
 - [MCP Server Handler](../../handlers/mcp-server.mdx) - Technical documentation
   for MCP server configuration
-- [Akamai AI Firewall](../../ai-gateway/policies/akamai-ai-firewall.mdx) - AI
+- [Akamai AI Firewall](../../policies/akamai-ai-firewall-v2-inbound.mdx) - AI
   security policy configuration
 - [Zuplo AI Gateway](../../ai-gateway/introduction.mdx) - Introduction to AI
   Gateway capabilities

package/docs/dev-portal/zudoku/configuration/search.md

@@ -181,6 +181,11 @@ You can also pass
 Zudoku's defaults and passed through to Inkeep as-is, so any option Inkeep supports can be used —
 including ones added after this Dev Portal version was released.
 
+Dev Portal owns the search modal's open state, so `modalSettings.isOpen` is managed for you. The
+<kbd>⌘</kbd>+<kbd>K</kbd> / <kbd>Ctrl</kbd>+<kbd>K</kbd> shortcut is handled by Zudoku's search
+button as well, which is why Inkeep's own `shortcutKey` is disabled by default. Setting it adds an
+additional shortcut rather than replacing it.
+
 For example, to categorize results into tabs based on their URL:
 
 ```typescript

package/docs/dev-portal/zudoku/openapi-extensions/x-mcp-server.md

@@ -32,6 +32,7 @@ When using the object form, the following properties are available:
 | --------- | --------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------- |
 | `name`    | `string`        | No       | Display name used in the generated client configuration snippets. Falls back to the operation `summary`, then `"mcp-server"` |
 | `version` | `string`        | No       | Version metadata                                                                                                             |
+| `url`     | `string`        | No       | Overrides the endpoint URL shown in the card and install snippets. See [MCP URL resolution](#mcp-url-resolution)             |
 | `tools`   | `[Tool Object]` | No       | Array of tools provided by the MCP server                                                                                    |
 
 Each item in the `tools` array:
@@ -47,6 +48,35 @@ The displayed MCP URL is constructed from the **server URL** of the API and the
 operation. The server URL comes from the OpenAPI `servers` array (or the operation-level `servers`
 override if present).
 
+### Overriding the URL
+
+Set `url` on `x-mcp-server` when the MCP server is not reachable under the documented API server —
+for example when it runs on its own hostname:
+
+```yaml
+servers:
+  - url: https://api.example.com
+paths:
+  /mcp:
+    post:
+      summary: My MCP Server
+      x-mcp-server:
+        name: my-mcp-server
+        url: https://mcp.example.com/mcp
+      responses:
+        "200":
+          description: MCP response
+```
+
+The card and every install snippet then use `https://mcp.example.com/mcp` instead of
+`https://api.example.com/mcp`.
+
+An absolute `url` (one with a scheme, such as `https://`) replaces the endpoint entirely and is used
+verbatim — it also takes precedence over the server picked in the server dropdown, since it names a
+host of its own. A value without a scheme is treated as a path on the server URL instead, so
+`url: /v2/mcp` resolves to `https://api.example.com/v2/mcp` and still follows server selection.
+Blank values are ignored and the URL falls back to the server URL plus the operation path.
+
 ## Examples
 
 ### Boolean shorthand

package/docs/policies/_index.md

@@ -4,10 +4,14 @@
 | --- | --- | --- | --- |
 | set-query-params-inbound | Add or Set Query Parameters | Adds or sets query parameters on the incoming request. | api-gateway |
 | set-headers-inbound | Add or Set Request Headers | Adds or sets headers on the incoming request. | api-gateway |
-| ai-gateway-fallback-model-v2-inbound | AI Gateway Fallback Model (v2) | Adds failure and quota fallbacks to an existing AI Gateway model selection.  Place this policy after AI Gateway Model Filtering (v2). It never creates a model selection, so a misplaced policy cannot bypass filtering. | ai-gateway |
-| ai-gateway-metering-v2-inbound | AI Gateway Metering (v2) | Meters AI Gateway v2 usage and enforces app and ancestor usage limits.  Limits configured on parent teams or the bucket root are enforced through a server-side hierarchical check.  The authentication policy must run before this policy so the app configuration id is available for meter storage and analytics. | ai-gateway |
-| ai-gateway-model-filtering-v2-inbound | AI Gateway Model Filtering (v2) | Matches AI Gateway requests against curated allow lists or open block lists, then stores the winning model reference for the route handler. | ai-gateway |
-| akamai-ai-firewall | Akamai AI Firewall | Akamai AI Firewall Inbound Policy | ai-gateway |
+| ai-gateway-auth-v2-inbound | AI Gateway Authentication | Authenticates requests to an AI Gateway endpoint with application API keys.  Add this policy to an application's `inboundPolicyChain` to require a key for that app only, or place it on the route before the configuration executor to require a key for every application on the route. The policies that follow can read the authenticated application from `request.user` (`sub` is the application name, `data` its metadata), and the application's AI Gateway configuration takes effect for the request. Use `authHeader` and `authScheme` when clients send their app key somewhere other than the default `Authorization: Bearer` header.  When the matched route captures an `app_id` path parameter (platform catch-all `/:app_id/(.*)`), this policy also requires `configuration.id === request.params.app_id` and returns 403 on mismatch. | ai-gateway |
+| ai-gateway-configuration-executor-v2-inbound | AI Gateway Configuration Executor | Loads the app configuration for the request (when auth or the configuration loader has not already) and runs the inbound policy chain from that configuration.  Place this policy on AI Gateway routes after optional authentication and optional `ai-gateway-configuration-loader-v2-inbound`. When either of those already populated the app-configuration channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter. Applications select from policies pre-declared by the gateway. Applications without a `inboundPolicyChain`, or with an empty chain, run no application-selected policies. Entry options replace the declaration's options as a complete object; omit them to inherit the declaration, including environment-backed credentials. Each occurrence receives a private deep copy of its entry options, so a policy mutating its options cannot corrupt the cached app configuration. | ai-gateway |
+| ai-gateway-configuration-loader-v2-inbound | AI Gateway Configuration Loader | Loads the AI Gateway app configuration for the request into the request-scoped channel and does nothing else.  Place this policy on AI Gateway routes before `ai-gateway-configuration-executor-v2-inbound` when you want configuration loading separated from chain execution. When `ai-gateway-auth-v2-inbound` already populated the channel, this policy reuses it. Otherwise it loads the configuration with the route's `app_id` path parameter.  If this policy is omitted, the configuration executor still loads configuration itself before running the application chain. | ai-gateway |
+| ai-gateway-fallback-model-v2-inbound | AI Gateway Fallback Model | Adds failure and quota fallbacks to an existing AI Gateway model selection.  Place this policy after AI Gateway Model Filtering. It never creates a model selection, so a misplaced policy cannot bypass filtering. | ai-gateway |
+| ai-gateway-metering-v2-inbound | AI Gateway Metering | Meters AI Gateway usage and enforces app and ancestor usage limits.  Limits configured on parent teams or the bucket root are enforced through a server-side hierarchical check.  The authentication policy must run before this policy so the app configuration id is available for meter storage and analytics. | ai-gateway |
+| ai-gateway-model-filtering-v2-inbound | AI Gateway Model Filtering | Matches AI Gateway requests against curated allow lists or open block lists, then stores the winning model reference for the route handler. | ai-gateway |
+| ai-gateway-semantic-cache-v2-inbound | AI Gateway Semantic Cache | AI Gateway Semantic Cache policy. This inbound policy looks up the semantic cache on entry and, on a miss, registers a response-sending hook to write the upstream response back into the cache.  Caching parameters (semanticTolerance, expirationSecondsTtl, namespace, recentMessageCount) come from the policy options, and presence in the route's chain is what enables it. An id from the authenticated app configuration always provides the cache namespace so application-supplied options cannot cross tenant partitions. The cache key covers the system prompt plus the last `recentMessageCount` messages (default 1) — applied when storing and when matching — so multi-turn conversations can hit entries cached from earlier, shorter ones.  Cache outcomes are reported on the response via the RFC 9211 `Cache-Status` header under the cache name `zp-aigw-sem-cache` (hit: `zp-aigw-sem-cache; hit; detail="similarity=0.93"`; miss: `zp-aigw-sem-cache; fwd=miss; stored`). Responses also include the `x-ai-gateway-cache: HIT\|MISS` and `x-ai-gateway-cache-similarity` headers. | ai-gateway |
+| akamai-ai-firewall-v2-inbound | Akamai AI Firewall | Akamai AI Firewall Inbound Policy | ai-gateway |
 | akamai-firewall-for-ai-outbound | Akamai Firewall for AI | Inspects each upstream response with Akamai's Firewall for AI detect API and replaces the response with a `403 Forbidden` if Akamai returns a `deny` rule. Useful behind AI-powered APIs to filter unsafe completions, sensitive data exposure, and toxic content before they reach the client.  The body, headers, URL, and query string sent to Akamai are configurable; by default only the response body is captured. Bodies are read from a clone so the client still receives the original. | api-gateway |
 | akamai-firewall-for-ai-inbound | Akamai Firewall for AI | Inspects each incoming request with Akamai's Firewall for AI detect API and blocks the request if Akamai returns a `deny` rule. Useful in front of AI-powered APIs to filter prompt injection, jailbreaks, and other unsafe inputs before they reach the model.  The body, headers, URL, and query string sent to Akamai are configurable; by default only the request body is captured. Bodies are read from a clone so the upstream handler still sees the original. | api-gateway |
 | amberflo-metering-inbound | Amberflo Metering / Billing | Amberflo is a usage metering and billing service. This policy allows you to send metering calls for each API to their meter ingest endpoint. | api-gateway |
@@ -26,7 +30,7 @@
 | clear-headers-inbound | Clear Request Headers | Removes all headers from the incoming request except for those in the exclude list. | api-gateway |
 | clear-headers-outbound | Clear Response Headers | Removes all headers from the response except for those in the exclude list. | api-gateway |
 | clerk-jwt-auth-inbound | Clerk JWT Auth | Authenticate users using Clerk issued JWT tokens. | api-gateway |
-| comet-opik-tracing-inbound | Comet Opik Tracing | Comet Opik Tracing Inbound Policy | ai-gateway |
+| comet-opik-tracing-v2-inbound | Comet Opik Tracing | Comet Opik Tracing Inbound Policy | ai-gateway |
 | complex-rate-limit-inbound | Complex Rate Limiting | The Complex Rate Limiting policy is an advanced rate limiting policy that let's you set rate limits based on custom counters (not just requests) | api-gateway |
 | composite-inbound | Composite Inbound (Group Policies) | Creates a composite, or group policy - composed of other inbound policies. For reuse across routes. | api-gateway |
 | composite-outbound | Composite Outbound (Group Policies) | Creates a composite, or group policy - composed of other outbound policies. For reuse across routes. | api-gateway |
@@ -35,9 +39,10 @@
 | custom-code-outbound | Custom Code Outbound | A custom outbound response policy. | api-gateway |
 | data-loss-prevention-outbound | Data Loss Prevention | Scans the upstream response body for sensitive data — PII, secrets, and financial identifiers — using an extensible catalog of built-in recognizers plus any custom patterns, and takes a configurable action when a match is found.  The action is one of `mask` (redact matches before returning the response), `block` (replace the response with a `422` listing the detected entity names only), or `log` (record a warning and return unchanged). Only text content types are inspected; binary bodies pass through untouched, and the body is read from a clone so the client still receives the original stream. | api-gateway |
 | data-loss-prevention-inbound | Data Loss Prevention | Scans the incoming request body for sensitive data — PII, secrets, and financial identifiers — using an extensible catalog of built-in recognizers plus any custom patterns, and takes a configurable action when a match is found.  The action is one of `mask` (redact matches before forwarding the request), `block` (reject with a `422` listing the detected entity names only), or `log` (record a warning and forward unchanged). Only text content types are inspected; binary bodies pass through untouched, and the body is read from a clone so the upstream still receives the original stream. | api-gateway |
+| ai-gateway-dlp-inbound | Data Loss Prevention (DLP) | Data Loss Prevention (DLP) Inbound Policy for the AI Gateway | ai-gateway |
 | firebase-jwt-inbound | Firebase JWT Auth | Authenticate users using Firebase issued JWT tokens. | api-gateway |
 | formdata-to-json-inbound | Form Data to JSON | Converts form data in the incoming request to JSON. | api-gateway |
-| galileo-tracing-inbound | Galileo Tracing | Galileo Tracing Inbound Policy | ai-gateway |
+| galileo-tracing-v2-inbound | Galileo Tracing | Galileo Tracing Inbound Policy | ai-gateway |
 | geo-filter-inbound | Geo-location filtering | Block requests based on geo-location parameters: country, region code, and ASN | api-gateway |
 | graphql-analytics-outbound | GraphQL Analytics | Reports GraphQL errors returned in response bodies to Zuplo's GraphQL analytics. GraphQL servers following the standard Apollo / graphql-yoga pattern return `200 OK` with an `errors[]` array in the body when an operation fails, which HTTP-level analytics alone report as a success — add this policy to a GraphQL route and failed operations show up as failures on the GraphQL dashboard, classified by error type.  Each error in `errors[]` is classified from its `extensions.code` following the Apollo Server conventions (`GRAPHQL_PARSE_FAILED` → `syntax`, `GRAPHQL_VALIDATION_FAILED` → `validation`, `UNAUTHENTICATED` / `FORBIDDEN` → `auth`, timeout codes → `timeout`); custom codes can be mapped with `errorCodeClassification`, and anything unrecognized falls back to `defaultErrorClass` (`resolver`). Optionally set `logErrors` to also write a structured warning per errored response. The policy reads up to `maxScanBytes` of the body (128 KiB by default, 5 MiB maximum), scanning it for the `errors` token; a response larger than that is treated as error-free. When the token is found and the body fits, it is parsed and its errors reported.  The response always passes through unchanged — the body is read from a clone, and any internal failure is swallowed so reporting can never break the request. The route must be marked `x-graphql: true` in `routes.oas.json` (which enables GraphQL analytics for the route); without the marker the policy logs a warning and does nothing. | api-gateway |
 | graphql-cache-inbound | GraphQL Cache | Caches GraphQL query responses at the edge so identical queries are served without a round-trip to the origin.  Unlike CDN caching that keys on the raw request body, this policy parses the GraphQL document and normalizes it before hashing: insignificant whitespace, field formatting, and fragment layout are collapsed, and variable object keys are sorted. Two requests that are semantically identical therefore share a cache entry even when their bodies differ byte-for-byte. There is no query size or nesting-depth limit.  Only `query` operations are cached. Mutations, subscriptions, malformed documents, and non-JSON bodies are forwarded to the origin untouched. Cache hits and misses are reported on the `x-cache` response header, with a short key fingerprint on `x-cache-key`.  To avoid serving one user's data to another, requests carrying an `authorization` or `cookie` header are not cached by default. Use `cacheKeyHeaders` to opt into caching them: each listed header's value is included in the cache key, so distinct credentials get distinct cache entries. | api-gateway |
@@ -87,7 +92,7 @@
 | require-origin-inbound | Require Origin | Sets an allow-list for an origin header | api-gateway |
 | require-user-claims-inbound | Require User Claims | Authorizes requests by validating claims on the authenticated user (`request.user`) against a configurable rule of `and`/`or` combinators and per-claim `eq`, `in`, and `startsWith` checks. Run it after any authentication policy that populates `request.user` — a JWT auth policy, API key auth, mTLS, and so on — to allow only specific callers (service accounts, OAuth clients, tenants, groups) without writing custom code.  Every check fails closed: a missing or non-primitive claim never matches, comparisons are strict and type-sensitive, and requests without an authenticated user receive a 401 response. Denied requests receive a 403 response that does not echo claim values or expected values; the failing checks are written to the request log instead.  Validation of the options runs lazily inside the policy constructor, which the runtime caches per policy name. Misconfigured options therefore fail on first use with a customer-facing `ConfigurationError` instead of failing at module load. | api-gateway |
 | secret-masking-outbound | Secret Masking (deprecated) | Masks common secrets like Zuplo API keys, GitHub tokens, or SSH private key in the response body. | api-gateway |
-| semantic-cache-inbound | Semantic Cache | Respond to matched incoming requests with semantically cached content  The Semantic Cache Inbound policy caches responses based on semantic similarity of cache keys rather than exact matches. This allows for more flexible caching where similar requests can return cached responses even if the cache key is not exactly the same.  The policy uses Large Language Model (LLM) embeddings to determine semantic similarity between cache keys based on a configurable similarity tolerance.  Options: - semanticTolerance: The semantic similarity threshold for semantic cache matches (0-1, default: 0.2). Values closer to 0 require higher similarity. Can be overridden by custom functions. - expirationSecondsTtl: The timeout of the cache in seconds (default: 3600, 1 hour). Can be overridden by custom functions. - namespace: Optional namespace to isolate cache entries (default: "default"). Useful for multi-tenant scenarios or different cache contexts. - cacheBy: Determines how cache keys are generated: 'function' for custom logic or 'propertyPath' to extract from JSON body. | ai-gateway |
+| semantic-cache-inbound | Semantic Cache (deprecated) | Respond to matched incoming requests with semantically cached content  The Semantic Cache Inbound policy caches responses based on semantic similarity of cache keys rather than exact matches. This allows for more flexible caching where similar requests can return cached responses even if the cache key is not exactly the same.  The policy uses Large Language Model (LLM) embeddings to determine semantic similarity between cache keys based on a configurable similarity tolerance.  Options: - semanticTolerance: The semantic similarity threshold for semantic cache matches (0-1, default: 0.2). Values closer to 0 require higher similarity. Can be overridden by custom functions. - expirationSecondsTtl: The timeout of the cache in seconds (default: 3600, 1 hour). Can be overridden by custom functions. - namespace: Optional namespace to isolate cache entries (default: "default"). Useful for multi-tenant scenarios or different cache contexts. - cacheBy: Determines how cache keys are generated: 'function' for custom logic or 'propertyPath' to extract from JSON body. | ai-gateway |
 | set-body-inbound | Set Body | Sets the body of the request in the inbound pipeline - make sure to convert a GET/HEAD request to another method when using this policy. | api-gateway |
 | set-headers-outbound | Set Headers | Adds or sets headers on the on the outgoing response. | api-gateway |
 | set-status-outbound | Set Status Code | Sets the status code on the on the outgoing response. | api-gateway |

package/docs/policies/ai-gateway-auth-v2-inbound/doc.md

@@ -0,0 +1,168 @@
+# AI Gateway Authentication
+
+The AI Gateway Authentication policy authenticates requests with an AI Gateway
+application API key. After a key is accepted, the calling application is
+identified on `request.user` — `sub` is the application name and `data` its
+metadata, both readable from custom policies — and the application's AI Gateway
+configuration (its selected policy chain, model access, and limits) takes effect
+for the request through the AI Gateway policies later in the route.
+
+Use this policy when an application (or every application on a route) must
+present an AI Gateway application API key.
+
+A missing or invalid key returns `401 Unauthorized`. A valid key that belongs to
+a different application than the route's `app_id` returns `403 Forbidden`.
+
+## Prerequisites
+
+Create the AI Gateway applications and their API keys before calling the
+gateway. Each client must use a key issued for one of those applications.
+
+## Add the policy
+
+Declare the policy in `config/policies.json`:
+
+```json
+{
+  "policies": [
+    {
+      "name": "ai-gateway-auth-v2-inbound",
+      "policyType": "ai-gateway-auth-v2",
+      "handler": {
+        "export": "AIGatewayAuthV2InboundPolicy",
+        "module": "$import(@zuplo/runtime)",
+        "options": {
+          "cacheTtlSeconds": 60
+        }
+      }
+    }
+  ]
+}
+```
+
+Authentication is optional. Choose where to attach it based on how widely keys
+should be required:
+
+### Per application (app-level)
+
+Add the policy to an application's `inboundPolicyChain`. Only that application
+requires an API key; other applications on the same route can omit it. The route
+should run the configuration executor alone so it can load configuration from
+the `app_id` path parameter before the app chain runs:
+
+```json
+{
+  "inboundPolicyChain": [
+    {
+      "name": "ai-gateway-auth-v2-inbound"
+    }
+  ]
+}
+```
+
+### Every application on the route (route-level)
+
+Add the policy on the route **before** the configuration loader (or before the
+executor on executor-only routes). That requires an API key for every
+application that hits the route:
+
+```json
+{
+  "x-zuplo-route": {
+    "corsPolicy": "none",
+    "handler": {
+      "export": "aiGatewayHandlerV2",
+      "module": "$import(@zuplo/runtime)",
+      "options": {}
+    },
+    "policies": {
+      "inbound": [
+        "ai-gateway-auth-v2-inbound",
+        "ai-gateway-configuration-loader-v2-inbound",
+        "ai-gateway-configuration-executor-v2-inbound"
+      ]
+    }
+  }
+}
+```
+
+When auth runs on the route, it loads the app configuration from the key and the
+loader/executor reuse that channel. When auth is omitted from the route (or only
+present in some apps' chains), the loader (or the executor alone) loads
+configuration from the route's `app_id` path parameter instead.
+
+> **Protect every public gateway.** Without this policy, the gateway resolves
+> the application from the URL and accepts the request without an application
+> key. Only leave authentication out when another control, such as network
+> isolation, restricts access. Team policy templates can include a locked auth
+> entry so new applications require keys by default.
+
+## Call the gateway
+
+By default, clients send the application key as a bearer token:
+
+```bash
+curl https://gateway.example.com/v1/chat/completions \
+  --header "Authorization: Bearer YOUR_APP_KEY" \
+  --header "Content-Type: application/json" \
+  --data '{
+    "model": "openai/gpt-5-mini",
+    "messages": [{ "role": "user", "content": "Hello" }]
+  }'
+```
+
+Authentication scheme matching is case-insensitive. A missing key, an invalid
+scheme, or a key that is not authorized receives a `401 Unauthorized` response.
+
+## Use a custom header
+
+Set `authHeader` to accept the key from another header. Set `authScheme` to an
+empty string when the header contains only the key:
+
+```json
+{
+  "name": "ai-gateway-auth-v2-inbound",
+  "policyType": "ai-gateway-auth-v2",
+  "handler": {
+    "export": "AIGatewayAuthV2InboundPolicy",
+    "module": "$import(@zuplo/runtime)",
+    "options": {
+      "authHeader": "x-api-key",
+      "authScheme": "",
+      "cacheTtlSeconds": 60
+    }
+  }
+}
+```
+
+Clients can then call the gateway with:
+
+```bash
+curl https://gateway.example.com/v1/chat/completions \
+  --header "x-api-key: YOUR_APP_KEY" \
+  --header "Content-Type: application/json" \
+  --data '{
+    "model": "openai/gpt-5-mini",
+    "messages": [{ "role": "user", "content": "Hello" }]
+  }'
+```
+
+## Choose a cache duration
+
+`cacheTtlSeconds` controls how long an authentication result can be reused. The
+minimum value is 10 seconds.
+
+- Use a shorter duration when key changes must take effect quickly.
+- Use a longer duration to reduce authentication latency and repeated validation
+  work.
+
+A revoked key can continue to work until its cached result expires.
+
+## Options
+
+- `cacheTtlSeconds`: Number of seconds to cache an authentication result.
+  Defaults to `10` and must be at least `10`.
+- `authHeader`: Header containing the application key. Defaults to
+  `Authorization`.
+- `authScheme`: Scheme before the key. Defaults to `Bearer`. Use `""` for a
+  header containing the key without a scheme.

package/docs/policies/ai-gateway-auth-v2-inbound/intro.md

@@ -0,0 +1,10 @@
+The AI Gateway Authentication policy protects an AI Gateway with application API
+keys. It identifies the calling application on `request.user` (`sub` is the
+application name, `data` its metadata) and puts the application's AI Gateway
+configuration into effect for the policies later in the request pipeline.
+
+Add it to an application's `inboundPolicyChain` to require a key for that app
+only, or place it on the route before the configuration executor to require a
+key for every application on the route. Clients can send keys with the standard
+`Authorization: Bearer` header or with a custom header and scheme.
+Authentication results can be cached briefly to reduce request latency.

package/docs/policies/ai-gateway-auth-v2-inbound/schema.json

@@ -0,0 +1,74 @@
+{
+  "$schema": "https://json-schema.org/draft-07/schema",
+  "$id": "https://cdn.zuplo.com/policies/runtime/schemas/ai-gateway-auth-v2-inbound.json",
+  "type": "object",
+  "title": "AI Gateway Authentication",
+  "isDeprecated": false,
+  "isPaidAddOn": false,
+  "isEnterprise": false,
+  "isInternal": false,
+  "isBeta": false,
+  "isHidden": false,
+  "requiresAI": true,
+  "policyType": "ai-gateway-auth-v2",
+  "products": ["ai-gateway"],
+  "description": "Authenticates requests to an AI Gateway endpoint with application API keys.\n\nAdd this policy to an application's `inboundPolicyChain` to require a key for that app only, or place it on the route before the configuration executor to require a key for every application on the route. The policies that follow can read the authenticated application from `request.user` (`sub` is the application name, `data` its metadata), and the application's AI Gateway configuration takes effect for the request. Use `authHeader` and `authScheme` when clients send their app key somewhere other than the default `Authorization: Bearer` header.\n\nWhen the matched route captures an `app_id` path parameter (platform catch-all `/:app_id/(.*)`), this policy also requires `configuration.id === request.params.app_id` and returns 403 on mismatch.",
+  "deprecatedMessage": "",
+  "required": ["handler"],
+  "properties": {
+    "handler": {
+      "type": "object",
+      "default": {},
+      "required": ["export", "module", "options"],
+      "properties": {
+        "export": {
+          "const": "AIGatewayAuthV2InboundPolicy",
+          "description": "The name of the exported type"
+        },
+        "module": {
+          "const": "$import(@zuplo/runtime)",
+          "description": "The module containing the policy"
+        },
+        "options": {
+          "x-zuplo-policy-type": "ai-gateway-auth-v2",
+          "title": "AIGatewayAuthV2InboundPolicyOptions",
+          "type": "object",
+          "description": "The options for this policy.",
+          "additionalProperties": false,
+          "required": [],
+          "properties": {
+            "cacheTtlSeconds": {
+              "type": "number",
+              "default": 10,
+              "minimum": 10,
+              "description": "The time to cache authentication results for a particular key. Higher values will decrease latency. Cached results will be valid until the cache expires even in the event the key is deleted, etc."
+            },
+            "authHeader": {
+              "type": "string",
+              "default": "Authorization",
+              "x-show-example": false,
+              "x-advanced": true,
+              "description": "The name of the header with the key."
+            },
+            "authScheme": {
+              "type": "string",
+              "default": "Bearer",
+              "x-show-example": false,
+              "x-advanced": true,
+              "description": "The scheme used on the header."
+            }
+          }
+        }
+      },
+      "examples": [
+        {
+          "export": "AIGatewayAuthV2InboundPolicy",
+          "module": "$import(@zuplo/runtime)",
+          "options": {
+            "cacheTtlSeconds": 10
+          }
+        }
+      ]
+    }
+  }
+}