Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 33 additions & 1 deletion changelog/enterprise.mdx
Original file line number Diff line number Diff line change
@@ -1,13 +1,45 @@
---
title: "Enterprise Gateway"
sidebarTitle: "Enterprise Gateway [2.27.0]"
sidebarTitle: "Enterprise Gateway [2.28.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.28.0" description="2026-10-08">

## v2.28.0

---

### OAuth Client Credentials for AWS Providers

Amazon Bedrock, Bedrock Mantle, SageMaker, and the Claude Platform on AWS can now authenticate using the OAuth Client Credentials grant, alongside existing IAM access key and assumed-role auth. The gateway acquires and caches a bearer token from your configured token endpoint instead of signing requests with AWS credentials.

[AWS Bedrock Integration](/integrations/llms/bedrock/aws-bedrock) · [Bedrock Mantle Integration](/integrations/llms/bedrock-mantle) · [AWS SageMaker Integration](/integrations/llms/aws-sagemaker) · [Claude Platform on AWS](/integrations/llms/claude-platform-aws)

### Gateway-Local JWT Auth: Just-in-Time Service Access

Set `JWT_JIT_USER_ACCESS=ON` so a user token that fails the workspace membership check is admitted as a `WORKSPACE_SERVICE` key instead of being rejected with a `403`. The `x-portkey-workspace` header hint is ignored for these requests, and the workspace resolves the same way it would for a service token.

[Gateway-Local JWT Authentication](/product/enterprise-offering/org-management/jwt#workspace-resolution)

### Provider Updates

- **Vertex AI**: Provisioned Throughput cost attribution on proxy requests (`x-portkey-custom-host`) now correctly detects PTU traffic from the raw Vertex response, instead of being charged at on-demand rates. [Vertex AI Integration](/integrations/llms/vertex-ai)

### Fixes and Improvements

- **Pricing**: New `DISABLE_TIKTOKEN` environment variable skips the tiktoken encoder and estimates token usage as `chars/4` on CPU-constrained hosts, trading exact counts for lower CPU cost. Only affects the usage fallback used when a provider doesn't return its own token counts. [Cost Management](/product/observability/cost-management)
- **MCP Gateway**: External-auth servers now keep their credential in the gateway cache on the connect path too, matching the authorization path, instead of reading it from and saving it to the control plane. [External OAuth](/product/mcp-gateway/authentication/external-oauth)
- **MCP Gateway**: OAuth route audit logs now record the HTTP status the client actually received, so a handler that returned an error response is logged as Blocked instead of Allowed. [MCP Observability](/product/mcp-gateway/observability)
- **Observability**: The `/v1/health` endpoint now reports `last_synced_at`, the timestamp of the gateway's last successful sync with the control plane.
- **Security**: Updated dependencies to patch security vulnerabilities.

</Update>

<Update label="2.27.0" description="2026-10-06">

## v2.27.0
Expand Down
7 changes: 7 additions & 0 deletions product/enterprise-offering/org-management/jwt.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -587,6 +587,7 @@ Use this when tokens come from Okta, Auth0, Entra, Cognito, or another IdP whose
| `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. |
| `JWT_JIT_USER_ACCESS` | No | Set to `ON` to admit a user token that fails the workspace membership check as a `WORKSPACE_SERVICE` key instead of rejecting with `403`. See [Workspace resolution](#workspace-resolution). |

Example:

Expand Down Expand Up @@ -744,6 +745,12 @@ Steps 1–4 are identical in both modes. The flag changes behaviour only for use

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**.

#### Just-in-time service access for non-members

By default, a user token that resolves to a workspace it is not a member of is rejected with **403**. Set `JWT_JIT_USER_ACCESS=ON` to instead admit the request as a `WORKSPACE_SERVICE` key: the membership check is skipped, any `x-portkey-workspace` header hint is discarded, and the workspace is resolved the same way it would be for a service token (signed claim → deployment `sub` mapping → deployment default → organisation default).

This trades per-user attribution for availability — use it when non-member requests should still be served under the workspace's service-level limits and policies rather than failing outright.

### 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:
Expand Down
Loading