zuplo 6.71.27 → 6.72.1

package/docs/analytics/access-and-entitlements.md

@@ -5,23 +5,22 @@ sidebar_label: "Access & Entitlements"
 
 ## When to use this
 
-- Confirm whether your account can see advanced analytics.
+- Confirm whether your account can see analytics.
 - Find out how many days of history you have access to.
 - Understand the trial banner or the demo mode link.
 
 ## Plan requirements
 
-Advanced analytics must be enabled on your account. Without it, the Analytics
-page shows an upsell view with a **Contact Sales** call-to-action and no charts.
+Analytics must be enabled on your account. Without it, the Analytics page shows
+an upsell view with a **Contact Sales** call-to-action and no charts.
 
 ## Free trial
 
-New accounts with advanced analytics enabled get an automatic free trial. The
-trial:
+New accounts with analytics enabled get an automatic free trial. The trial:
 
 - Runs for the same number of days as your account's retention window.
 - Shows a banner across the top of the Analytics page: "You're on a {N}-day
-  preview of Advanced Analytics, {N} days left."
+  preview of Analytics, {N} days left."
 - Includes two call-to-actions: **View demo →** (loads the dashboard with sample
   data) and **Contact sales**.
 
@@ -54,8 +53,8 @@ Append `?demo=true` to the Analytics URL, or click **View demo →** in the tria
 banner, to switch into demo mode. In demo mode:
 
 - Charts and tables are populated with synthetic sample data.
-- A persistent banner reads: "You're viewing the Advanced Analytics demo with
-  sample data. Your real analytics aren't shown here."
+- A persistent banner reads: "You're viewing the Analytics demo with sample
+  data. Your real analytics aren't shown here."
 
 Remove the `demo` parameter from the URL to return to your real data.
 

package/docs/analytics/overview.md

@@ -56,12 +56,12 @@ You'll see a subset of sections depending on your plan and project setup:
 
 | Section   | When it appears                                            |
 | --------- | ---------------------------------------------------------- |
-| Requests  | All accounts with advanced analytics enabled.              |
+| Requests  | All accounts with analytics enabled.                       |
 | Origins   | The project uses managed-edge origins.                     |
-| Consumers | All accounts with advanced analytics enabled.              |
-| Agents    | All accounts with advanced analytics enabled.              |
+| Consumers | All accounts with analytics enabled.                       |
+| Agents    | All accounts with analytics enabled.                       |
 | MCP       | The project type is **standard** and the project uses MCP. |
 | GraphQL   | The project proxies a GraphQL API.                         |
 
-If you don't see Analytics at all, your account likely doesn't have advanced
-analytics enabled. See [Access and entitlements](./access-and-entitlements.md).
+If you don't see Analytics at all, your account likely doesn't have analytics
+enabled. See [Access and entitlements](./access-and-entitlements.md).

package/docs/analytics/shared-controls.md

@@ -99,8 +99,8 @@ Banners appear at the top of the page in this priority order:
 1. **Preview banner**: when `preview=1` is set. Indicates legacy preview mode.
 2. **Demo banner**: when `demo=true` is set. Reminds you sample data is shown
    instead of your real analytics.
-3. **Trial banner**: for new accounts with advanced analytics. Shows days
-   remaining and offers **View demo →** and **Contact Sales**.
+3. **Trial banner**: for new accounts with analytics. Shows days remaining and
+   offers **View demo →** and **Contact Sales**.
 
 ## Loading and empty states
 

package/docs/articles/securing-backend-mtls.mdx

@@ -263,6 +263,9 @@ For more information on securing your backend, see:
   Alternative approach using shared secrets
 - [Secure Tunnels](./secure-tunnel.mdx) - Connect to private backends without
   exposing them to the internet
+- [Client mTLS Authentication](./securing-the-gateway-with-client-mtls.mdx) -
+  The reverse direction, where clients authenticate to your Zuplo gateway with a
+  client certificate
 
 If you need assistance configuring mTLS for your project, contact us at
 [support@zuplo.com](mailto:support@zuplo.com).

package/docs/dev-portal/zudoku/components/landing-page.mdx

@@ -10,7 +10,7 @@ A ready-made, customizable landing page for your developer portal. It comes in t
 covering the most common layouts: a centered hero, a two-column split hero, and a compact
 documentation hub.
 
-Use it as the `element` of a [custom page](/dev-portal/zudoku/custom-pages) — typically your home page:
+Use it as the `element` of a [custom page](/dev-portal/zudoku/guides/custom-pages) — typically your home page:
 
 ```tsx title=zudoku.config.tsx
 import { LandingPage } from "zudoku/components";

package/docs/policies/_index.md

@@ -57,7 +57,7 @@
 | ldap-auth-inbound | LDAP Auth | Authenticate requests using an LDAP server. | api-gateway |
 | mcp-cognito-oauth-inbound | MCP Amazon Cognito OAuth | Authenticate MCP gateway requests using a gateway-issued OAuth access token, with browser login delegated to Amazon Cognito.  Cognito-friendly wrapper around `McpOAuthInboundPolicy`. Provide an AWS region, user pool id, user pool domain, client id, and client secret; the constructor derives the Cognito issuer, JWKS URL, authorize URL, and token URL. | mcp-gateway |
 | mcp-auth0-oauth-inbound | MCP Auth0 OAuth | Authenticate MCP gateway requests using a gateway-issued OAuth access token, with browser login delegated to Auth0.  Auth0-friendly wrapper around `McpOAuthInboundPolicy`. Provide `auth0Domain` and `clientId`; the constructor derives the OIDC issuer, JWKS URL, and Auth0 authorize/token endpoints automatically and runs the resulting shape through the same Zod schema as the generic policy.  Validation runs lazily inside the policy constructor, which the runtime caches per policy name — so a misconfigured policy fails the first request with a `ConfigurationError` (surfaced in the 500 problem body) rather than crashing boot. | mcp-gateway |
-| mcp-capability-filter-inbound | MCP Capability Filter | Curate MCP capabilities advertised and reachable through `McpProxyHandler`.  Validation 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. | mcp-gateway |
+| mcp-capability-filter-inbound | MCP Capability Filter | Curate MCP capabilities advertised and reachable through `McpProxyHandler`.  Validation 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.  Optional per-caller access control (`accessControl`) narrows the curated catalog. See `claimsCapabilityResolver` for built-in role/group matching and `McpCapabilityResolver` for custom resolvers. | mcp-gateway |
 | mcp-clerk-oauth-inbound | MCP Clerk OAuth | Authenticate MCP gateway requests using a gateway-issued OAuth access token, with browser login delegated to Clerk.  Clerk-friendly wrapper around `McpOAuthInboundPolicy`. Provide Clerk's Frontend API URL plus the OAuth application client id and secret; the constructor derives the Clerk issuer, JWKS URL, authorize URL, and token URL. | mcp-gateway |
 | mcp-google-oauth-inbound | MCP Google OAuth | Authenticate MCP gateway requests using a gateway-issued OAuth access token, with browser login delegated to Google.  Google-friendly wrapper around `McpOAuthInboundPolicy`. Provide `clientId` and `clientSecret`; the constructor uses Google's fixed OIDC issuer, JWKS URL, authorize URL, and token URL, then runs the resulting shape through the same Zod schema as the generic policy. | mcp-gateway |
 | mcp-keycloak-oauth-inbound | MCP Keycloak OAuth | Authenticate MCP gateway requests using a gateway-issued OAuth access token, with browser login delegated to Keycloak.  Keycloak-friendly wrapper around `McpOAuthInboundPolicy`. Provide the Keycloak server root, realm, client id, and client secret; the constructor derives the realm issuer, JWKS URL, authorize URL, and token URL from Keycloak's documented OIDC endpoint layout. | mcp-gateway |

package/docs/policies/mcp-capability-filter-inbound/doc.md

@@ -50,6 +50,138 @@ gateway-managed upstream OAuth credentials. That order lets the token exchange
 policy retry or replace a 401 response first; this policy then filters the final
 upstream JSON-RPC response.
 
+## Access control
+
+`accessControl` narrows the curated catalog **per caller**. Its `mode` selects
+the strategy:
+
+- **`allPublic`** (default): no access control — every curated capability is
+  available to all callers. Setting `roles`/`groups`/`public` on a capability in
+  this mode is a configuration error (it would silently do nothing).
+- **`rolesAndGroups`**: match the caller's roles and groups — read from
+  `request.user.data` (see below) — against each capability's markup.
+- **`function`**: delegate to a custom resolver.
+
+### Mode `rolesAndGroups`
+
+Mark each capability with `roles` and/or `groups`, or `public: true`. **Every
+capability must be classified** — one that sets neither (or both) is rejected at
+load, so nothing is ever exposed by omission:
+
+```json
+{
+  "options": {
+    "tools": [
+      { "name": "search_invoices", "roles": ["billing", "admin"] },
+      { "name": "create_invoice", "roles": ["admin"], "groups": ["finance"] },
+      { "name": "list_products", "public": true }
+    ],
+    "accessControl": { "mode": "rolesAndGroups" }
+  }
+}
+```
+
+A caller may use a capability if it is `public`, or if the caller matches any
+listed role **or** any listed group (so `create_invoice` above is available to
+admins or to the finance team). Anonymous callers get only `public`
+capabilities. `roles`/`groups`/`public` are enforcement markup and are stripped
+from downstream responses — use `_meta` for hints you want clients to see.
+
+The caller's roles and groups come from `request.user.data` — the object an
+upstream authentication policy sets for the authenticated caller. What lands
+there depends on the policy: a JWT auth policy stores the token's claims, an API
+key policy stores the key's metadata, and so on. This policy reads the `roles`
+and `groups` properties by default. For example, behind a JWT auth policy a
+token with these claims:
+
+```json
+{
+  "sub": "user_8f3a",
+  "roles": ["billing"],
+  "groups": ["sales"],
+  "iss": "https://acme.us.auth0.com/",
+  "aud": "https://mcp.acme.com",
+  "exp": 1893456000
+}
+```
+
+`request.user.data.roles` is `["billing"]` and `request.user.data.groups` is
+`["sales"]`. Against the config above, this caller may use `search_invoices`
+(matches the `billing` role) and the public `list_products`, but not
+`create_invoice` (which needs the `admin` role or the `finance` group). A
+request with no authenticated caller (no `request.user`) has no roles or groups,
+so it sees only `public` capabilities.
+
+Use `roleClaim`/`groupClaim` to read different `request.user.data` properties,
+including a dot-path for nested values or a literal namespaced key:
+
+```json
+{
+  "accessControl": { "mode": "rolesAndGroups", "groupClaim": "cognito:groups" }
+}
+```
+
+```json
+{
+  "accessControl": {
+    "mode": "rolesAndGroups",
+    "roleClaim": "realm_access.roles"
+  }
+}
+```
+
+### Mode `function`
+
+For any other mapping — looking up entitlements from an external API, requiring
+both a role AND a group, blocklists, etc. — set `mode: "function"` and point
+`identifier` at a resolver (same `{ module, export }` shape as rate-limit). **It
+fully replaces the built-in roles/groups matching.** It receives
+`(request, context, options)` and returns the allowed identifiers; the result is
+always clamped to the configured catalog, so a resolver can only narrow access.
+A capability type left as passthrough (no static list) is not narrowed. A
+resolver that throws or returns no value fails closed.
+
+```json
+{
+  "accessControl": {
+    "mode": "function",
+    "identifier": {
+      "module": "$import(./modules/mcp-access-control)",
+      "export": "default"
+    }
+  }
+}
+```
+
+```ts
+// modules/mcp-access-control.ts
+import { ZuploRequest, ZuploContext, environment } from "@zuplo/runtime";
+import type {
+  McpCapabilityFilterInboundPolicyOptions,
+  AllowedCapabilities,
+} from "@zuplo/runtime/mcp-gateway";
+
+export default async function resolveCapabilities(
+  request: ZuploRequest,
+  context: ZuploContext,
+  options: McpCapabilityFilterInboundPolicyOptions
+): Promise<AllowedCapabilities> {
+  const subject = request.user?.sub;
+  if (!subject) return { tools: [] }; // fail closed for anonymous
+
+  const res = await fetch(
+    `https://entitlements.example.com/users/${encodeURIComponent(subject)}`,
+    { headers: { authorization: `Bearer ${environment.ENTITLEMENTS_API_KEY}` } }
+  );
+  if (!res.ok) {
+    context.log.warn(`entitlements lookup failed: ${res.status}`);
+    return { tools: [] };
+  }
+  const { allowedTools } = (await res.json()) as { allowedTools: string[] };
+  return { tools: allowedTools };
+}
+```
+
 ## Batch Requests
 
 For JSON-RPC batch requests, list responses are filtered per response item when

package/docs/policies/mcp-capability-filter-inbound/schema.json

@@ -11,7 +11,7 @@
   "isHidden": false,
   "requiresAI": false,
   "products": ["mcp-gateway"],
-  "description": "Curate MCP capabilities advertised and reachable through `McpProxyHandler`.\n\nValidation 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.",
+  "description": "Curate MCP capabilities advertised and reachable through `McpProxyHandler`.\n\nValidation 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.\n\nOptional per-caller access control (`accessControl`) narrows the curated catalog. See `claimsCapabilityResolver` for built-in role/group matching and `McpCapabilityResolver` for custom resolvers.",
   "deprecatedMessage": "",
   "required": ["handler"],
   "properties": {
@@ -67,6 +67,28 @@
                         "type": "object",
                         "additionalProperties": true,
                         "description": "Arbitrary MCP \\_meta fields to expose downstream."
+                      },
+                      "roles": {
+                        "type": "array",
+                        "minItems": 1,
+                        "items": {
+                          "type": "string",
+                          "minLength": 1
+                        },
+                        "description": "Access control: roles allowed to see and invoke this capability. Matched against the caller's roles on request.user.data (accessControl.roleClaim, default 'roles'). Used when accessControl.mode is 'rolesAndGroups'."
+                      },
+                      "groups": {
+                        "type": "array",
+                        "minItems": 1,
+                        "items": {
+                          "type": "string",
+                          "minLength": 1
+                        },
+                        "description": "Access control: groups allowed to see and invoke this capability. Matched against the caller's groups on request.user.data (accessControl.groupClaim, default 'groups'). Used when accessControl.mode is 'rolesAndGroups'."
+                      },
+                      "public": {
+                        "type": "boolean",
+                        "description": "Access control: mark this capability as available to all callers. In mode 'rolesAndGroups' every capability must set roles/groups OR public: true (not both) — an unclassified capability is a configuration error, so nothing is ever exposed by omission."
                       }
                     }
                   }
@@ -100,6 +122,28 @@
                         "type": "object",
                         "additionalProperties": true,
                         "description": "Arbitrary MCP \\_meta fields to expose downstream."
+                      },
+                      "roles": {
+                        "type": "array",
+                        "minItems": 1,
+                        "items": {
+                          "type": "string",
+                          "minLength": 1
+                        },
+                        "description": "Access control: roles allowed to see and invoke this capability. Matched against the caller's roles on request.user.data (accessControl.roleClaim, default 'roles'). Used when accessControl.mode is 'rolesAndGroups'."
+                      },
+                      "groups": {
+                        "type": "array",
+                        "minItems": 1,
+                        "items": {
+                          "type": "string",
+                          "minLength": 1
+                        },
+                        "description": "Access control: groups allowed to see and invoke this capability. Matched against the caller's groups on request.user.data (accessControl.groupClaim, default 'groups'). Used when accessControl.mode is 'rolesAndGroups'."
+                      },
+                      "public": {
+                        "type": "boolean",
+                        "description": "Access control: mark this capability as available to all callers. In mode 'rolesAndGroups' every capability must set roles/groups OR public: true (not both) — an unclassified capability is a configuration error, so nothing is ever exposed by omission."
                       }
                     }
                   }
@@ -143,6 +187,28 @@
                         "type": "object",
                         "additionalProperties": true,
                         "description": "Arbitrary MCP \\_meta fields to expose downstream."
+                      },
+                      "roles": {
+                        "type": "array",
+                        "minItems": 1,
+                        "items": {
+                          "type": "string",
+                          "minLength": 1
+                        },
+                        "description": "Access control: roles allowed to see and invoke this capability. Matched against the caller's roles on request.user.data (accessControl.roleClaim, default 'roles'). Used when accessControl.mode is 'rolesAndGroups'."
+                      },
+                      "groups": {
+                        "type": "array",
+                        "minItems": 1,
+                        "items": {
+                          "type": "string",
+                          "minLength": 1
+                        },
+                        "description": "Access control: groups allowed to see and invoke this capability. Matched against the caller's groups on request.user.data (accessControl.groupClaim, default 'groups'). Used when accessControl.mode is 'rolesAndGroups'."
+                      },
+                      "public": {
+                        "type": "boolean",
+                        "description": "Access control: mark this capability as available to all callers. In mode 'rolesAndGroups' every capability must set roles/groups OR public: true (not both) — an unclassified capability is a configuration error, so nothing is ever exposed by omission."
                       }
                     }
                   }
@@ -186,11 +252,76 @@
                         "type": "object",
                         "additionalProperties": true,
                         "description": "Arbitrary MCP \\_meta fields to expose downstream."
+                      },
+                      "roles": {
+                        "type": "array",
+                        "minItems": 1,
+                        "items": {
+                          "type": "string",
+                          "minLength": 1
+                        },
+                        "description": "Access control: roles allowed to see and invoke this capability. Matched against the caller's roles on request.user.data (accessControl.roleClaim, default 'roles'). Used when accessControl.mode is 'rolesAndGroups'."
+                      },
+                      "groups": {
+                        "type": "array",
+                        "minItems": 1,
+                        "items": {
+                          "type": "string",
+                          "minLength": 1
+                        },
+                        "description": "Access control: groups allowed to see and invoke this capability. Matched against the caller's groups on request.user.data (accessControl.groupClaim, default 'groups'). Used when accessControl.mode is 'rolesAndGroups'."
+                      },
+                      "public": {
+                        "type": "boolean",
+                        "description": "Access control: mark this capability as available to all callers. In mode 'rolesAndGroups' every capability must set roles/groups OR public: true (not both) — an unclassified capability is a configuration error, so nothing is ever exposed by omission."
                       }
                     }
                   }
                 ]
               }
+            },
+            "accessControl": {
+              "type": "object",
+              "additionalProperties": false,
+              "description": "Optional per-caller access control. Defaults to mode 'allPublic' (no access control). Set mode to 'rolesAndGroups' to match the caller's role/group claims against each capability's markup (every capability must then set roles/groups or public: true), or 'function' to delegate to a custom resolver.",
+              "properties": {
+                "mode": {
+                  "type": "string",
+                  "enum": ["allPublic", "rolesAndGroups", "function"],
+                  "default": "allPublic",
+                  "description": "Access-control strategy. 'allPublic' (default): no access control; roles/groups/public markup is not allowed. 'rolesAndGroups': match the caller's role and group claims against each capability's markup. 'function': delegate to the resolver named by 'identifier'."
+                },
+                "roleClaim": {
+                  "type": "string",
+                  "minLength": 1,
+                  "default": "roles",
+                  "description": "Property on request.user.data holding the caller's roles (commonly a JWT 'roles' claim, but request.user.data is set by whichever auth policy ran — JWT, API key, etc.), matched against each capability's 'roles'. Supports a dot-path for nested values, e.g. 'realm\\_access.roles'. Used in mode 'rolesAndGroups'. Defaults to 'roles'."
+                },
+                "groupClaim": {
+                  "type": "string",
+                  "minLength": 1,
+                  "default": "groups",
+                  "description": "Property on request.user.data holding the caller's groups (commonly a JWT 'groups' claim, but request.user.data is set by whichever auth policy ran — JWT, API key, etc.), matched against each capability's 'groups'. Supports a dot-path for nested values, e.g. 'cognito:groups'. Used in mode 'rolesAndGroups'. Defaults to 'groups'."
+                },
+                "identifier": {
+                  "type": "object",
+                  "additionalProperties": false,
+                  "required": ["module", "export"],
+                  "description": "Custom capability resolver, required when mode is 'function'. It fully replaces built-in roles/groups matching.",
+                  "properties": {
+                    "module": {
+                      "type": "string",
+                      "minLength": 1,
+                      "description": "Module to load the resolver from, e.g. $import(./modules/mcp-access-control)."
+                    },
+                    "export": {
+                      "type": "string",
+                      "minLength": 1,
+                      "description": "Named export of the resolver function, e.g. 'default'."
+                    }
+                  }
+                }
+              }
             }
           }
         }
@@ -200,6 +331,12 @@
           "export": "McpCapabilityFilterInboundPolicy",
           "module": "$import(@zuplo/runtime)",
           "options": {
+            "accessControl": {
+              "groupClaim": "groups",
+              "identifier": {},
+              "mode": "allPublic",
+              "roleClaim": "roles"
+            },
             "prompts": [],
             "resourceTemplates": [],
             "resources": [],

package/docs/policies/mcp-token-exchange-inbound/doc.md

@@ -65,9 +65,47 @@ can discover:
 2. The upstream protected resource metadata `scopes_supported` value.
 3. No `scope` parameter if the upstream does not advertise one.
 
-Explicit configured scopes always win. Use them for providers such as Microsoft
-365 where the correct resource-specific application scope is known from the
-provider configuration rather than from MCP discovery.
+Explicit configured scopes always win: they are sent as the `scope` parameter on
+the upstream authorization request even when the upstream advertises a different
+`scopes_supported` in its protected resource metadata. Use them for providers
+such as Microsoft 365 where the correct resource-specific application scope is
+known from the provider configuration rather than from MCP discovery, or to add
+`offline_access` when the upstream requires it for refresh-token issuance but
+does not advertise it.
+
+## Consent Prompt Override
+
+The MCP SDK that the gateway uses as its upstream OAuth client adds
+`prompt=consent` to the authorization request whenever the requested scope
+includes `offline_access`, because most providers require a fresh consent grant
+before issuing a refresh token. The gateway itself never injects `prompt`; the
+`prompt` option strips or replaces the SDK's parameter at the gateway's
+authorization seam. Some providers honor `prompt=consent` literally: Microsoft
+Entra ID forces the consent screen on every single authorization, even after a
+tenant admin has granted org-wide admin consent.
+
+Set `prompt` to control this behavior:
+
+- **Unset** (default): keep the SDK's behavior, including the automatic
+  `prompt=consent` for `offline_access`.
+- **`false`**: strip the `prompt` parameter from the authorization request. Use
+  this for Entra upstreams where a tenant admin has already granted admin
+  consent — users connect without seeing the consent screen, and refresh tokens
+  are still issued because admin consent satisfies the requirement.
+- **`"none"` / `"login"` / `"consent"` / `"select_account"`**: set or replace
+  the `prompt` parameter with an explicit value.
+
+Note that the effective scope can include `offline_access` even when `scopes` is
+not configured, because the gateway also reads scopes from the upstream's
+`WWW-Authenticate` challenge and protected resource metadata.
+
+**Warning**: stripping `prompt=consent` while requesting `offline_access` can
+silently prevent refresh-token issuance on providers that require a fresh
+consent grant for offline access (for example, Google). Only use `false` when
+the provider grants offline access through pre-authorized or admin consent, such
+as Entra tenant admin consent. If connections start requiring frequent
+reauthorization after setting `prompt: false`, remove the option so the consent
+grant is requested again.
 
 ## Route Shape
 

package/docs/policies/mcp-token-exchange-inbound/schema.json

@@ -71,6 +71,19 @@
               "type": "string",
               "description": "Delimiter used to join scopes in the OAuth authorization request. Defaults to a single space."
             },
+            "prompt": {
+              "description": "Overrides the OIDC `prompt` parameter on upstream authorization requests. The MCP SDK adds `prompt=consent` whenever the requested scope includes `offline_access`, which forces a consent screen on every authorization on providers like Microsoft Entra ID even after a tenant admin has granted org-wide admin consent. Leave unset to keep the SDK's behavior; set to `false` to strip the `prompt` parameter; set an explicit value to replace it. Warning: stripping `prompt=consent` while requesting `offline_access` can silently prevent refresh-token issuance on providers that require a fresh consent grant for offline access (e.g. Google) — only use this when the provider grants offline access via pre-authorized/admin consent (e.g. Entra tenant admin consent).",
+              "oneOf": [
+                {
+                  "type": "string",
+                  "enum": ["none", "login", "consent", "select_account"]
+                },
+                {
+                  "type": "boolean",
+                  "const": false
+                }
+              ]
+            },
             "clientRegistration": {
               "description": "OAuth client registration mode. Defaults to `auto`, which uses Client ID Metadata Documents when the upstream advertises support and falls back to Dynamic Client Registration otherwise.",
               "oneOf": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zuplo",
-  "version": "6.71.27",
+  "version": "6.72.1",
   "type": "module",
   "description": "The programmable API Gateway",
   "author": "Zuplo, Inc.",
@@ -19,9 +19,9 @@
     "zuplo": "zuplo.js"
   },
   "dependencies": {
-    "@zuplo/cli": "6.71.27",
-    "@zuplo/core": "6.71.27",
-    "@zuplo/runtime": "6.71.27",
+    "@zuplo/cli": "6.72.1",
+    "@zuplo/core": "6.72.1",
+    "@zuplo/runtime": "6.72.1",
     "@zuplo/test": "1.4.0"
   }
 }