What does Portkey Error Code 033 mean, and how can it be resolved for MCP Gateway access?

[Chen.Dequan]

Issue

Why does an Active Service Gateway API Key with MCP → INVOKE permission receive HTTP 403 / Portkey Error Code 033 when invoking MCP servers provisioned to the same admin-automation workspace in Strata Cloud Manager (SCM)?

Environment / Background

I am evaluating the PRISMA AIRS / AI Gateway MCP functionality in an SCM trial tenant.

A Tumor Board MCP server is registered in:

AI Security → AI Gateway → Integrations → MCP Registry

and provisioned to the admin-automation workspace.

Its catalog entry is:

• MCP server: tumor-board-mcp-server

• Gateway URL: https://mcp-aigw.portkey.ai/tumor-board-mcp-server/mcp

• Status: Active

• Backend authentication type: Headers

• Workspace: admin-automation

The backend MCP server itself has already been independently validated: MCP initialize, tools/list, and tools/call work when invoking the backend directly.

I also created an SCM Service Gateway API Key:

• Key name: tb-mcp-poc-client

• Type: Service

• Status: Active

• Permission: MCP → INVOKE

• Other permissions: disabled

• Workspace used during creation: admin-automation

Critical Information / Reproduction

I can reproduce the same failure against two different MCP servers.

1. Tumor Board MCP Server

Request:

POST https://mcp-aigw.portkey.ai/tumor-board-mcp-server/mcp

with:

x-portkey-api-key: <active Service Gateway API key>

and a valid MCP initialize JSON-RPC request.

Result:

HTTP 403 Forbidden

Portkey Error: Forbidden!. Error Code: 033

Request information:

• Time: 2026-10-29 15:15:46 GMT

• CF-RAY: a5232336ad43356f-ORD

2. HR MCP Server — A/B comparison

The hr-mcp server is also provisioned to admin-automation, but its backend Auth Type is none.

Request:

POST https://mcp-aigw.portkey.ai/hr-mcp/mcp

using the same Service Gateway API Key and the same MCP initialize request.

Result:

HTTP 403 Forbidden

Portkey Error: Forbidden!. Error Code: 033

Request information:

• Time: 2026-10-29 15:16:14 GMT

• CF-RAY: a52323e5bd0a356f-ORD

Because both MCP servers return the same Error 033—including hr-mcp, whose backend authentication type is none—the failure does not appear to be specific to the Tumor Board backend authentication.

Additional Tenant Observations

Workspace:

• Workspace: admin-automation

• Workspace members: 0

• No workspace rate limit

• No workspace budget limit

• No workspace guardrail assigned

• No relevant MCP policy found under Policies & Profiles

User Gateway API Key:

• User key creation shows: “No users found”

OAuth 2.1 discovery/testing:

• Protected Resource Metadata discovery succeeds

• Authorization Server Metadata discovery succeeds

• Dynamic Client Registration succeeds (HTTP 201)

• Authorization endpoint fails with:

  • access_denied

  • Organisation identity could not be resolved

Service Gateway API Key:

• Status: Active

• Permission: MCP → INVOKE

• Request header: x-portkey-api-key

• Result against both MCP servers: HTTP 403 / Portkey Error 033

AI Gateway Observability:

• The rejected MCP requests do not appear in Analytics, Errors, or Logs for the admin-automation workspace.

Questions

1. What does Portkey Error Code 033 specifically mean?

2. Is x-portkey-api-key with an Active Service Gateway API Key and MCP → INVOKE permission supported for non-interactive access to an SCM AI Gateway MCP endpoint such as https://mcp-aigw.portkey.ai/<server-slug>/mcp?

3. If yes, is any additional organization, workspace, service identity, or MCP-resource authorization required for the Service Gateway API Key?

4. Is the fact that admin-automation currently has 0 workspace members related to Error 033 for a Service API key, or is that relevant only to the user/OAuth flow?

5. Could PANW please use the two CF-RAY IDs/timestamps above to determine at which authorization layer the requests are being rejected?

Thank you.

Dequan Chen, Ph.D.
Mayo (MC)

[Chen.Dequan]

Additional finding regarding the suggested x-portkey-virtual-key remediation

Strata Copilot, citing PANW technical documentation, indicated that the HTTP 403 / Portkey Error 033 can occur because my MCP requests contain x-portkey-api-key but not the workspace virtual key in x-portkey-virtual-key.

I attempted to follow the documented remediation. In the current SCM UI, workspace creation is performed through:

AI Security → AI Gateway → Workspace Control → Create from Workspace Management → + New Workspace

I created a new workspace named mcp-poc-validation specifically to capture the generated virtual key. No virtual key was displayed during or after workspace creation.

To verify this was not a one-time UI issue, I repeated the creation. SCM successfully created a second, distinct mcp-poc-validation workspace, but again no virtual key was displayed.

The two workspaces have distinct workspace identifiers/slugs and distinct Scope Name values in Workspace Management, confirming that two separate workspace objects were successfully created. However:

• no field is labeled Virtual Key or Workspace Virtual Key;

• Workspace Control does not display a virtual key;

• Workspace Management displays a Scope Name, but the UI/documentation does not identify Scope Name as the x-portkey-virtual-key credential;

• the workspace details link/copy control only copies the SCM workspace URL.

PANW documentation/Strata Copilot also states that the workspace virtual key is shown only once and cannot subsequently be retrieved, regenerated, or rotated.

Could PANW please clarify:

1. Is x-portkey-virtual-key actually required for the current SCM MCP Gateway endpoint when using an Active Service Gateway API Key with MCP → INVOKE?

2. If it is required, where/how is the virtual key generated and displayed in the current Workspace Management / Workspace Control UI, given that two newly created workspaces displayed no virtual key?

3. Is the Workspace Management Scope Name a non-secret workspace identifier, or is it intended to be supplied as x-portkey-virtual-key?

4. Is the current SCM trial-tenant UI using a newer MCP Gateway authentication model in which workspace context is derived differently from the general AI Gateway virtual-key model?

I have not attempted to use the workspace Scope Name, slug, or workspace UUID as x-portkey-virtual-key because none of these values is identified by SCM as a virtual-key credential.