Enforcing Saved-Only Resources

Hybrid enterprise customers require Gateway version 2.11.0 or later to enforce saved-only mode. On earlier versions the setting has no effect and inline configuration is not blocked.

Overview

The Prisma AIRS AI Gateway lets administrators define saved resources (providers, integrations, and configs) that callers reference by slug. Saved-only mode (the Block Inline Configs data-plane security setting) enforces that callers can only use these admin-curated resources. When the setting is enabled, the Gateway inspects every inference request and rejects any attempt to select a provider, endpoint, or config inline. Callers can no longer bring their own provider name, base URL, or ad-hoc config object in the request. Instead, they must reference a saved entity created and governed by an administrator. This keeps every request on resources your team has set up, so the governance, allowlists, budget controls, and audit attribution attached to those resources apply consistently, without relying on configuration supplied at request time.

This setting sits alongside the other security settings you manage for API keys, providers, and workspaces. It is available on both SaaS and self-hosted deployments.

How It Works

Saved-only mode is a data-plane control: it is enforced by the AI Gateway on every request, independently of which API key or workspace the request belongs to. When a request arrives, the Gateway resolves whether saved-only mode is active for the caller’s organisation (and workspace). If it is, the Gateway runs a single check at the very start of request processing, before the request is forwarded to any provider:

The request is scanned for any signal that selects a provider, endpoint, or config inline (rather than by slug).
If such a signal is found, the request is rejected immediately with an HTTP 400 and a specific, machine-readable error code identifying exactly what was blocked.
If the request only references saved entities (a config slug, a saved provider, a saved model), it proceeds normally.

Because the check runs at a single point before routing, blocked requests never reach an upstream provider, and every rejection is emitted from one consistent place, making the errors easy to detect, log, and alert on.

Default Behavior and Rollout

How this setting is initialized depends on when your organisation was created:

Organisations created on or after June 19, 2026 have saved-only mode enabled (blocked) by default. Inline provider configuration is rejected out of the box, and administrators can turn it off if they want to allow inline configuration.
Organisations created before June 19, 2026 have saved-only mode disabled by default to preserve backward compatibility. Existing traffic is unaffected until an administrator turns it on.

New workspaces inherit their organisation’s setting at the time of creation.

Existing organisations can adopt saved-only mode at any time by enabling it from the Admin Settings panel (see below). No code changes are required on the caller side as long as requests already reference saved resources.

Enabling Saved-Only Mode

From the Dashboard (SaaS and self-hosted)

Administrators can enable the setting per organisation:

Navigate to Admin Settings in Strata Cloud Manager.
Open the Security tab.
Locate the Data Plane Security Settings section.
Toggle on Block Inline Configs.

The change applies to all subsequent requests for the organisation. Existing workspaces are kept in sync with the organisation setting.

Via Environment Variable (self-hosted only)

Self-hosted deployments can additionally enforce saved-only mode across the entire Gateway, regardless of the per-organisation setting:

# Force saved-only mode on every request through this Gateway
BLOCK_INLINE_CONFIG=true

The organisation setting and the Gateway environment variable combine to make policy stricter: if either one enables saved-only mode, it is enforced. Neither can loosen the other. This lets platform teams set a baseline at the infrastructure layer that applies across organisations.

The environment variable applies to self-hosted Gateways only and is ignored on the AI Gateway’s managed SaaS.

What Gets Blocked

When saved-only mode is enabled, the following inline inputs are rejected. Each one returns an HTTP 400 with its own error code so you can pinpoint exactly what was blocked.

Blocked input	What the caller tried to do	Error code
Inline config JSON	Passed a raw config object instead of referencing a saved config by its `pc-...` slug	`inline_config_blocked`
Raw provider name	Named a provider directly (e.g. `openai`) instead of a saved provider slug (`@my-provider`)	`inline_provider_blocked`
Inline custom host	Supplied a custom base URL for the upstream provider at request time	`inline_custom_host_blocked`
Inline provider URL	Overrode a provider-specific endpoint at request time (e.g. a Hugging Face base URL, Azure Foundry URL, or Databricks workspace)	`inline_provider_url_blocked`
Inline forward headers	Asked the Gateway to forward arbitrary request headers to the upstream provider	`inline_forward_headers_blocked`

A few notes on why each is included:

Inline custom host and inline provider URL are blocked because they point the Gateway at an endpoint defined at request time rather than the one on the curated provider.
Inline forward headers are blocked because forwarded headers are layered on top of a saved provider’s authentication headers downstream, so an inline list could override the curated credentials. Forwarding is still allowed when an administrator has configured it on the saved provider itself.

What Stays Allowed

Saved-only mode is designed to be transparent to callers that already reference saved resources. The following continue to work:

Saved configs referenced by slug, e.g. x-portkey-config: pc-...
Saved providers / integrations referenced by slug, e.g. x-portkey-provider: @my-provider
Saved model references in the request body, e.g. "model": "@my-provider/model-name"
Forward headers configured by an administrator on a saved provider (as opposed to passed inline on the request)
Credentials passed directly via the Authorization header (credentials alone cannot select a provider)

Error Responses

When a request is blocked, the Gateway returns an HTTP 400 with a structured body. The error.code field identifies the violation, and error.field names the specific input that triggered it.

{
  "status": "failure",
  "error": {
    "code": "inline_provider_blocked",
    "message": "Inline provider names are not allowed when saved-only mode is enabled. Use a saved integration via '@slug' instead.",
    "field": "x-portkey-provider"
  },
  "message": "Inline provider names are not allowed when saved-only mode is enabled. Use a saved integration via '@slug' instead."
}

Each error code maps to one blocked input:

Error code	Meaning	How to fix
`inline_config_blocked`	A raw config object was passed inline	Save the config and reference it by its `pc-...` slug
`inline_provider_blocked`	A provider was named directly	Reference a saved provider via `@slug`
`inline_custom_host_blocked`	A custom host was supplied inline	Configure the custom host on a saved provider
`inline_provider_url_blocked`	A provider-specific URL was supplied inline	Configure the endpoint on a saved provider
`inline_forward_headers_blocked`	Header forwarding was requested inline	Configure `forward_headers` on a saved provider

The Gateway checks for violations in order and returns the first one it finds, so a request with multiple inline inputs surfaces one error code at a time.

Use Cases

Centralized Provider Governance

Saved-only mode keeps every request on admin-curated resources, so the budget limits, guardrails, and model allowlists attached to your saved providers and configs consistently apply across all callers.

Shared and Multi-Tenant Gateways

When many teams or applications share a Gateway, saved-only mode keeps each request scoped to the resources an administrator has set up, rather than endpoints or headers supplied at request time.

Clear Audit Attribution

Because every request references a named, saved resource, logs and analytics attribute usage to known providers and configs rather than to inline payloads.

Enforce Default Configs

Attach default configs to API keys for org-wide governance.

Configs

Save and reference Gateway configs by slug.

Model Catalog

Create saved providers and integrations.

Gateway Headers

Full reference for the x-portkey-* request headers.

Introduction

Product

Enforcing Saved-Only Resources

Overview

How It Works

Default Behavior and Rollout

Enabling Saved-Only Mode

From the Dashboard (SaaS and self-hosted)

Via Environment Variable (self-hosted only)

What Gets Blocked

What Stays Allowed

Error Responses

Use Cases

Centralized Provider Governance

Shared and Multi-Tenant Gateways

Clear Audit Attribution

Enforce Default Configs

Configs

Model Catalog

Gateway Headers

​Overview

​How It Works

​Default Behavior and Rollout

​Enabling Saved-Only Mode

​From the Dashboard (SaaS and self-hosted)

​Via Environment Variable (self-hosted only)

​What Gets Blocked

​What Stays Allowed

​Error Responses

​Use Cases

​Centralized Provider Governance

​Shared and Multi-Tenant Gateways

​Clear Audit Attribution

​Related

Enforce Default Configs

Configs

Model Catalog

Gateway Headers

Overview

How It Works

Default Behavior and Rollout

Enabling Saved-Only Mode

From the Dashboard (SaaS and self-hosted)

Via Environment Variable (self-hosted only)

What Gets Blocked

What Stays Allowed

Error Responses

Use Cases

Centralized Provider Governance

Shared and Multi-Tenant Gateways

Clear Audit Attribution

Related