chore: changelog for gateway 2.26.0

changelog/enterprise.mdx

@@ -1,13 +1,43 @@
 ---
 title: "Enterprise Gateway"
-sidebarTitle: "Enterprise Gateway [2.25.1]"
+sidebarTitle: "Enterprise Gateway [2.26.0]"
 rss: true
 ---
 
 <Card title="Schedule Call" href="https://www.paloaltonetworks.com/ai-security/ai-gateway#:~:text=See%20Prisma%20AIRS%20AI%20Gateway%20in%20Action" icon="calendar" horizontal>
 Discuss how Portkey's AI Gateway can enhance your organization's AI infrastructure
 </Card>
 
+<Update label="2.26.0" description="2026-10-01">
+
+## v2.26.0
+
+---
+
+### DashScope Image Generation
+
+DashScope is now supported on Portkey's unified `/v1/images/generations` endpoint. Image requests are priced per region, so token usage and cost are attributed correctly in logs and analytics.
+
+[DashScope Integration](/integrations/llms/dashscope) · [Image Generation](/product/ai-gateway/multimodal-capabilities/image-generation)
+
+### Gateway-Local JWT Auth: User-First Workspace Resolution
+
+Set `JWT_PREFER_USER_WORKSPACE_RESOLUTION=ON` so a user token that names no workspace resolves to the user's own membership instead of the deployment or organization default. A workspace named explicitly still takes precedence, and membership is enforced on whichever workspace is chosen.
+
+[Gateway-Local JWT Authentication](/product/enterprise-offering/org-management/jwt#workspace-resolution)
+
+### Provider Updates
+
+- **Google Gemini / Vertex AI**: Streaming chat completions now report `finish_reason: "tool_calls"` when the model makes a tool call, matching the non-streaming path. Clients that gate tool execution on this value no longer discard tool calls delivered in earlier chunks. [Gemini Integration](/integrations/llms/gemini) · [Vertex AI Integration](/integrations/llms/vertex-ai)
+- **Amazon Bedrock**: The `redact-thinking-2026-02-12` beta header is now stripped before the upstream call instead of causing a 400. Bedrock handles redacted thinking natively, so clients that send this header - including Claude Code with experimental betas enabled - now work against Bedrock. [AWS Bedrock Integration](/integrations/llms/bedrock/aws-bedrock)
+
+### Fixes and Improvements
+
+- **Guardrails**: PII redaction now applies to embedding requests. Redacted text is written back into the `input` field for both plain-string and structured inputs, so redactions are no longer dropped before the upstream call. Token-array inputs and non-text parts are left untouched. [PII Redaction](/product/guardrails/pii-redaction)
+- **Security**: Updated dependencies to patch security vulnerabilities.
+
+</Update>
+
 <Update label="2.25.1" description="2026-09-29">
 
 ## v2.25.1

product/enterprise-offering/org-management/jwt.mdx

@@ -586,6 +586,7 @@ Use this when tokens come from Okta, Auth0, Entra, Cognito, or another IdP whose
 | `ORGANISATIONS_TO_SYNC` | **Yes** | Comma-separated org UUIDs to sync from the control plane. Also restricts which orgs this gateway accepts. |
 | `PORTKEY_CLIENT_AUTH` | **Yes** | Service auth token for the gateway to sync org, workspace, and deployment settings from the control plane. |
 | `JWT_LOCAL_AUTH_DEFAULT_SCOPES` | No | Comma-separated gateway scopes to apply when the IdP token does not include `scope` or `scopes`. Use this when you cannot add Portkey scopes to tokens in your IdP. |
+| `JWT_PREFER_USER_WORKSPACE_RESOLUTION` | No | Set to `ON` to resolve a user token's own workspace membership before the deployment and organisation defaults. See [Workspace resolution](#workspace-resolution). Service tokens are unaffected. |
 
 Example:
 
@@ -725,6 +726,24 @@ Workspace is determined after the token is verified, using token claims first, t
 
 Whenever a request resolves to a specific workspace this way, the gateway verifies that the token's user is an active member of it, and rejects the request with **403** otherwise.
 
+#### Preferring the user's own workspace
+
+By default, when a user token does not name a workspace, the gateway tries the deployment default and the organisation default workspace before falling back to the user's own membership. Set `JWT_PREFER_USER_WORKSPACE_RESOLUTION=ON` on the gateway to try the user's own membership first.
+
+| Step | Default (flag off or unset) | `JWT_PREFER_USER_WORKSPACE_RESOLUTION=ON` |
+| ---- | --------------------------- | ----------------------------------------- |
+| 1 | `portkey_workspace` claim | `portkey_workspace` claim |
+| 2 | `workspace_slug` claim | `workspace_slug` claim |
+| 3 | `x-portkey-workspace` header hint (user tokens only) | `x-portkey-workspace` header hint (user tokens only) |
+| 4 | Deployment `sub` → workspace mapping | Deployment `sub` → workspace mapping |
+| 5 | Deployment default (first allowed workspace) | **The user's own membership** |
+| 6 | Organisation default workspace | Deployment default (first allowed workspace) |
+| 7 | The user's own membership | Organisation default workspace |
+
+Steps 1–4 are identical in both modes. The flag changes behaviour only for user tokens — those carrying a valid email claim. Service tokens always follow the default order.
+
+If the user-first lookup does not yield a workspace, the gateway falls back through the deployment default and then the organisation default. Membership is re-validated against whichever workspace is finally selected, so a user who is not an active member of the fallback workspace is still rejected with **403**.
+
 ### Usage limits, rate limits, and policies
 
 JWT-authenticated requests are subject to the same limit and policy checks as API key requests. Limits can come from three places: