AI GatewayEnterprise

Overview

Airia's AI Gateway sits between your applications and the foundation models they call. It gives you a single, policy-aware endpoint that adds observability, routing, resilience, budgets, guardrails, and data loss prevention to every AI request — without changing your application beyond the endpoint and key.

You can run multiple gateway configurations, each tailored to a workload with its own providers, routing rules, budgets, and protections. Every client points at the same tenant gateway URL; the API key it presents determines which configuration applies.

To open the workspace, go to Secure → Gateway → AI Gateway.

The Gateway Configurations page

A banner at the top shows Your Gateway Endpoint — the single URL all clients use. Use the copy button whenever you need to point a client at the gateway.

Below the banner, a Gateway Overview strip summarizes activity across all configurations (Total Requests, Success Rate, Avg Response Time) with a time-period dropdown and Refresh.

Each configuration appears as a card. From a card you can:

• copy or reveal its API key, or add another with + API Key;
• toggle the configuration on/off;
• see its configured providers, request count, budget usage, success rate, and response time;
• open the actions menu, or select Configure to edit it.

Select + Add Configuration (top-right) to create a new gateway.

Edit Configuration

Selecting Configure opens Edit Configuration, organized into tabs. Each tab is described below.

General

The General tab ("Basic configurations") sets the identity and providers for the gateway.

• Configuration name — a name for this gateway (required).
• Description — an optional description.
• AI providers — enable the model providers this gateway exposes. Multiple providers can be enabled on one configuration:

Expand an enabled provider to configure it:

Create any credentials you need first under Settings → Credentials, then select Use customer's Key.

Budget

The Budget tab ("Set default gateway budget limits") caps spend for this configuration. Amounts are in US dollars.

• Gateway-level limits — three cards for Daily, Weekly, and Monthly periods. Each shows current spend versus the limit and has a Set Limit button.
• Configure Individual User Budget — set per-user caps that count toward the gateway's overall budget. Users must first be granted access on the User Access tab, then added here with Select Users.
• Budget History — tracks usage and spending over time for this configuration.

For organization-wide limits — and budgets scoped to a whole company, project, or user across the platform — use Spend Management. See Budgets & Spend for how gateway budgets fit alongside the other scopes.

User Access

The User Access tab controls who may use this specific gateway configuration. Switch between the Users and Groups sub-tabs, then select Add Users to grant access — search by name or email, select the checkboxes, and choose Add Selected. Granted entries show when they were added; each row's actions menu lets you Manage API keys or remove the entry.

Rules

The Rules tab ("Configure rules to transform, route, and control traffic through the gateway") is a priority-ordered engine that intercepts and modifies requests before they reach a provider. Select + Add Rule to create one. Rules are evaluated top-to-bottom and can be reordered by dragging.

Each rule has three parts:

For evaluation order, every condition and action type, and worked examples, see Composing Gateway Rules.

Resilience

The Resilience tab defines how traffic is distributed across multiple targets, with automatic failover and circuit-breaker behavior. If none exist yet, the tab shows No Resilience Rules; select Add Resilience Rule to create one.

Rule basics:

When you choose Apply to specific conditions, add conditions using the same Rule Type options as the Rules tab (Provider, Header, Model Name, Endpoint), each with a NOT (Invert) toggle.

Routing targets hold the actions performed when a request matches — and are executed in order. For each target:

• HTTP Status Codes the target reacts to;
• a Weight (its share of load-balanced traffic, e.g. 50);
• Circuit Breaker Settings — Use rule's default or an override for this target;
• one or more Actions (the same action types as the Rules tab — most commonly Change Provider).

Use Duplicate target and + Add target to build the chain.

Circuit breaker. Enable Default circuit breaker on a target to override the rule defaults and tune:

Model identifiers on failover targets

When a resilience rule fails over to a backup target, the target only changes what you tell it to change. If a target has no Change Model Name action, it reuses the model identifier from the original request and sends that identifier to the target's provider.

For most identifiers this is exactly what you want. Plain on-demand model IDs and cross-region inference profile IDs (for example us.amazon.nova-lite-v1:0) are not tied to a single AWS Region or account, so a backup target inherits them and resolves with no extra configuration.

Full AWS Bedrock inference-profile ARNs are the exception. An ARN is scoped to the exact AWS account and Region it was created in, so a backup target only resolves an inherited ARN if that target's AWS Bedrock provider is signed for the same account and Region:

Guardrails

The Guardrails tab ("Gateway Guardrails") applies runtime policies — DLP, Responsible AI, and Security filters — to the traffic flowing through this gateway. It lists Applied Guardrails and Available Guardrails; apply an existing one or select + Create New Guardrail to build a new one. Guardrails scoped to all gateway configurations apply everywhere; otherwise they apply only to the configurations you select.

Guardrails work on passthrough traffic, including external apps routed through the gateway. A Block action stops the request and returns an error; an Audit action lets it through and logs the violation for review. For filter details, see Runtime Security.

Agent Constraints

The Agent Constraints tab applies tool-usage policies to gateway traffic — blocking or auditing tool calls by condition. It lists Applied and Available constraints; apply one or select + Create New Agent Constraint. Each constraint shows an action badge (Block / Audit) and a scope badge.

Analytics & Monitoring

The Analytics & Monitoring tab shows this configuration's activity, with a time-period dropdown, Refresh, and Export:

• Summary cards — Total Requests, Success Rate, Avg Response Time.
• Charts — Requests Over Time, Top Models by Usage, and Top Providers by Usage.

Use it to confirm traffic is actually flowing through the gateway and to spot model/provider usage trends.

Connect your own cloud-hosted models (Azure AI Foundry & AWS Bedrock)

Route gateway traffic to models hosted in your own Azure AI Foundry workspace or AWS Bedrock account, so inference runs in your cloud region under your credentials while still passing through Airia's guardrails, DLP, and observability.

Both are configured from the General tab (AI providers) of a gateway configuration: enable the provider card and attach a connection.

Azure AI Foundry

Before you start (in Azure): create the service principal Airia will use and give it access to your Foundry workspace. Microsoft's own docs cover the current steps:

• Register a Microsoft Entra app and create a service principal — this is where you get the Client ID, Tenant ID, and a Client Secret.
• Role-based access control for Microsoft Foundry — assign that service principal a role (for example, Foundry User) on your Foundry resource so it can call your deployments.

1. In the gateway configuration's General tab, toggle the Azure AI Foundry provider on.
2. Under Azure AI Foundry Connection, choose + Create New Connection.
3. Complete the Create Azure AI Foundry Connection form - Name, Subscription ID, Client ID, Client Secret, Azure Tenant ID, and Location - using an Entra ID service principal that has access to your Foundry workspace. Select Create.
4. Pick the new connection. Airia reads the workspace and lists its deployed models under Model Selection - check the ones you want to expose.
5. Choose an Authentication Method for how the gateway calls Foundry:
   • API Key - a static key from the Azure resource, or
   • Microsoft Entra ID - Azure AD OAuth client credentials.
6. Select Generate Rules. Airia adds a routing rule per model (visible on the Rules tab) that points requests at your Foundry deployment. Reference each model by its deployment name.
7. Save the configuration.

AWS Bedrock

Before you start (in AWS): create an IAM identity with Bedrock access and a long-term access key, and make sure the models you want are enabled. AWS's own docs cover the current steps:

• Identity and access management for Amazon Bedrock — give the IAM user/role permission to invoke Bedrock (the AmazonBedrockFullAccess managed policy is the simplest option).
• Manage access keys for IAM users — create the long-term access key (Access Key ID + Secret Access Key). Temporary IAM Identity Center (SSO) credentials are not supported.
• Request access to models — enable the foundation models you plan to use; Anthropic (Claude) models require the one-time use-case form described there.

1. In the General tab, toggle the AWS Bedrock provider on.
2. Under AWS Bedrock Connection, choose + Create New Connection.
3. Complete the Create AWS Bedrock Connection form:
   • Connection Name - a label (for example, Bedrock US East).
   • AWS Region - the region where your Bedrock models are enabled.
   • Access Key ID and Secret Access Key - a long-term IAM access key whose user or role can invoke Bedrock (the AmazonBedrockFullAccess policy covers this). Temporary credentials from AWS IAM Identity Center (SSO) are not supported.
4. Select Create, choose the connection, and save the configuration. The Bedrock provider proxies the /model/{modelName}/converse and /model/{modelName}/converse-stream endpoints, so regional routing follows the connection you selected.

Bedrock enables most foundation models automatically on first use. Anthropic (Claude) models on Bedrock require a one-time use-case form in the AWS console before they can be invoked; Amazon Nova and Titan models are available immediately.

Route to other OpenAI-compatible providers (OpenRouter, Perplexity, and more)

The gateway's provider list is fixed, but you can route to any provider that speaks the OpenAI API format — even if it doesn't have its own card — by reusing the OpenAI provider with a custom base URL. This covers aggregators like OpenRouter, search-grounded providers like Perplexity, fast-inference hosts like Groq, and your own self-hosted OpenAI-compatible servers.

1. In the gateway configuration's General tab, toggle the OpenAI provider on.
2. Set Base URL to the provider's OpenAI-compatible endpoint (see the table below). Match the path exactly — a missing or extra /v1 causes the provider to reject the request.
3. Under AI Service Authentication, choose Use Customer's OpenAI Key and select (or create in Settings → Credentials) an OpenAI-type credential that holds the provider's API key.
4. (Optional) Use Allowed Models to restrict which models callers may request.
5. Save the configuration. Requests routed through this gateway now reach the provider you specified, with Airia's guardrails, DLP, and observability applied.

Common base URLs:

Manage API keys

Every configuration starts with a standard API key. Choose Manage API Keys on a card (or + API Key) to:

• Create New Key — issue additional keys;
• enable or disable individual keys with the toggle;
• delete a key;
• reveal or copy a key's value.

Use separate keys to partition environments, rotate credentials, or give individual users and external agents their own access. Each key shows whether it is Enabled, who it belongs to, and when it was last updated.

Using the gateway from your app

Calling models by provider

The gateway is one endpoint, but the path you call selects the provider's API format, and the model field selects the model. The request body is whatever that provider's own API already expects — where the model runs (a foundation provider, your cloud account, or a self-hosted server) doesn't change the body you send, only the response shape.

Anthropic (Claude models) — add the anthropic-version header:

curl -X POST "https://<gateway-domain>/anthropic/v1/messages" \
  -H "x-api-key: <AIRIA_GATEWAY_API_KEY>" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-haiku-4-5-20251001",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

Google Gemini — the model goes in the path, and the body uses contents:

curl -X POST "https://<gateway-domain>/v1beta/models/gemini-2.5-flash:generateContent" \
  -H "x-api-key: <AIRIA_GATEWAY_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{"parts": [{"text": "Hello!"}]}]
  }'

AWS Bedrock — send an OpenAI-style body; the response comes back in Bedrock's Converse format:

curl -X POST "https://<gateway-domain>/bedrock/v1/chat/completions" \
  -H "x-api-key: <AIRIA_GATEWAY_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "us.amazon.nova-lite-v1:0",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

Ollama (self-hosted) — call the native Ollama path against your configured server:

curl -X POST "https://<gateway-domain>/ollama/api/chat" \
  -H "x-api-key: <AIRIA_GATEWAY_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.2",
    "messages": [{"role": "user", "content": "Hello!"}],
    "stream": false
  }'