zuplo 7.7.17 → 7.8.0

package/docs/ai-gateway/bedrock-runtime.mdx

@@ -243,23 +243,25 @@ into it.
 
 ## Policies on Bedrock Runtime routes
 
-These routes run your app's [policy chain](./policy-chains.mdx) like any other,
-with two differences that follow from the request body being Bedrock's shape
-rather than one the gateway parses:
-
-| Policy                                                                   | On Bedrock Runtime routes                                                                  |
-| ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
-| [Authentication](../policies/ai-gateway-auth-v2-inbound.mdx)             | Works. Reads the app key from `Authorization: Bearer`                                      |
-| [Model Filtering](../policies/ai-gateway-model-filtering-v2-inbound.mdx) | Works. Refuses a model outside the allow list before any AWS call                          |
-| [Metering and budgets](../policies/ai-gateway-metering-v2-inbound.mdx)   | Works. Meters tokens and cost on all four operations, streamed or not                      |
-| [DLP](../policies/ai-gateway-dlp-inbound.mdx) and content guardrails     | **Blocks by default.** The gateway doesn't parse these bodies, so `onUnknownShape` applies |
-| Semantic Cache                                                           | Skipped                                                                                    |
+These routes run your app's [policy chain](./policy-chains.mdx) like any other.
+What changes is that the request body is Bedrock's shape rather than one the
+gateway parses, so a policy that reads the body applies its `onUnknownShape`
+setting instead. Each policy's default follows from its job: a guardrail fails
+closed, while an observer or an optimization fails open.
+
+| Policy                                                                                                                        | On Bedrock Runtime routes                                                                                                                              |
+| ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| [Authentication](../policies/ai-gateway-auth-v2-inbound.mdx)                                                                  | Works. Reads the app key from `Authorization: Bearer`                                                                                                  |
+| [Model Filtering](../policies/ai-gateway-model-filtering-v2-inbound.mdx)                                                      | Works. Refuses a model outside the allow list before any AWS call                                                                                      |
+| [Metering and budgets](../policies/ai-gateway-metering-v2-inbound.mdx)                                                        | Works. Meters tokens and cost on all four operations, streamed or not                                                                                  |
+| [DLP](../policies/ai-gateway-dlp-inbound.mdx) and content guardrails                                                          | **Blocks by default.** The gateway can't read these bodies, so the policy denies the request. Set `onUnknownShape` to `skip` to forward it uninspected |
+| [Galileo](../policies/galileo-tracing-v2-inbound.mdx) and [Comet Opik](../policies/comet-opik-tracing-v2-inbound.mdx) tracing | **Skipped by default.** The request goes through untraced. Set `onUnknownShape` to `deny` to make a trace a hard requirement                           |
+| Semantic Cache                                                                                                                | Skipped                                                                                                                                                |
 
 The table lists every policy the gateway supports on these routes. It audits the
-chain and refuses any other policy, such as a custom policy, Smart Router,
-[Fallback Model](./fallback.mdx), or tracing, with a `400 ValidationException`
-that names the policy. Remove it from the chain to use Bedrock Runtime through
-that app.
+chain and refuses any other policy, such as a custom policy, Smart Router, or
+[Fallback Model](./fallback.mdx), with a `400 ValidationException` that names
+the policy. Remove it from the chain to use Bedrock Runtime through that app.
 
 If you need content inspection on Bedrock traffic, use
 [Bedrock's own guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html)

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

@@ -406,6 +406,32 @@ The corresponding expression is `request.headers.get("x-budget-customer")`.
 Configuration code should create that ordinary string and pass the enclosing
 object to `JSON.stringify`; the serializer adds the JSON transport escaping.
 
+Headers you set or remove in the inbound chain control what reaches your AI
+provider. For example, you can add a session header or remove an internal
+customer header before sending the request. Gateway-owned headers are excluded,
+including credentials, `Content-Type`, `Accept`, and headers starting with `zp-`
+or `cf-`; setting a credential header does not override your configured provider
+credential.
+
+That includes headers you add only for the gateway's own use. The
+`x-budget-customer` header above carries the caller's user id, and unless you
+remove it after the metering policy has read it, the provider receives it on
+every request. Add a `remove-headers-inbound` entry after the metering entry:
+
+```json
+[
+  { "name": "set-budget-dimension" },
+  { "name": "ai-gateway-metering-v2-inbound" },
+  {
+    "name": "remove-headers-inbound",
+    "options": { "headers": ["x-budget-customer"] }
+  }
+]
+```
+
+Declare `remove-headers-inbound` in `config/policies.json` so the chain can
+select it.
+
 Invalid budget rules and unsupported expressions are logged and skipped. Other
 valid rules continue to apply.
 

package/docs/policies/mcp-auth0-oauth-inbound/schema.json

@@ -52,7 +52,7 @@
             },
             "clientSecret": {
               "type": "string",
-              "examples": ["$env(MCP_AUTH0_CLIENT_SECRET)"],
+              "examples": ["$env(AUTH0_CLIENT_SECRET)"],
               "description": "The Auth0 client\\_secret. Use $env(...) to source from a secret environment variable."
             },
             "scope": {
@@ -209,7 +209,7 @@
               "sessionTtlSeconds": 28800,
               "stateTtlSeconds": 900
             },
-            "clientSecret": "$env(MCP_AUTH0_CLIENT_SECRET)",
+            "clientSecret": "$env(AUTH0_CLIENT_SECRET)",
             "gateway": {
               "accessTokenTtlSeconds": 900,
               "cimdEnabled": true,

package/docs/policies/mcp-oauth-inbound/schema.json

@@ -73,7 +73,7 @@
                   "type": "string",
                   "format": "uri",
                   "examples": ["https://my-tenant.us.auth0.com/authorize"],
-                  "description": "The IdP /authorize endpoint to redirect the user to. For local development on loopback, use http://127.0.0.1:9000/oauth/dev-login."
+                  "description": "The IdP /authorize endpoint to redirect the user to. For local development on loopback, use http://127.0.0.1:9000/\\_\\_zuplo/oauth/dev-login (the gateway's default basePath is /\\_\\_zuplo; adjust if the plugin is configured with a different one)."
                 },
                 "tokenUrl": {
                   "type": "string",

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

@@ -108,6 +108,52 @@ 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.
 
+## Authorization Server Issuer Mismatch
+
+Some providers publish inconsistent OAuth metadata: the protected-resource
+document advertises a path-scoped authorization server, but that server's own
+metadata reports a different (usually root-origin) `issuer`. ServiceNow is one —
+its protected-resource metadata names
+`https://<instance>.service-now.com/sncapps/...` while the metadata served there
+reports `https://<instance>.service-now.com`. Atlassian and Okta
+org-versus-custom authorization servers publish the same shape.
+
+RFC 8414 section 3.3 requires a client to reject a metadata document whose
+`issuer` differs from the identifier the well-known URL was built from, so the
+gateway hard-fails discovery against these providers. Set
+`skipIssuerMetadataValidation` to `true` on that connection to proceed anyway:
+
+```json
+{
+  "name": "mcp-token-exchange-servicenow",
+  "policyType": "mcp-token-exchange-inbound",
+  "handler": {
+    "module": "$import(@zuplo/runtime/mcp-gateway)",
+    "export": "McpTokenExchangeInboundPolicy",
+    "options": {
+      "displayName": "ServiceNow",
+      "authMode": "user-oauth",
+      "skipIssuerMetadataValidation": true
+    }
+  }
+}
+```
+
+**Warning**: this puts the connection out of spec. The issuer check is an
+unqualified MUST in both RFC 8414 section 3.3 and the MCP authorization spec,
+whose own example is the attack it prevents — a document served from
+`https://attacker.example/.well-known/oauth-authorization-server` claiming
+`"issuer": "https://honest.example"` must be rejected. The check binds the
+metadata to the TLS-authenticated host it came from, and with it off the gateway
+trusts the authorization, token and JWKS endpoints from a document that never
+proved it speaks for that issuer.
+
+Only enable it for a specific upstream known to publish a mismatched issuer, and
+only when the metadata URL's host is itself trusted. Never enable it as a
+default. It relaxes the discovery-time check only: the RFC 9207
+authorization-response check and the callback-leg authorization-server binding
+still apply.
+
 ## ID-JAG Token Exchange (Cross-App Access)
 
 Set `authMode` to `id-jag` when the upstream is protected by an Identity
@@ -128,8 +174,8 @@ Use this mode in enterprise deployments where the gateway and the upstream trust
 the same identity provider (for example, Okta Cross-App Access), so upstream
 access follows the caller's identity without a per-user upstream consent flow.
 The `user-oauth`/`shared-oauth` options — `scopes`, `scopeDelimiter`, `prompt`,
-and `clientRegistration` — do not apply; the `id-jag` mode is configured
-entirely through the `idJag` option.
+`skipIssuerMetadataValidation`, and `clientRegistration` — do not apply; the
+`id-jag` mode is configured entirely through the `idJag` option.
 
 ```json
 {

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

@@ -56,6 +56,9 @@
                 {
                   "required": ["prompt"]
                 },
+                {
+                  "required": ["skipIssuerMetadataValidation"]
+                },
                 {
                   "required": ["clientRegistration"]
                 }
@@ -120,6 +123,11 @@
                 }
               ]
             },
+            "skipIssuerMetadataValidation": {
+              "type": "boolean",
+              "x-advanced": true,
+              "description": "Skips the RFC 8414 section 3.3 issuer-echo check when discovering the upstream authorization server. That check requires the `issuer` in the authorization server's metadata to equal the `authorization_servers` entry the protected-resource metadata advertised. Some providers publish a path-scoped authorization server whose metadata reports the root origin instead — for example ServiceNow advertises `https://<instance>.service-now.com/sncapps/...` but its metadata reports `https://<instance>.service-now.com` — so discovery hard-fails without this option. Warning: enabling this puts the connection out of spec. The check is an unqualified MUST in both RFC 8414 section 3.3 and the MCP authorization spec, which require rejecting a metadata document whose `issuer` differs from the identifier the well-known URL was built from; the spec's own example is a document served from `https://attacker.example/.well-known/oauth-authorization-server` claiming `\"issuer\": \"https://honest.example\"`. The echo check binds the metadata to the TLS-authenticated host it came from, and with it off the gateway trusts the authorization, token and JWKS endpoints from a document that never proved it speaks for that issuer. Only enable it for a specific upstream known to publish a mismatched issuer, and only when the metadata URL's host is itself trusted. It relaxes the discovery-time check only — the RFC 9207 authorization-response check and the callback-leg authorization-server binding still apply."
+            },
             "clientRegistration": {
               "x-advanced": true,
               "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.",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zuplo",
-  "version": "7.7.17",
+  "version": "7.8.0",
   "type": "module",
   "description": "The official Zuplo CLI for local development and platform management",
   "homepage": "https://zuplo.com/docs/cli/overview",
@@ -32,9 +32,9 @@
     "zuplo": "zuplo.js"
   },
   "dependencies": {
-    "@zuplo/cli": "7.7.17",
-    "@zuplo/core": "7.7.17",
-    "@zuplo/runtime": "7.7.17",
-    "@zuplo/test": "7.7.17"
+    "@zuplo/cli": "7.8.0",
+    "@zuplo/core": "7.8.0",
+    "@zuplo/runtime": "7.8.0",
+    "@zuplo/test": "7.8.0"
   }
 }