Prisma AIRS AI Gateway Deployment

The gateway monitors and audits three classes of AI traffic from a single dashboard:

• LLM prompts — requests and responses between your applications and model providers.
• MCP interactions — Model Context Protocol traffic between agents and MCP servers, including servers authenticated with API keys or static tokens via custom headers.
• Agent-to-agent (A2A) communication — traffic exchanged directly between AI agents.

All three classes are metered by token consumption against your flex credit allocation, and all three appear in the unified AI Gateway dashboard.

• Unified AI traffic visibility — monitor and audit all AI interactions across prompts, MCP, and A2A traffic from a single dashboard.
• Flexible logging — event logs stream to SIEM (security information and event management) and SOAR (security orchestration, automation, and response) tools via OpenTelemetry-compatible endpoints; prompt logs are stored natively with 1-year retention on SaaS, and on Hybrid deployments they are written to the customer-owned object store configured in Step 2.5.
• AI Runtime guardrail — Prisma AIRS AI Runtime scans prompts and responses through the gateway against an AI security profile; configured in Step 5.2. Applications that call the AIRS Scan API themselves, as the AIRS API Intercept guide shows, keep working.
• Guardrails — Basic and third-party guardrails are supported on top of that; Check Language and Detect Gibberish are included in the Basic tier.
• Flex credit licensing — metered by token consumption (1 token equals 4 characters), with identical pricing across both deployment models.
• SCM-managed — full lifecycle management through Strata Cloud Manager with access scoped by SBAC (the SCM role model that grants administrators access to specific tenants and folders).

Strata Logging Service (SLS) integration for Threat Logs is supported.

AI Gateway reuses the SCM tenancy and access model rather than inventing its own. Two mappings matter for everything that follows:

When Phase 3 talks about provisioning an integration to a workspace, that workspace is an SCM workspace, and who can touch it is governed by SBAC roles. When Phase 1 maps your deployment profile to a TSG, that TSG is your AI Gateway organization boundary.

Five things must already be true before the AI Gateway tile will do anything useful:

1. An activated Prisma AIRS license (AI Runtime Security, shortened to AIRS throughout this guide). If your organization has not activated it yet, complete Activate Your AI Runtime Security License first.
2. A cloud account onboarded and activated in Strata Cloud Manager, per Onboard and Activate a Cloud Account in SCM.
3. A Customer Support Portal (CSP) account on the support account that owns your flex credit pool, with a role that can view Software NGFW (Next-Generation Firewall) Credits and create deployment profiles. Step 1.3 happens entirely in the Customer Support Portal, not in SCM; if you cannot log in at support.paloaltonetworks.com or cannot see the credit pool, request access from your organization's CSP Super User before continuing.
4. Flex credits remaining in the pool that will fund the gateway.
5. An SCM user whose role shows the AI Security entry in the left navigation; if it is missing, ask your SCM administrator to grant it.

Three more things are consumed later in the guide, so line them up now:

• An API key for the LLM provider you will connect, pasted in Step 3.2.
• Claude Code, Anthropic's command-line coding assistant, installed on the workstation you will test from; the worked examples in Steps 3.9 and 4.5 run it (or another client from Client variations). Install it with the native installer from the Claude Code install page, which also lists Homebrew, WinGet, apt, dnf, apk, and npm options:

  # macOS, Linux, WSL
  curl -fsSL https://claude.ai/install.sh | bash
  
  # Windows PowerShell
  irm https://claude.ai/install.ps1 | iex

  Copy
  Then open a terminal and run claude --version; it must print a version number such as 2.1.211 (Claude Code) before you start Step 3.9. You do not need a claude.ai login for the gateway path; the gateway key replaces it.
• An AIRS API key linked to an AI security profile, from Phase 3 of the AIRS API Intercept guide, used in Step 5.2.

All AI Gateway metering is token-based. Every AI transaction through the gateway (prompts, MCP interactions, and A2A traffic) draws down flex credits by token usage, and you license the instance against your maximum expected monthly token consumption.

The token conversion is the industry standard:

1 token = 4 characters of text

estimated monthly tokens = total characters sent and received per month / 4

billion tokens per month = estimated monthly tokens / 1,000,000,000

Example: 12,000,000,000 characters per month
  tokens   = 12,000,000,000 / 4 = 3,000,000,000
  billions = 3,000,000,000 / 1,000,000,000 = 3

To build the estimate, inventory the applications, agents, and MCP servers that will route through the gateway, and for each one approximate: requests per month, average prompt size (including system prompts and context), and average response size. Sum the character counts, divide by 4, and add headroom for growth.

The deployment profile is the licensing object that funds AI Gateway. You create it in the Customer Support Portal (not Strata Cloud Manager), from the credit pool that holds your flex credits. Creating it and finishing setup (next step) is what activates the gateway for your tenant.

1. Log in to the Palo Alto Networks Customer Support Portal.
2. In the left navigation, expand Products and select Software NGFW Credits. (Flex credits for every Software NGFW and Prisma AIRS product, AI Gateway included, come from the same pools, so this is the right page.)
3. Locate the credit pool that will fund the gateway and click its name (or its row) to open the pool page; if several are listed, open the one with the most remaining credits. Item 8 shows how many credits this profile will draw; if that number exceeds the pool's remaining credits, close the dialog without creating the profile and repeat from this item with another pool. The pool page shows total credits, the allocated and consumed meters, the expiration date, and, at the bottom, the Current Deployment Profiles table.
4. Before creating anything, scroll to the Current Deployment Profiles table. If a row with product type AI-GW and the Profile Name you chose (or planned to choose) already exists from an earlier attempt, do not create another; it already holds a credit allocation. Skip to Step 1.4 and use that row's Finish Setup link. An AI-GW row with a different name belongs to another deployment; leave it alone and create yours. If you created a profile by mistake, open the vertical ellipsis (More Options) at the far right of its row and select Delete; Palo Alto Networks documents this control for other Software NGFW credit profiles, including Prisma AIRS ones. If the menu offers no Delete, open an admin case in the Customer Support Portal or ask your account team to remove the profile and return its credits.
5. Click Create New Profile (above the Current Deployment Profiles table).
6. In the Create Deployment Profile: STEP 1 dialog, the products are laid out in labeled columns. Find the column headed Prisma AIRS: and click AI Gateway within it so its option is selected. The dialog calls this the firewall type because the same wizard provisions Software NGFW products; AI Gateway is not a firewall, and selecting it here is correct. Click Next.
7. Complete the FORM stage:
   • Deployment — select the option matching your deployment model, chosen in Choose Your Deployment Model: Managed Service if you chose SaaS, Self Service (DIY) if you chose Hybrid. The field is informational and does not change the credit allocation or the usage limit; if undecided, choose Managed Service.
   • Profile Name — a descriptive name, for example AI-Gateway-Deployment-Profile.
   • Billion tokens per month — the billions figure you calculated in Step 1.2.
   • Bundled — no action needed. Strata Cloud Manager Pro is bundled with AI Gateway automatically and cannot be deselected. Its cost is included in the credit estimate you see in the next item, so that estimate covers more than AI Gateway alone.
   • Notes — optional.
8. Click Calculate Estimated Cost. The dialog shows how many credits this profile will draw and how many remain available in the pool; this is the flex credit allocation.
9. Click Create Deployment Profile. The dialog closes and returns you to the Software NGFW Credits credit pool page, with your new profile listed in the Current Deployment Profiles table at the bottom.

Credit pool page with the Create New Profile button (steps 3 to 5):

STEP 1: find the Prisma AIRS column and select AI Gateway (step 6):

▶ See screenshots — the FORM stage field by field

FORM: choose the Deployment type (step 7):

FORM: name the profile (step 7):

FORM: enter the monthly token volume (step 7):

Estimated cost in credits (step 8):

Created profile row (verification):

Mapping the deployment profile to a Tenant Service Group (TSG) is the link that connects Strata Cloud Manager and the Strata Logging Service to your AI Gateway. The TSG you map becomes the AI Gateway organization (see the concept mapping in the Architecture Overview). The activation form labels the TSG as the Tenant.

1. On the same Software NGFW Credits credit pool page from Step 1.3, scroll to the Current Deployment Profiles table and click the Finish Setup link on your AI-GW profile row. If you navigated away after the last step, get back via Products → Software NGFW Credits and reopen the same pool. The Activate Subscriptions based on Deployment Profile(s) page opens.
2. Under Select Customer Support Account, choose the support account used to create the deployment profile.
3. Under Specify the Recipient, select the Tenant that will own the gateway. This is the TSG. To confirm which name is yours, open the hub with the account you used in Step 1.1, select Common Services → Tenant Management, find the tenant you work in, and select the matching Tenant here. If only one tenant is listed, select it.
4. Under Select Region, choose your region (for example, United States - Americas). The form will not proceed without it.
5. Under Select Deployment Profile(s), check the AI Gateway profile you created (its services column reads Strata Cloud Manager Pro, AI Runtime Security Gateway). Profiles already associated with this tenant are pre-checked; leave them checked, so the selected count will read higher than one. Unchecking a pre-checked profile removes its association when you activate. Click Done.
6. Leave Data Loss Prevention and Additional Services (including Cloud Identity Engine) at their pre-populated defaults; AI Gateway uses neither. A greyed-out DLP field is expected.
7. Check Agree to the Terms and Conditions, then click Activate.

▶ See screenshots

Activation page: select the Customer Support Account (step 2):

Region is required before activation can proceed (step 4):

Locate the AI Gateway profile in the deployment profile table (step 5):

Check the AI Gateway profile and click Done; the other checked rows are existing associations, left in place on purpose (step 5):

Leave DLP and Cloud Identity Engine at their pre-populated defaults (step 6):

Agree to the terms and activate (step 7):

With licensing in place, complete setup from inside SCM:

1. Log in to Strata Cloud Manager.
2. In the left navigation, select AI Security → Home.
3. On the Home page, locate the AI Gateway card under Select a feature to begin onboarding. On a fresh tenant (status Not Started) it offers three actions: Go to Gateway Registration, Launch AI Gateway, and Deploy Hybrid. Do not click any of them; Phase 2 works from the left navigation.

▶ See screenshots

The AI Security entry in the left navigation (step 2):

The AI Security menu with Home at the top and the AI Gateway section below (step 2):

The AI Gateway onboarding card with its three actions (step 3):

1. In the left navigation, select AI Security → AI Gateway → Integrations. The page opens on the LLM Integrations tab (alongside MCP Registry, Secret References, and Agent Integrations) and shows the total integration count. If you are recreating an integration from an earlier attempt, delete the old row now (delete action at the end of its row, then confirm) so its slug is free; the wizard rejects a slug still in use, and reusing the slug keeps existing clients working.
2. Click + Add LLM Integration.
3. On the Select the LLM Provider page, click the tile for your provider; it shows as selected.
4. Click Next: Set Details.

▶ See screenshots

Integrations in the AI Gateway navigation (step 1):

The Integrations page on a fresh tenant, with the Add LLM Integration button (step 2):

The provider catalog with Anthropic selected (steps 3–4):

The Basic Integration Details page opens with your selected provider shown at the top. Steps 3.2 through 3.4 all happen on this one page.

1. Provide a Name for the integration (required), for example default-anthropic.
2. Optionally provide a Short Description.
3. Enter the Slug, for example default-anthropic: lowercase letters, digits, and hyphens only, unique in your organization. It becomes part of the model reference (@<slug>/<model>, Step 3.7). If the field auto-filled from the Name, check it against that rule. The slug is explained in full below, and it is worth getting right before any client is pointed at it.
4. Paste the provider API Key. If you do not know where to get one, click the Grab API Key link next to the field for provider-specific instructions.

Your screen should look like this:

What the slug is, and what depends on it

The slug is a value you invent here. Nothing in the customer environment supplies it, and it is not derived from anything the provider issues. Once a client is pointed at it, the dependency runs the other way: the slug is the address applications use, so changing it means changing every caller.

It is the second half of the model reference. An application that used to name a model directly now names the integration and the model together:

Before, calling the provider directly
  base URL:  https://api.anthropic.com
  model:     claude-sonnet-4-20250514

After, calling through the gateway
  base URL:  https://<your gateway host>
  model:     @default-anthropic/claude-sonnet-4-20250514
             └──── slug ────┘ └──── model ────┘

Optional fields: some providers expose additional optional fields on this page, such as a project ID or organization. Fill them if your provider account uses them; the Anthropic example shows none.

The Advanced Options section further down the same page covers two routing features:

1. Enter the Custom Host URL if this integration targets a privately hosted or local model (the field shows the expected format, for example https://api.example.com/v1).
2. Under Custom headers, enter the header name (for example Authorization) and its value for any extra header the provider or custom host requires on every request. Click + Add Header to add more header and value pairs as needed. MCP servers are registered separately in Phase 4.

A token placed here is shared by every workspace, like the provider key in Step 3.2; scope it minimally.

Pricing Adjustments apply a discount or markup multiplier to the integration so cost tracking reflects your effective rate with the provider. A multiplier of 1 leaves pricing unchanged, 0.8 applies a 20% discount, and 1.2 applies a 20% markup. This affects cost reporting only; it does not change how traffic is routed.

If you do not have negotiated provider rates, leave the toggle off and go to item 4.

1. Switch on the Pricing Adjustments toggle at the bottom of the details page.
2. Select the mode: Form (the default) for the most common token types, or JSON for the full multiplier shape, including reasoning, audio, image, and additional units.
3. In Form mode, enter a Default multiplier; every token type you leave unset inherits it. To give a token type its own rate, set Request Tokens, Response Tokens, Cache Read Tokens, or Cache Write Tokens. For a discount, the multiplier is 1 minus the discount percentage divided by 100: a 10% discount on Default is 0.90, and a 15% discount on Request Tokens is 0.85, which leaves response, cache read, and cache write tokens at 0.90.
4. When the details page is complete, click Next: Choose Workspace.

Workspace provisioning determines which teams and projects can access this integration. Sharing credentials with a workspace means:

• That workspace sees the integration as an AI Provider in its Model Catalog.
• The workspace can use it immediately; there is no need to enter credentials again.
• You can set different budgets and rate limits for each workspace.
• You can revoke access at any time.

1. On the Workspace Access, Budget & Rate Limits stage, check the box next to each workspace that gets access (the toolbar offers Select All, Deselect All, and a search filter). Workspaces are created under AI Security → AI Gateway → Workspace Control; a new tenant has one default workspace.
2. For the worked example, check the default workspace, leave Automatically provision this integration for new workspaces off, and do not open Set Value. If you need limits or automatic provisioning, open Set a budget or rate limit for a workspace below before item 3.

The workspace stage with one workspace selected and its Set Value action:

▶ Set a budget or rate limit for a workspace

1. Optionally enable Automatically provision this integration for new workspaces. Every workspace created afterwards then receives this integration with the budget and rate limits set here. On a first deployment leave it off: limits cannot be edited once applied, so settle your values first. You can turn it off at any time without changing workspaces already provisioned.
2. For each workspace, click Set Value (or select several and use Set Value for All Selected) to open the Set Budget and Rate Limits panel.

Set Value opens the budget and rate limit panel for that workspace:

Add Budget: a budget limit caps what a workspace can spend through this integration, and it cascades down to all AI Providers created from this integration.

1. In the panel, switch on Add Budget.
2. Choose the budget type with the Request or Token selector (the API key form in Step 3.8 labels the same pair Cost and Tokens):
   • Request — a budget in dollars entered in the Budget Limit ($) field. Once reached, the gateway blocks further usage for that workspace through this integration until the budget resets.
   • Token — enter the maximum token count in the field beneath the type selector; this caps usage independent of cost fluctuations.
3. Optionally fill the Alter Threshold ($) field with a dollar amount below the budget limit.
4. Set the dropdown beneath Alter Threshold to one of the options below. The panel labels this dropdown Set Rate Limit, the same label as the rate limit field, and the capture shows it on Reset Weekly before any change:
   • No Periodic Reset — the budget limit applies until exhausted, with no automatic renewal.
   • Reset Weekly — resets at the beginning of each week (Sunday at 12 AM UTC).
   • Reset Monthly — resets on the 1st calendar day of the month at 12 AM UTC, irrespective of when the budget limit was set.
5. If you are setting only a budget, click Apply. Clicking Cancel or closing the panel discards the values.

What Alter Threshold means

The field carries no description in the UI, but it maps to the underlying gateway platform's alert threshold; the on-screen label is a typo, and the API key form in Step 3.8 labels the same control Alert Threshold ($). When spend crosses this amount, the gateway raises an alert without blocking traffic; requests are blocked only when the Budget Limit itself is reached. Example: a Budget Limit of 500 with a threshold of 400 warns at $400 of spend and cuts off at $500. A common practice is to set it at 80% of the budget.

Add Rate Limit: a rate limit caps how many requests or tokens a workspace can send through this integration per time window, which stops a runaway process from consuming capacity the other teams need.

1. In the panel, switch on Add Rate Limit.
2. Choose the limit type with the Request or Token selector:
   • Request-based — limit the number of API calls (for example, 1000 requests per minute).
   • Token-based — limit the token consumption rate (for example, 1M tokens per hour).
3. Enter the limit in Set Rate Limit and choose the time window in the unit dropdown next to it. Its options read Requests/Minute, Requests/Hour, and Requests/Day (or the Tokens/ forms when the Token type is selected). Per minute is the finest control; per day suits broad usage patterns.
4. Click Apply. Clicking Cancel or closing the panel discards the values.

Minimums, cadence, and scope are in the Budget and rate limit quick reference.

Budget and rate limits cannot be edited once set

Once set, neither budget limits nor rate limits can be edited by any organization member. The only way to change a workspace's limit is to remove that workspace's access and provision it again with new values: delete the integration from the LLM Integrations tab and recreate it (Step 3.2) with the same slug so clients keep working. Traffic from that workspace fails between the delete and the recreate. This guide has not confirmed whether spend already recorded against the old integration carries over; after recreating, check the workspace's spend on the Observability Analytics page before relying on the new limit. Decide the budget amount, type, and reset cadence deliberately, model your peak legitimate traffic before committing a rate value, and remember that 0 turns the provider off entirely.

Default workspace

A first deployment provisions the default workspace. As you add SCM workspaces for more teams under AI Security → AI Gateway → Workspace Control, return here to grant or deny each one access with its own limits.

3. With every intended workspace checked (and any limits applied), click Next: Select Models at the bottom of the stage.

One integration, many workspaces

Everything you provision here hangs off a single integration, which means a single slug and a single provider key. Every workspace you check addresses the integration by the same @<slug>/<model> reference. The slug is not per team, and there is no per-workspace variant of it.

Plenty does stay separate, though. On one shared integration each workspace still gets:

• Its own budget and rate limit — set individually on this page
• Its own gateway API key — created in Step 3.8 and scoped to that workspace
• Its own attribution — usage and logs separate out by workspace
• Independent revocation — unchecking a workspace removes its access without touching the others

What is not separate is the provider key, which every provisioned workspace consumes without seeing, and the model allowlist, which Step 3.6 sets for the integration as a whole.

The models you enable here are the only ones workspaces can call through this integration; unlike budgets and rate limits, this list can be changed later.

1. On the Select Models to Provision stage, toggle on the models you want to enable, either individually or with Select All (a search filter helps on long lists). The models you leave off stay unavailable to workspaces, forming your allowlist.
2. For the Claude Code worked example, click Select All so every model is enabled, then prune the list later once you know which models your clients send. If you would rather enable only the models Claude Code uses, run /status inside a Claude Code session to read the model the session uses, or run /model to open the model picker and see or change it. Claude Code v2.1.280 and later defaults to Opus 5.5 (claude-opus-5-5) unless you choose another model, and with the gateway key in ANTHROPIC_AUTH_TOKEN (Step 3.9) it sends background tasks to that same model. The captures in this guide show claude-fable-5.
3. Click Set Pricing on a model as needed. The Update Base Model panel opens with an Add custom pricing for this model? toggle; when enabled you can set Input Cost, Output Cost, Cache Pricing (as JSON, for cache write and cache read token prices), and an optional per-model Custom Host. Left unspecified, the model uses default public pricing. Click Apply.
4. Optionally switch on Automatically enable new models from this provider: new models the provider releases become available on this integration by default, and you can disable them later.
5. If a model you need is not in the list, click + Add Model (top right).
6. Click Create Integration.

▶ See screenshots

The model list with per-model toggles, Set Pricing, Add Model, and the auto-enable option (steps 1–5):

Set Pricing opens the Update Base Model panel (claude-fable-5 shown) (step 3):

After Create Integration, the new integration appears in the list (step 6):

The integration is live, so the next step is pointing a real application at it. Any application needs three values from your tenant, none of which is the provider key from Step 3.2 (workspace members never see that one). This step records the first two; Step 3.8 creates the third.

• Gateway base URL — the endpoint applications send requests to, replacing the provider's own API endpoint.
• Model reference — the provisioned model to call, addressed through the integration slug from Step 3.2 (this is where the slug appears in request paths and configs).
• Gateway API key — the credential the application presents to the gateway, scoped to a workspace (Step 3.8).

1. In the left navigation, select AI Security → AI Gateway → Admin Settings (the last entry in the AI Gateway section). The page opens on the General tab, showing the Organization Details panel.
2. Get your gateway base URL.
   SaaS (Default) Hybrid

   Read the Gateway URLs value (https://aigw.portkey.ai/v1 in the capture below). Record it without the trailing /v1, as https://aigw.portkey.ai; that is your gateway base URL. Every client in this guide adds its own path to it.

   Your base URL is the address you built in Step 3.7 (Hybrid); ignore the Gateway URLs field, which is the hosted SaaS endpoint. The API key and the model reference below come from the same SCM tenant either way.

3. In the left navigation, select AI Security → AI Gateway → Integrations. On the LLM Integrations tab (its Connected view lists created integrations), click your integration's row (the default-anthropic worked example). The integration panel slides open on its Integration Details tab; the slug appears as a pill with a copy icon in the panel header, and again in the Slug field below. Record it.
4. Switch to the panel's Model Provisioning tab. Provisioned LLMs lists every model you enabled in Step 3.6; record the Model Name of the model your application will use (for example claude-fable-5). The slug and model name combine into the model reference your application sends: @<integration-slug>/<model-name>, for example @default-anthropic/claude-fable-5.

▶ See screenshots

Admin Settings sits at the bottom of the AI Gateway navigation (step 1):

The General tab's Organization Details panel holds both gateway addresses (step 2):

Click the integration's row on the Integrations page (step 3):

The integration panel opens with the slug in the header and the Model Provisioning tab highlighted (steps 3 and 4):

Provisioned LLMs lists the model names to record (step 4):

The gateway API key is the credential an application presents to the gateway. It is scoped to a workspace and carries its own permissions and optional limits, so each application or person gets their own. The form does not show which workspace the key is scoped to. Every AI Gateway page has a Workspace selector at the top left, next to the breadcrumbs, and each key belongs to a single workspace; this guide has not confirmed that the selector sets the new key's workspace, so check that it names the intended workspace before you click + Create New. On a fresh tenant with one default workspace there is nothing to choose, and the key can only reach the integrations from Step 3.5 and the MCP servers from Step 4.3 that were provisioned to that workspace. If the tenant has more than one workspace, create the key, then send the Step 3.9 curl test; a 401 or an error naming the model means the key landed in a workspace that is not provisioned in Step 3.5, so revoke it and recreate it after selecting the right workspace. This worked example creates a personal key for Claude Code; Step 3.10 shows how the same form labels keys for agents.

1. In the left navigation, select AI Security → AI Gateway → Security Keys. The Gateway API Keys page opens with two tabs: Service and User. For this worked example (Claude Code running as you), select the User tab, then click + Create New. A User key is a personal access credential tied to your identity; choose the Service tab instead when creating a key for a backend application or automation that runs unattended.
2. The Create New Gateway API Key page opens: a two-stage wizard (API Key Details, then Permissions) with the API Key Type preset to User ("For a specific user's access"). Fill in the details:
   • API Key Name — name the key so it identifies its holder or consuming application (the capture uses drod-api).
   • Short Description — optional, up to 100 characters; say whose access this is so the row explains itself later.
   • Configuration — leave as is for now; the dropdown reads No configurations available until configs exist on the Policies & Profiles Configuration tab. Step 5.2 creates the AI Runtime guardrail config; keys created after that can select it here, and a key that already exists attaches it per request instead (Step 5.2, item 5).
   • Metadata — optional JSON tags attached to every request made with the key. Enter {"actor": "human", "_user": "<your-email>"} now; Step 3.10 explains the scheme and adds the agent variant.
3. Leave every toggle under Controls & Limits off for the worked example. No workspace limits were set in Step 3.5, so this key is unbounded until you revoke it on this page, and on SaaS it authenticates from any internet address (Step 2.1); a leaked key spends against the provider account until revoked. Before issuing personal keys to other people, switch on Auto Expire and set an expiry date, and set a workspace budget in Step 3.5; personal keys end up in local files and shell history and should not be permanent. The five controls are described under Gateway API key controls and limits in the Reference section.
4. Click Next: Set Permissions. The Set up Permissions stage lists five permissions, each pairing a gateway resource with the one action that applies to it (the other action columns show n/a). A search filter plus Select All and Unselect All sit above the table:
   • Completions — Write: send LLM requests through the gateway. This is the permission Claude Code's prompt traffic uses.
   • Agents — Invoke: call agent integrations registered on the gateway.
   • Mcp — Invoke: call MCP servers brokered by the gateway (Phase 4).
   • Logs — Write: submit entries to the gateway's logging pipeline.
   • Prompts — Render: fetch rendered prompt templates managed on the gateway.
   For this worked example select Completions (Write), which Claude Code's prompt traffic uses. Also select Mcp (Invoke) if you intend to complete Phase 4 (optional), because Step 4.5 reuses this same key for MCP tool calls; if you will skip Phase 4, leave it unselected. Decide now: this guide has not confirmed that a key's permissions can be changed after creation, and the pattern elsewhere in the guide is to replace the key. Leave Agents, Logs, and Prompts unselected; nothing in this guide calls them. For a Service key powering a single application, follow the same rule and grant only the permissions that application actually calls.
5. Click Create Gateway API Key. The Save your Gateway API Key dialog opens with the key masked. Click the copy icon next to the key (or Copy and Close) and paste the key somewhere safe now; it is never shown again. Only then close the dialog. The key appears on the User tab with a masked value and Active status.

▶ See screenshots

Security Keys with the User tab and Create New highlighted (step 1):

The API Key Details stage with the name and metadata fields highlighted (step 2):

The optional per-key controls: rate limit, budget, and rotation policy (step 3):

Auto Expire and Email Notifications close out the optional controls (step 3):

Next: Set Permissions advances to the second wizard stage (step 4):

The permissions matrix and Create Gateway API Key highlighted; the capture shows all five selected, where the worked example selects Completions and Mcp only (steps 4 and 5):

The one-time key dialog; copy it before closing (step 5):

After closing, the key lists as Active on the User tab (step 5):

Use this procedure whenever a key is lost, exposed, or needs a property that cannot be edited in place (Metadata, Configuration, or permissions). Later steps point here rather than repeating it.

1. Create the new key in Step 3.8, with the same type, Metadata, and permissions as the old one, plus whatever changed (for example the Step 5.2 config selected in the Configuration dropdown).
2. Update ANTHROPIC_AUTH_TOKEN in ~/.claude/settings.json (Step 3.9, item 6), and in any shell that still exports it.
3. If Phase 4 is in use, run claude mcp remove --scope user <server-name>, then re-add the server with the new key (Step 4.5).
4. Update AIGW_API_KEY in your shell profile if Codex or an SDK application uses it (Client variations).
5. Delete the old key: on the User or Service tab of AI Security → AI Gateway → Security Keys, click the trash icon at the right end of the old key's row.

The three variables, what each one does, and how to prove the routing took:

Claude Code reads three environment variables for gateway routing: ANTHROPIC_BASE_URL for the gateway endpoint, ANTHROPIC_AUTH_TOKEN for the credential (sent as an Authorization: Bearer header), and ANTHROPIC_CUSTOM_HEADERS to pin the integration (explained after the list). Test with shell exports first, then persist the values in a settings file. The exports in item 1 last only for that terminal session; if you are resuming in a new terminal, re-run item 1 before item 4, or go to item 6 first so the settings file carries the values.

If ~/.claude/settings.json already contains ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, or ANTHROPIC_CUSTOM_HEADERS from an earlier attempt, remove those three entries now or correct them to the values you are about to export; the settings file overrides the shell, so stale entries make the curl test pass and Claude Code fail.

1. Open a terminal. Every placeholder in this step maps to a value recorded in Steps 3.7 and 3.8:
   • <gateway-base-url> — SaaS: https://aigw.portkey.ai, the Gateway URLs value with /v1 removed as recorded in Step 3.7, because Claude Code appends its own /v1/messages. Hybrid: the address you built in Step 3.7 (Hybrid), for example https://<hostname> behind your ingress, or http://localhost:8787 through a port-forward for a first test, with no /v1.
   • <gateway-api-key> — the User key copied from the Save your Gateway API Key dialog in Step 3.8
   • <integration-slug> — the slug alone, for example default-anthropic
   Copy the block below, then replace all three angle-bracket placeholders with your own values before pressing Enter. The shell accepts the placeholder text without complaining, and the curl test in item 3 then fails in a way that is hard to trace back to this step. Keep the surrounding double quotes. The key line lands in your shell history; the Keep the key out of shared settings files callout below shows how to avoid that.

   export ANTHROPIC_BASE_URL="<gateway-base-url>"
   export ANTHROPIC_AUTH_TOKEN="<gateway-api-key>"
   export ANTHROPIC_CUSTOM_HEADERS="x-portkey-provider: @<integration-slug>"

   Copy
2. Confirm the substitution worked before moving on:

   echo "$ANTHROPIC_BASE_URL"

   Copy
   That must print your gateway address, not angle brackets. If it prints a string containing angle brackets, the placeholders were never replaced; re-run the exports with real values.
3. Confirm the gateway answers before opening Claude Code. Replace <model-reference> in the body with the slug and model name combined from Step 3.7 (for example @default-anthropic/claude-fable-5):

   curl -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
     -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
     -H "anthropic-version: 2023-06-01" \
     -H "content-type: application/json" \
     -d '{"model": "<model-reference>", "max_tokens": 32,
          "messages": [{"role": "user", "content": "Say OK"}]}'

   Copy
   A JSON response starting with {"id":"msg_ and containing a "content":[...] field proves the URL and credential work. An error naming an unknown model still proves both, because the gateway authenticated the request before rejecting the model name. If curl fails: a connection refused or timeout means the base URL (Step 3.7) is wrong or, on Hybrid, the port-forward is not running; a 401 means the key is wrong, revoked, from another tenant, or scoped to the wrong workspace (Step 3.8); a 400 mentioning x-portkey-provider means the third export was not set in this terminal.
4. In the same terminal, run claude, then run /status inside the session. The output includes an Anthropic base URL line (shown only when a gateway address is set) and an Auth token line confirming which credential is active.
5. Send any prompt, then open AI Security → AI Gateway → Observability in SCM and check the Logs tab: the request appears with its model, token counts, and cost, and the Analytics panels tick up from zero.
6. Persist the configuration so every future session routes through the gateway. If ~/.claude/settings.json does not exist, create it with exactly the block below. If it already exists, add the "env" key inside the existing top-level object, alongside your other settings, rather than pasting the whole block; if an env object already exists, add the three entries inside it rather than adding a second env key. The file must remain a single JSON object:

   {
     "env": {
       "ANTHROPIC_BASE_URL": "<gateway-base-url>",
       "ANTHROPIC_AUTH_TOKEN": "<gateway-api-key>",
       "ANTHROPIC_CUSTOM_HEADERS": "x-portkey-provider: @<integration-slug>"
     }
   }

   Copy
   Hybrid: persist the ingress address from Step 3.7 (Hybrid), https://<hostname>. If you have not built the ingress yet, persist http://localhost:8787 and start the port-forward before each session; it only works while that kubectl port-forward command is running, so a new session without it fails until you start it again.

▶ See screenshots

The base URL and auth token exported in the terminal, key redacted; the third export follows the same pattern (step 1):

The curl test answered by the gateway; the response opens with an id of msg_ and the requested model replies OK (step 3):

/status now shows the gateway rows (step 4):

A prompt answered through the gateway; the session banner reads API Usage Billing instead of your subscription plan (step 5):

The Analytics Overview after the first request: cost, tokens, latency, one request, one user (step 5):

The request row on the Observability Logs tab: timestamp, model, path, tokens, and cost (step 5):

All three variables in the env block at the top of your own ~/.claude/settings.json, key redacted; any existing settings keep their place below it (step 6):

For other providers and other clients, see Provider variations and Client variations, next.

The Anthropic walkthrough is this guide's worked example, but the wizard is identical for every provider in the catalog: the four stages (provider, details, workspaces, models) never change. What changes is the Basic Integration Details page, where each provider requests its own credential and optional fields. For each provider: select its tile in Step 3.1, give it a Name and Slug in Step 3.2, fill the fields below, then continue with Steps 3.5 and 3.6. The model reference is @<slug>/<model-name> with the Model Name from Provisioned LLMs (Step 3.7). The sections below cover the most common providers.

▶ Open AI

Field names in this section that are not shown in bold are descriptions rather than exact labels; match each to the closest field on your tenant's details page. OpenAI needs a single platform API key. The two optional IDs make the usage reported by the gateway line up with the OpenAI organization and project that are billed for it.

• Tile — listed as Open AI in the catalog.
• API Key — a secret key from the OpenAI platform; use the Grab API Key link if you need to create one.
• Organization ID (optional) — pins requests to one OpenAI organization. Set it when the key's owner belongs to several organizations, so usage is billed to the right one.
• Project ID (optional) — scopes requests to one OpenAI project, which keeps usage and cost tracking per project. Mainly needed with legacy user keys that can reach more than one project.
• Streaming and cost — with stream: true OpenAI returns no usage data, so tokens and cost log as zero and budget enforcement never sees the spend. The application has to send stream_options: {include_usage: true}. This applies to every OpenAI-compatible provider, Azure OpenAI included.
• Model reference — @<your-slug>/<model-name>, for example @default-openai/gpt-4.1 if you used default-openai as the slug in Step 3.2.

How the call reaches OpenAI, and the scope line between the OpenAI API and the ChatGPT app:

▶ Azure OpenAI

Field names in this section that are not shown in bold are descriptions rather than exact labels; match each to the closest field on your tenant's details page. Azure OpenAI serves models from a resource you deploy in your Azure subscription, so the details page asks for the resource and its deployments rather than just a key. Gather three things before you start: the resource name, the name of each model deployment you want to expose, and the api-version value your existing Azure OpenAI requests use for that deployment.

• Resource name — the name of the Azure OpenAI resource, which is the first label of its endpoint host (https://<resource-name>.openai.azure.com).
• Deployments — one entry per deployment you want to expose, each with its deployment name and API version, with one entry flagged as the default. A deployment is the name you gave a model when you deployed it in Azure, not the underlying model's name.
• Authentication — one of three modes. API key: the resource's key from the Azure portal, the simplest option and the one to start with. Entra ID: a service principal identified by tenant ID, client ID, and client secret, so the gateway requests tokens instead of holding a resource key. Assign the principal the Cognitive Services OpenAI User role on the resource. It permits inference calls with Entra ID but cannot read keys or change deployments; do not use Contributor or Owner. Managed identity: for Hybrid data planes running on Azure infrastructure that has a managed identity, with the same role assignment on the resource and an optional client ID to select a user-assigned identity. The client secret is stored in the Strata Cloud Manager control plane like a provider key (Step 3.2); set an expiry on it in Entra and record where the rotation is tracked.
• Model reference — applications address a deployment through its name: @<your-slug>/<deployment-name>, for example @default-azure-openai/<deployment-name> if you used default-azure-openai as the slug in Step 3.2.

How the call reaches Azure, and why the catalog carries Azure OpenAI and Azure AI Foundry as separate entries:

▶ Bedrock

Field names in this section that are not shown in bold are descriptions rather than exact labels; match each to the closest field on your tenant's details page. Bedrock access is governed by AWS identity rather than a single provider key, so the details page offers three ways to authenticate. Every option also needs the AWS region where the models are enabled.

• Access key — an IAM user's access key ID and secret access key, plus the region. Quickest to set up; the key is long-lived, so rotate it on a schedule.
• Assumed role — a role ARN, the region, and an optional external ID. The gateway obtains temporary credentials through STS, so no long-lived secret is stored. The role's trust policy must allow the principal the gateway runs as to assume it: for a Hybrid data plane on EKS that is the role the pods assume through their service account (Step 2.5). For SaaS the principal belongs to the hosted gateway and is not shown in this guide, so use one of the other two options unless you have it.
• Bedrock API key — an API key generated in the Bedrock console, plus the region.
• Permissions — whichever identity you use, grant it bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on the models you provision. If you call models through inference profiles, it also needs bedrock:GetInferenceProfile on arn:aws:bedrock:*:*:inference-profile/* and arn:aws:bedrock:*:*:application-inference-profile/*, because the gateway resolves the profile to its foundation model before sending the request.
• Model reference — @<your-slug>/<model-id> with the full Bedrock model ID, including any cross-region prefix, for example @default-bedrock/us.anthropic.claude-3-7-sonnet-20250219-v1:0 if you used default-bedrock as the slug in Step 3.2.

How the call reaches Bedrock, and where the prompt physically travels on the way:

Claude Code speaks the Anthropic protocol, which is why Step 3.9 trimmed the /v1 suffix and pinned the integration with a header. Most other tools speak the OpenAI protocol instead, and for those the recipe is simpler: use the gateway address with a /v1 suffix, present the gateway key as the API key, and put the full @<integration-slug>/<model-name> reference in the model field. No provider header is needed because the model reference already names the integration. In every section below, <gateway-base-url> is the same value as in Step 3.9 (no /v1), and the /v1 is appended in the configuration; the key and model reference come from Steps 3.7 and 3.8.

import os
from anthropic import Anthropic

client = Anthropic(
    base_url="<gateway-base-url>",
    auth_token=os.environ["AIGW_API_KEY"],
)

message = client.messages.create(
    model="<model-reference>",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello through the gateway"}],
)

import os
from openai import OpenAI

client = OpenAI(
    base_url="<gateway-base-url>/v1",
    api_key=os.environ["AIGW_API_KEY"],
)

response = client.chat.completions.create(
    model="@<integration-slug>/<model-name>",
    messages=[{"role": "user", "content": "Hello through the gateway"}],
)
print(response.choices[0].message.content)

Give every person a User key and every agent a Service key, tagged as in this table. Key metadata (the JSON in the key's Metadata field, Step 3.8) is set by the admin and cannot be changed by the caller; request metadata (a JSON object the client sends in the x-portkey-metadata header, where the reserved key _user drives the per-user analytics) is the caller's own claim; and key metadata wins when both carry the same key. Keep the tag names consistent across the tenant, because the filters you build later depend on them.

How a cost or audit question is traced back from a log row to a person or a team:

Values are strings of at most 128 characters.

If you have no agent yet, create one Service key named test-agent with metadata {"actor": "agent", "agent": "test-agent"} and use it as the bearer token in the Step 3.9 curl command; that request stands in for the agent request in item 5 and in Step 5.1.

1. Create one Service key per agent (or the test-agent key above). In the left navigation select AI Security → AI Gateway → Security Keys, open the Service tab, and click + Create New. The wizard is the one from Step 3.8 with the API Key Type set to Service. Name the key after the agent, and in the Metadata editor enter:

   {"actor": "agent", "agent": "<agent-name>"}

   Copy
   This page is also where a per-agent budget belongs: enable Add Budget or Add Rate Limit under Controls & Limits if the agent should be capped independently of the people in its workspace (the controls are described under Gateway API key controls and limits in the Reference section). On the permissions stage grant only what the agent calls, typically Completions (Write), plus Mcp (Invoke) if it uses MCP servers through the gateway (Phase 4).
2. Create User keys for people the same way on the User tab, with the person's identity in the metadata:

   {"actor": "human", "_user": "<email>"}

   Copy
   The Step 3.8 worked example already carries this metadata. A key created earlier with different or no metadata is identified by its name and type in the logs, and the request-level header in the next item tags its traffic too; to change its Metadata, replace the key.
3. Have interactive tools tag their own requests. For Claude Code, add a second line to ANTHROPIC_CUSTOM_HEADERS from Step 3.9: the variable takes one Name: Value pair per line, written as \n inside the JSON string of ~/.claude/settings.json:

   {
     "env": {
       "ANTHROPIC_BASE_URL": "<gateway-base-url>",
       "ANTHROPIC_AUTH_TOKEN": "<gateway-api-key>",
       "ANTHROPIC_CUSTOM_HEADERS": "x-portkey-provider: @<integration-slug>\nx-portkey-metadata: {\"_user\": \"<email>\", \"client\": \"claude-code\"}"
     }
   }

   Copy
   For a one-off shell test the same two lines can be exported with a real newline between them:

   export ANTHROPIC_CUSTOM_HEADERS=$'x-portkey-provider: @<integration-slug>\nx-portkey-metadata: {"_user": "<email>", "client": "claude-code"}'

   Copy
   For Codex, add a static header to the provider block from Client variations; single quotes make a TOML literal string, so the JSON needs no escaping:

   [model_providers.aigw]
   name = "Prisma AIRS AI Gateway"
   base_url = "<gateway-base-url>/v1"
   env_key = "AIGW_API_KEY"
   wire_api = "responses"
   http_headers = { "x-portkey-metadata" = '{"_user": "<email>", "client": "codex"}' }

   Copy
4. Have agents tag their requests in code, so a run can name the person it is acting for. With the Anthropic Python SDK the header goes on the client as a default:

   import json
   from anthropic import Anthropic
   
   client = Anthropic(
       base_url="<gateway-base-url>",
       auth_token="<service-key>",
       default_headers={
           "x-portkey-metadata": json.dumps({"_user": "<end-user>", "run_id": "<run-id>"}),
       },
   )

   Copy
   The OpenAI SDK takes the same header through its default_headers argument. OpenAI-style requests have a shortcut as well: a user field in the request body is mapped to _user automatically, with an explicit _user in the header taking precedence if both are present.
5. Verify the split in SCM. Send one request from Claude Code and one from an agent, then open AI Security → AI Gateway → Observability. On the Logs tab, click each row: the Request Details panel names the API key that made the call and shows its metadata, including actor. The Search Filter bar above the log table accepts metadata filters, so you can narrow the list to actor = agent.

MCP traffic does not use the base URL from Step 3.7. The gateway listens for it separately, so the first task is finding the right address and recording it as <mcp-base>, the value every later step in this phase builds on.

kubectl get svc airs-gw -n airs-gw -o jsonpath='{range .spec.ports[*]}{.name}{"\t"}{.port}{"\t"}{.targetPort}{"\n"}{end}'

kubectl port-forward -n airs-gw pod/<gateway-pod-name> 8787:8787 <mcp-container-port>:<mcp-container-port>

Confirm the endpoint answers before going further:

curl -s <mcp-base>/health

Registration is what tells the gateway that a server exists, where to reach it, how to authenticate to it, and which workspaces may call it. It is the MCP equivalent of the LLM integration you built across Steps 3.1 through 3.6. The Add MCP Server page is a two-stage wizard, with MCP Integration Details and Workspace Provisioning listed down the left side; this step covers the first stage and Step 4.3 covers the second. The worked example values below use Context7, a public documentation-lookup MCP server that needs no credential.

1. In the left navigation, select AI Security → AI Gateway → Integrations. The page opens on the LLM Integrations tab used in Phase 3; switch to the MCP Registry tab alongside it. The registry opens on its Connected view, which is the one this step uses. If you are re-registering a server from an earlier attempt, delete the old row now (delete action at the end of its row) so its slug is free.
2. Click + Add MCP Servers. On a tenant with no servers registered yet, the tab shows an empty state reading No MCP Registry Created with that button in the middle of the page.
3. Enter the Name (worked example: context7). This is required, and it is what identifies the server in the registry list.
4. Enter a Short Description if you want one. It is optional.
5. Enter the URL of the origin MCP server, the upstream that implements the tools (worked example: https://mcp.context7.com/mcp). This is required. Do not enter the gateway's own MCP endpoint from Step 4.1; the per-server URL clients use is built in Step 4.4.
6. Check the Slug (worked example: context7, auto-filled from the Name). It identifies the server in the registry the same way an integration slug does in Phase 3.
7. Leave Server Type on Streamable HTTP (the worked example keeps it); choose SSE only for a server that requires it.
8. Add Passthrough headers if you need them (the worked example leaves them empty), filling in the Passthrough Headers and Passthrough String pair as necessary and clicking + Add Header for each additional one. The trash icon at the end of a row removes it. These take headers your client sent (tracing identifiers, tenant context) and forward them to the server; they are not credentials.
9. Choose the Authentication mode the origin server requires (worked example: None); the choice is dictated by the server, not by preference:
   • OAuth 2.1 (the default) — for servers that speak OAuth. With dynamic client registration the gateway starts the OAuth exchange on the first tool call, so each user completes their own consent and holds their own token. With a client credentials grant you supply a client ID and secret, the gateway fetches and refreshes tokens itself, and every user shares the same access.
   • Headers — for servers that authenticate with an API key or a static token. The gateway attaches the headers to every request it makes to that server, shared by every user, so scope the token minimally. A credential can instead be stored once on the Integrations page's Secret References tab, backed by HashiCorp Vault, Azure Key Vault, or AWS Secrets Manager, and reused across registrations.
   • None — for servers that require no credential at all.
10. Expand Advanced Settings only if the server requires it (the worked example leaves it collapsed). It holds three JSON editors (OAuth Metadata, External Auth Configuration, Advanced Configuration), all optional and all empty for a straightforward registration; follow the server's own documentation for the keys it expects.
11. Click Next: Choose Workspace to continue to Step 4.3.

The MCP Registry tab before any server exists (step 2):

The completed first stage of the wizard (steps 3 to 10):

Advanced Settings expanded:

The second stage of the wizard, headed Workspace Access, controls which workspaces are allowed to call the server you just described. It mirrors the workspace access model from Step 3.5: the registry entry exists organization-wide, and provisioning is what exposes it to the teams that need it.

1. At the top of the stage, a banner reads Automatically provision this integration for new workspaces; leave the toggle at its right-hand end off unless every future workspace should get this server automatically; that is fine for a public documentation server but not for one reaching sensitive systems. It affects only workspaces created later.
2. Under Total Valid Workspaces, switch on each of your workspaces that should reach this server. Use the Search box to find one by name in a large organization, or Select All and Deselect All to move through the list quickly.
3. Click Create MCP Server to finish the registration.

Your screen should look like this, except that the automatic provisioning toggle stays off for a first registration (the capture shows it on):

Your screen should look like this:

Each registered server has its own URL on the MCP gateway, built from the server's slug:

<mcp-base>/<server-slug>/mcp

The slug is the value from the Slug column of the MCP Registry list, and the copy button beside it copies exactly the string this URL needs. For the worked example registered in Step 4.2, the path is /context7/mcp. When you configure clients in Step 4.5, pointing a client at the bare host will not reach a server.

Authentication

The MCP endpoint is authenticated, and clients authenticate to it with a gateway API key sent as a header on every request:

x-portkey-api-key: <gateway-api-key>

This is the same kind of key as the one created in Step 3.8, and the key determines which servers and tools the caller can reach: it must carry the MCP Invoke permission, granted on the permissions stage of the API key form. A key without that permission fails against the MCP endpoint no matter how correct the rest of the configuration is, so check it before blaming the URL. Both listeners accept the same key in either of two headers:

Use the header shown for each listener. The LLM listener also accepts x-portkey-api-key in place of Authorization: Bearer; the published examples for the Responses API use the two interchangeably against the same endpoint. Prefer Authorization: Bearer there anyway, because that is what OpenAI-compatible SDKs send without extra configuration, and switch to x-portkey-api-key only when the client already uses the Authorization header for another credential, such as a provider key or an end-user token.

Prove the server URL is reachable and protected before configuring a client:

curl -si <mcp-base>/<server-slug>/mcp

Look for HTTP/1.1 401 and a WWW-Authenticate header on the first lines of the output.

curl -s <mcp-base>/.well-known/oauth-authorization-server

Configure your MCP client with the per-server URL from Step 4.4 in place of the origin server's own address, and the gateway API key in the request headers. In Claude Code, the claude mcp add command does both in one line.

1. Run the add command, substituting the placeholders in angle brackets first, since they are not literal values:

   claude mcp add --scope user --transport http <server-name> "<mcp-base>/<server-slug>/mcp" --header "x-portkey-api-key: <gateway-api-key>"

   Copy
   • <server-name> — the label Claude Code shows for this server; use the slug, context7, for the worked example.
   • <mcp-base> and <server-slug> — the values from Steps 4.1 and 4.4.
   • <gateway-api-key> — the User key from Step 3.8 (the same placeholder as Step 3.9); it must carry the Mcp (Invoke) permission.
   --scope user registers the server machine-wide; drop it to register for the current project only. Prefer the command over hand-editing configuration files.
2. Restart the Claude Code session, then run /mcp; the server shows as connected.
3. Ask Claude Code use context7 to look up the kubectl port-forward docs; it lists the tool it is about to call and asks to run it. Approve the tool call.
4. Open AI Security → AI Gateway → Observability → Logs and find the row whose Model column shows the server slug.

{
  "mcpServers": {
    "<server-name>": {
      "type": "http",
      "url": "<mcp-base>/<server-slug>/mcp",
      "headers": {
        "x-portkey-api-key": "<gateway-api-key>"
      }
    }
  }
}

Your screen should look like this, with MCP tool calls interleaved with LLM traffic:

Skip this step unless you need limits that cut across integrations by model, user, or metadata; the Step 3.5 workspace limits stand on their own. The per-workspace budgets and rate limits from Step 3.5 are set inside one integration's wizard. The Policies & Profiles page manages the policy layer above them: budget and rate policies that control spend across models, users, workspaces, or metadata conditions.

1. In the left navigation, select AI Security → AI Gateway → Policies & Profiles. The page opens on the Budget Limits tab, alongside Rate Limits and Configuration tabs (Step 5.2 uses the Configuration tab).
2. On a fresh tenant the tab shows a No Budget Limits empty state. Click + Add Budget Limit. The Create Budget Limit Policy page opens ("Cap spending or token consumption per group with metadata conditions and per-period resets").
3. Provide a Policy Name (for example drod-example-budget) and an optional Description.
4. Under Set Budget Limits, choose the Policy Type (Cost for the worked example; the page caps spending or token consumption), then fill Budget Limit ($), an optional Alert Threshold ($), and the Periodic Reset cadence, including a custom Periodic Reset in Days. For the worked example enter a Budget Limit ($) of 10, an Alert Threshold ($) of 8, and Reset Monthly.
5. Under Conditions, click + Add Condition to scope the policy: each condition pairs a Condition Key with Includes and Excludes value lists, matching the metadata your requests carry (such as the actor and agent tags from Step 3.10). For the worked example add one condition with Condition Key actor and Includes policy-test, a value no real key carries; send the verification request with a throwaway Service key whose Metadata is {"actor": "policy-test"} (Step 3.10, item 1), then revoke that key (Replace a gateway API key, item 5). Only after you have confirmed on your tenant that a policy can be deleted from its row should you scope a policy to agent, which would cap every agent key from Step 3.10.
6. Under Groups, optionally set Group by Key so the cap applies per group value rather than to the whole matched set.
7. Click Create. The policy appears in the Budget Limits list in place of the empty state.
8. Switch to the Rate Limits tab for the request-volume equivalent: rate limit policies control request volume across the same dimensions. Click + Add Rate Limit. The Create Rate Limit Policy page opens ("Throttle requests per time period using metadata conditions and group keys").
9. Fill it the same way as the budget policy: a Policy Name and optional Description, then under Set Rate Limits choose Requests or Tokens, enter the limit, and pick the time window in the unit dropdown (its options read Requests/Minute, Requests/Hour, and Requests/Day). For the worked example enter 60 with Requests/Minute and the same actor / policy-test condition. The Conditions and Groups sections work exactly as in the budget form. Click Create.

▶ See screenshots

Policies & Profiles in the AI Gateway navigation (step 1):

The Budget Limits tab with its empty state and Add Budget Limit highlighted (step 2):

The Create Budget Limit Policy form with its name, limits, conditions, and grouping sections highlighted (steps 3 through 7):

The Rate Limits tab with its empty state and Add Rate Limit highlighted (step 8):

The Create Rate Limit Policy form mirrors the budget form with a Requests or Tokens rate instead of a dollar cap (step 9):

The AI Runtime guardrail is a check inside a gateway configuration. Traffic is scanned when the request carries that configuration, either because the API key it uses has the configuration attached or because the request names it in a header. You need an AIRS API key linked to an AI security profile, the configuration itself, and the attachment.

1. Get an AIRS API key linked to the AI security profile you want applied. Both come from Phase 3 of the AIRS API Intercept guide: Step 3.2 creates the profile, Step 3.3 generates the key. Record the key and the profile name.
2. In the left navigation, select AI Security → AI Gateway → Policies & Profiles, open the Configuration tab, and click + Create configs. On a fresh tenant the tab shows a No Configurations empty state; the Create Configuration page is a JSON editor, pre-filled with an example config setting retry attempts and a cache mode. Saved configs are what the Configuration dropdown on the gateway API key form (Step 3.8) offers; the dropdown read "No configurations available" earlier because none existed yet.
3. Replace the editor's example JSON with the configuration below, substituting your key and profile name from item 1, and an application name of your own choosing (for example claude-code); it appears in the AI Runtime scan logs as Portkey-claude-code. It declares the guardrail twice: as a before-request hook that scans the prompt, and as an after-request hook that scans the model's response. In the after-request hook the plugin sends the model's response text to AIRS, and the four scan_scope values under Check parameters choose among request messages only. The plugin documentation does not say whether scan_scope or strip_scaffolding changes what the after-request check scans, so run the response-side test in the verification below before relying on response scanning. deny: true blocks the request when AIRS returns a block action; async: false makes the gateway wait for the verdict before continuing.

   {
     "before_request_hooks": [
       {
         "type": "guardrail",
         "id": "airs-prompt-scan",
         "credentials": { "AIRS_API_KEY": "<airs-api-key>" },
         "checks": [
           {
             "id": "panw-prisma-airs.intercept",
             "parameters": {
               "profile_name": "<security-profile-name>",
               "app_name": "<application-name>",
               "scan_scope": "last_user_message",
               "strip_scaffolding": true
             }
           }
         ],
         "deny": true,
         "async": false
       }
     ],
     "after_request_hooks": [
       {
         "type": "guardrail",
         "id": "airs-response-scan",
         "credentials": { "AIRS_API_KEY": "<airs-api-key>" },
         "checks": [
           {
             "id": "panw-prisma-airs.intercept",
             "parameters": {
               "profile_name": "<security-profile-name>",
               "app_name": "<application-name>",
               "scan_scope": "last_user_message",
               "strip_scaffolding": true
             }
           }
         ],
         "deny": true,
         "async": false
       }
     ]
   }

   Copy
4. Click Save Configuration. The config appears in the Configuration list with an ID that starts with pc-. Record the ID, because the x-portkey-config header in item 5 takes the ID, not the name. If you cannot find it, attach the config to a key instead (item 5, first option), which needs no ID. Palo Alto Networks documents that a new config reaches the gateway within 30 seconds, so wait at least a minute before testing it.
5. Attach the configuration to the traffic it should govern:
   • On the API key — the enforced path: every request made with that key is scanned and the client cannot opt out. Select this config in the Configuration dropdown when creating a key (Step 3.8, item 2). Palo Alto Networks documents attaching a config to an existing key by editing the key. If the key's row on the Security Keys page offers an edit action, select the config there. Otherwise follow Replace a gateway API key (after Step 3.8), selecting the config on the new key.
   • Per request — the header x-portkey-config: <config-id>, added as \nx-portkey-config: <config-id> to ANTHROPIC_CUSTOM_HEADERS in ~/.claude/settings.json (Step 3.9) for Claude Code, followed by a restart, or to default_headers for the SDKs. This is useful for testing the config before rolling it onto keys, but it is opt-in: any request that omits the header is not scanned, so do not rely on it as a control. By default a config named in the request replaces the key's config for that request. The gateway platform documents a per-key setting that rejects such requests with HTTP 400 when it is turned off. Turn it off on keys whose config is a control, or strip the x-portkey-config header at your ingress.
   The config above names no provider and no targets, so the gateway takes the provider from the x-portkey-provider header. Keep that line in ANTHROPIC_CUSTOM_HEADERS, because removing it reintroduces the 400 from Step 3.9. The benign prompt in the verification below confirms that routing still reaches your integration.

The Configuration tab with its empty state and Create configs highlighted (step 2):

The Create Configuration JSON editor with the pre-filled example config and Save Configuration highlighted (steps 3 and 4):

1. Open AI Security → AI Gateway → Observability (this guide's "AI Gateway dashboard") and confirm traffic events are appearing on the Logs tab, the same page and tab you checked in Step 3.9, item 5. Threat Logs also land in the Strata Logging Service, which the TSG mapping in Step 1.4 enabled.
2. For SIEM or SOAR export, choose one path. Hybrid: the data plane pushes analytics and traces over OTLP to a collector you name with the gateway environment variables in the next item, set under environment.data in values.yaml; see Hybrid chart extras in the Reference section for credential handling. Allow egress from the airs-gw namespace to the collector on TCP 4317 (gRPC) or 4318 (HTTP), and supply the collector's bearer token or mTLS client certificate through the same Secret mechanism as Step 2.5. SaaS: export Threat Logs from Strata Logging Service using its own forwarding configuration.
3. The gateway documents two sets of OTLP variables. Analytics export uses OTEL_PUSH_ENABLED (set to true), OTEL_ENDPOINT (the collector's OTLP URL, for example http://<collector>:4318), and the optional OTEL_EXPORTER_OTLP_HEADERS (comma-separated key=value pairs, which is where a collector token goes). Request traces use four more: EXPERIMENTAL_GEN_AI_OTEL_TRACES_ENABLED (set to true to turn traces on), EXPERIMENTAL_GEN_AI_OTEL_EXPORTER_OTLP_ENDPOINT (the endpoint URL, given without the /v1/traces suffix, which the gateway appends), EXPERIMENTAL_GEN_AI_OTEL_EXPORTER_OTLP_HEADERS (the same key=value header format), and EXPERIMENTAL_GEN_AI_OTEL_RESOURCE_ATTRIBUTES (comma-separated key=value pairs attached as OTLP resource attributes). Treat the EXPERIMENTAL_ prefix as meaningful: those names are documented as an experimental feature and may be renamed in a later release, so pin your chart version if you depend on them.

1. On the Observability Logs tab, click a request row to open its trace detail. The panel shows a Trace ID, the Request Details (model, total cost, request timing, the provider integration, and the API key that made the call), and the full Request and Response context windows with token counts, each viewable as Pretty or raw JSON.
2. Confirm full request and response context is captured for your test traffic.
3. Hybrid only: prompt bodies are also written to the log store you configured in Step 2.5; confirm objects are arriving there (for MinIO: kubectl port-forward svc/minio 9001:9001 and browse the bucket; for a cloud store: list the bucket or container).

Clicking the Step 3.9 test request opens its trace (steps 1 and 2):

Walk the whole chain once before handing the gateway to teams:

1. License — in the Customer Support Portal under Products → Software NGFW Credits, the AI-GW profile row's consumed meter reflects test traffic. Consumption can lag behind traffic; allow time before treating a flat meter as a failure.
2. Gateway — the data plane is active (SaaS) or registered and healthy in SCM (Hybrid). Hybrid: the SaaS Gateway toggle on the Gateway Registration tab reads Disabled if traffic must not leave your environment (Step 3.9 (Hybrid)).
3. Integration — a provisioned workspace sees the provider in its Model Catalog and can invoke an allowed model without holding provider credentials.
4. Controls — if you used Select All in Step 3.6, first disable one model you do not need on the integration's Model Provisioning tab (Step 3.7, item 4). Then re-run the Step 3.9 curl test with the model value changed to that disabled model; the gateway must return an error naming the model. To prove rate limiting without touching the immutable workspace limits from Step 3.5, create a throwaway User key (Step 3.8) with Add Rate Limit set to 1 request per minute, send two requests with it, confirm the second is rejected with a rate-limit error, then revoke that key (Replace a gateway API key, item 5). Do not use Add Budget for this test unless the key is disposable.
5. Logs — the interaction appears as an event log and a prompt log, and each row names the key and the actor tag from Step 3.10. If your tenant has an SLS instance (Step 1.1), Threat Logs reach the Strata Logging Service dashboard; this guide has not confirmed the SCM navigation path or the log filter for viewing them, so ask your SLS administrator where AI Gateway Threat Logs appear and confirm a row for your test traffic. Skip this check if you have no SLS instance.

Every request crosses six checks before the gateway swaps in the provider credential, and each one rejects with its own error. Start a support conversation from the error the caller reported and this diagram points at the gate that produced it. A rejected call is still written to the logs, so a block leaves evidence rather than a gap.

The Controls & Limits section of the gateway API key form (Step 3.8 and Step 3.10) offers five controls, each behind its own toggle and scoped to that single key:

• Add Rate Limit — request-based or token-based, with a limit and time window, mirroring the workspace panel from Step 3.5.
• Add Budget — a cost or token budget with Budget Limit ($), Alert Threshold ($), and a Periodic Reset cadence, including a custom reset in days and a next-reset date. A key-level budget blocks the key's requests until the Periodic Reset you chose, or permanently if you chose no reset, so do not use Add Budget on a key you intend to keep unless you also set a reset. An exhausted budget returns 412 Budget exhausted. Weekly resets land on Sunday at 12 AM UTC and monthly resets on the first calendar day of the month at 12 AM UTC, regardless of when you set the budget, so the first period after you set one is usually shorter than a full week or month. The minimum is $1 or 100 tokens, and a budget applies only to requests made after you set it.
• A budget cannot be edited after it is set — no organisation member can change one. Correcting a budget means duplicating the provider and creating a new one with the value you wanted, so confirm the figure before you save.
• Add Rotation Policy — automatic key rotation with a Rotation Period (or custom days), Next Rotation At date, and a Key Transition Period during which old and new keys overlap (minimum 30 minutes).
• Auto Expire — a Set Expiry Date after which the key stops working entirely.
• Email Notifications — add recipients with New + to be notified about this key's lifecycle events.

Step 5.2 configures the AI Runtime guardrail. The gateway offers these guardrail checks alongside it:

AI Gateway separates logs into two categories with different storage and routing. Event logs are small, structured logs built for real-time SIEM and SOAR ingestion: audit events, authentication events, traffic logs, and metrics and analytics (Step 5.3). Prompt logs are large, text-heavy logs capturing full LLM context windows, routed to observability tooling for performance analysis, cost tracking, and compliance storage (Step 5.4).

The chart offers these optional components beyond the log store and cache store configured in Step 2.5:

• Vector store — enables semantic caching, backed by Milvus. On-premises this pairs with the same bundled MinIO. See VectorStore.md.
• OpenTelemetry — the chart has no dedicated OpenTelemetry values. Set the gateway's OTLP variables under environment.data in values.yaml, the same block that carries the Step 2.5 log store keys: OTEL_PUSH_ENABLED, OTEL_ENDPOINT, and OTEL_EXPORTER_OTLP_HEADERS for analytics, plus the four EXPERIMENTAL_GEN_AI_OTEL_* variables for request traces, all described in Step 5.3. Supply the header value through the same Secret mechanism as Step 2.5, and allow egress from the airs-gw namespace to the collector on TCP 4317 (gRPC) or 4318 (HTTP). See Portkey analytics export for the optional resource-attribute variables. This is the Hybrid path for the event log export in Step 5.3.
• Data service — set dataservice.enabled: true for custom fine-tuning, batches, and data exports. Fine-tuning data storage currently supports S3 only.

The chart ships with replicaCount: 1, which is a starting point rather than a production posture. Palo Alto Networks' resiliency guidance describes three or more gateway pods, and the chart exposes autoscaling (defaulting to a range of 2 to 20 replicas when enabled), pod disruption budgets, and topologySpreadConstraints. Availability comes from spreading pods across failure domains: Availability Zones on a cloud-managed cluster, or your own labeled racks, rooms, or sites on-premises. Confirm the spread with kubectl get pods -n airs-gw -o wide.

Remove what the guide built in reverse order, because keys embedded in clients keep working until revoked and the deployment profile keeps consuming credits until removed:

1. Remove client configuration: delete the env block from ~/.claude/settings.json or .claude/settings.local.json (Step 3.9), delete ~/.config/aigw/key if you created it, remove the export AIGW_API_KEY line from ~/.zshrc or ~/.bashrc and the aigw provider from ~/.codex/config.toml (Client variations), and run claude mcp remove --scope user <server-name> (Step 4.5).
2. Delete gateway API keys: open AI Security → AI Gateway → Security Keys, and on the User and Service tabs click the trash icon at the right end of each key's row.
3. Delete MCP registry entries and LLM integrations: open AI Security → AI Gateway → Integrations, and on the MCP Registry and LLM Integrations tabs click the trash icon at the right end of each row.
4. Delete policies and configs: open AI Security → AI Gateway → Policies & Profiles and remove each entry on the Budget Limits, Rate Limits, and Configuration tabs. Deleting the Step 5.2 config removes the pasted AIRS API key from the control plane; revoke that key in the AIRS API Intercept guide (Step 3.3) if it is not used elsewhere.
5. At each provider, revoke the API key you pasted in Step 3.2 (and the Vertex service account key, Azure client secret, or Bedrock access key from Provider variations); deleting the integration in SCM does not invalidate the credential at the provider.
6. Hybrid: run helm uninstall airs-gw --namespace airs-gw, delete the leftover claims with kubectl delete pvc -n airs-gw --all, delete the namespace with kubectl delete namespace airs-gw, then delete the gateway row from the Total Gateways list on Admin Settings → Gateway Registration.
7. Hybrid, outside the chart: delete the Ingress and its certificate and DNS records from Step 3.7 (Hybrid), remove any NetworkPolicy you added in Step 2.6 if the namespace deletion did not take it, delete the IAM role (and its trust policy), managed identity and federated credential, or Google service account and bucket binding from Step 2.5, and remove the ElastiCache security group inbound rule. Then decide the fate of the log store bucket or container: it holds every prompt and response in clear text, so either delete it or apply a retention policy, and do the same for MinIO's persistent volume if the PVC deletion above did not reclaim it.
8. SaaS: leave the SaaS Gateway toggle on Admin Settings → Gateway Registration Enabled, or switch it off if the tenant should stop accepting gateway traffic.
9. Ask your CSP Super User or Palo Alto Networks account team to remove the deployment profile from the credit pool (Step 1.3) and return its credits.