AI Gateway

This is section 04, AI Gateway, on the Connections page. A gateway is the one place Reagent can read prompts and tool calls inline and enforce before a request leaves. Hooks and client-side settings can be stripped; a network chokepoint cannot. Reagent either provides the gateway (the built-in Zaun Agent Gateway, managed on Enforce) or reads and governs one you already run (the six tiles in this section).

Two of the six tiles can light up a discovery signal on Discover: AWS AgentCore Gateway and Google Agent Gateway light MCP Servers in Cloud Applications through template packs. The Azure AI Foundry Gateway tile rides the base Azure pack for AI Prompts & Model Routing/Use, which your Azure connection already lights. LiteLLM, agentgateway, Kong, and the Zaun gateway feed Enforce and Lake, not Discover.

The six tiles need the manage integrations permission (Administrator, MSSP Admin, or a custom role with it). The Zaun Agent Gateway is not a tile. It is built in and always available, and turning it on for an environment needs the manage agent enforcement permission (Administrator, MSSP Administrator, Power User, or a custom role with it).

Zaun Agent Gateway

Connector: zaun-gateway (the Athena query surface Monitor uses to read gateway_events from Lake; the Zaun Gateway Wire Events pipeline is what writes them) · Auth: none; Zaun hosts the listener · Requires: any plan

Zaun's built-in agent gateway sits in front of your agents' MCP tool calls and their LLM traffic. It enforces at the wire: guardrails, MCP server allowlisting, self-service temporary exceptions, session freeze, and cost and rate budgets, without owning your model provider relationship. The gateway is built in and always available; there is nothing to connect and nothing to enable from the Connections page. You turn it on per environment from Enforce → Gateways → Zaun, which provisions a listener for that environment. Targets, access rules, and guardrail policy are configured on the same page.

Lights up: no discovery signal on its own. The gateway feeds Enforce and Lake, not Discover. Once the Zaun Gateway Wire Events pipeline pack is installed, denied tool calls and guardrail findings land in the gateway_events table in Lake. Monitor's Gateway Enforcement pack opens investigations on denied tool calls; LLM guardrail findings appear directly on Monitor → Alerts.

What it proxies

Before you start

• You need the manage agent enforcement permission (Administrator, MSSP Administrator, Power User, or a custom role with it).
• Select an environment first. The gateway is provisioned per environment, and its policy is scoped to that environment.
• To search gateway events in Lake, the environment's data lake must be active. Activate it under Settings → Data Lake if you have not. Then search gateway events on Lake in the sidebar.
• If an AWS Managed WAF fronts the gateway hosts, read the WAF note at the end of this section before you route agents.

Setup

1. In Reagent, select the environment, then open Enforce → Gateways → Zaun (/reagent/enforce/gateways/zaun). The Setup section tracks five readiness stages (table below). Each stage completes on evidence, not on a click.
2. Stage 1, turn on the gateway: turn the gateway on, set the listener hostname, then run the wire check. The stage completes when the gateway is enabled, the hostname is set, and the last wire check is green.
3. Stage 2, apply recommended config: apply the baseline catalog. The stage completes when every baseline catalog item is present.
4. Stage 3, route your agents: pin Claude Code and Codex CLI to the gateway (see Routing agents below). The stage completes when a real session or tool event lands.
5. Stage 4, optional: connect Okta for group-based access rules and turn on key custody.
6. Configure MCP tool targets under Traffic & routing, access rules under Guardrails → Tool access, and guardrail policy under Guardrails, all on the same page.
7. To keep gateway events in Lake and drive Monitor, install the Zaun Gateway Wire Events data pipeline pack and the Gateway Enforcement detection pack from Content Packs. Map any placeholder credential for the zaun-gateway connection at install; it is never used for auth.

Setup readiness

Stages 1 to 3 are core. Once they are complete, the setup rail collapses to a "Gateway: N/5 healthy" strip.

Controls enforced inline

Routing agents

• Claude Code. The managed-settings channel pins ANTHROPIC_BASE_URL to the environment's gateway. In BYO passthrough mode, managed sessions send their existing Anthropic credential and the gateway forwards it upstream.
• Codex CLI. OpenAI API traffic routes through a managed openai_base_url pin.
• Key custody (optional). Moves the fleet onto the custody listener. The gateway attaches its own upstream credential (your org's Anthropic key, AWS SigV4, or Vertex) and the device never holds one. Custody tokens live 15 minutes; a helper refreshes them every 10.

Routing steps for each agent are on Coding agents.

Identity

• Every caller presents a short-lived, environment-scoped ES256 JWT minted by Zaun and signed by AWS KMS. A token for the wrong environment sees zero tools.
• Okta groups sync into access rules every 15 minutes. Remove a person from the group and their tool access is revoked on the next sync.

What Reagent reads

• The gateway's own wire feed: OTLP trace export plus the guardrail webhook. This is inline capture; client-side hooks cannot strip it.
• Denied tool calls and LLM guardrail findings, written to the gateway_events table in Lake by the Zaun Gateway Wire Events pipeline. Each event carries the plane (mcp or llm), the action (tool_call or guardrail_finding), whether it was denied, the verdict (pass, mask, or reject), method, target (the MCP server), tool, user_sub, session_id, severity, a findings summary with no raw content, a secret-redacted excerpt, error, status, duration_ms, trace_id, and span_id.

---

LiteLLM

Connector: litellm · Auth: Bearer token (LiteLLM Admin API) · Requires: any plan

LiteLLM is an open-source LLM proxy and router that fronts many model providers (OpenAI, Anthropic, Bedrock, Vertex, Azure OpenAI, and self-hosted models) behind a single OpenAI-compatible API. Reagent connects to the proxy's Admin API and reads its governance posture: guardrail definitions and evaluation logs, the MCP server registry and tool inventory reachable through LiteLLM's MCP gateway, model-routing configuration, spend logs, the administrative audit trail, and the virtual-key and team entitlement inventory. Reagent can also push changes back: block or unblock a key, or remove an MCP server.

Lights up: no discovery signal on its own. The connector reads LiteLLM's guardrails, MCP registry, routing config, spend logs, audit trail, and key and team inventory into Enforce and Lake, not Discover or Optimize. Key block/unblock and MCP server removal are available as response actions.

Before you start

• You need the manage integrations permission in Reagent.
• You need access to the LiteLLM Admin UI to create a virtual key.
• The proxy's base URL must be reachable from Reagent.

Setup

1. In the LiteLLM Admin UI, open Virtual Keys.
2. Generate a key through /key/generate with the proxy_admin role, or a role scoped to the permissions this connector needs. Do not use the proxy's root master key.
3. Copy the key. It starts with sk-.
4. In Reagent, open Connections and click LiteLLM.
5. Enter the Proxy URL and the Admin Key, then save.

Permissions

What Reagent reads

• Guardrail definitions and evaluation logs: PII, prompt-injection, and content-safety policies applied before and after each call.
• The federated MCP server registry and the tool inventory reachable through LiteLLM's MCP gateway.
• Model-routing configuration: which upstream provider and model each alias resolves to, rate limits, and fallback chains.
• Per-request and aggregated spend logs for cost attribution and budget reconciliation.
• The administrative audit trail of every config change made through the Admin API.
• The virtual-key and team entitlement inventory.

---

agentgateway

Connector: agentgateway · Auth: Kubernetes ServiceAccount bearer token (kube-apiserver REST) · Requires: any plan

agentgateway is an open-source, Linux Foundation-hosted agentic proxy built for LLM, MCP, and A2A traffic. It runs on Kubernetes and is managed as ordinary Gateway API and agentgateway.dev custom resources; there is no dedicated admin API. Reagent connects directly to the cluster's Kubernetes API server and reads the gateway's governance posture: AgentgatewayPolicy resources, AgentgatewayBackend resources, and the Gateway API topology underneath them. Reagent can also delete a policy, route, or backend to cut off a compromised route, tool target, or misbehaving policy.

Lights up: no discovery signal on its own. The connector reads AgentgatewayPolicy and AgentgatewayBackend resources and the Gateway API topology into Enforce and Lake, not Discover. Policy, route, and backend delete are available as response actions.

Before you start

• You need the manage integrations permission in Reagent.
• You need kubectl access to the cluster running agentgateway, with rights to create the RBAC objects in the manifest.
• The cluster's kube-apiserver endpoint must be reachable from Reagent.
• The kube-apiserver must present a publicly chained certificate; a private-CA cluster will fail the connection. Most managed Kubernetes API servers present a publicly chained certificate.

Setup

1. In Reagent, open Connections and click agentgateway.

2. Apply the RBAC manifest below to the cluster running agentgateway (kubectl apply -f -). It is the same manifest the tile shows. It scopes access to the agentgateway.dev and Gateway API resources only, nothing else in the cluster. The ServiceAccount lives in the default namespace; change namespace in all three places if you move it.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: zaun-agentgateway-reader
   rules:
     - apiGroups: ["agentgateway.dev"]
       resources: ["agentgatewaypolicies", "agentgatewaybackends"]
       verbs: ["get", "list"]
       # Add "delete" here (and to the httproutes rule below) only if you
       # want Zaun to be able to run the containment operations
       # (policies.delete / backends.delete / httproutes.delete).
     - apiGroups: ["gateway.networking.k8s.io"]
       resources: ["gateways", "httproutes", "gatewayclasses"]
       verbs: ["get", "list"]
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: zaun-agentgateway-reader
     namespace: default
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: zaun-agentgateway-reader
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: zaun-agentgateway-reader
   subjects:
     - kind: ServiceAccount
       name: zaun-agentgateway-reader
       namespace: default

3. Mint a long-lived token for the service account the manifest creates. The token lasts one year (--duration 8760h). Change --namespace if you moved the ServiceAccount.

   kubectl create token zaun-agentgateway-reader \
     --namespace default \
     --duration 8760h

4. Find the kube-apiserver endpoint with kubectl cluster-info.

5. Paste the Kubernetes API Server URL and the ServiceAccount Token into the form and save.

Permissions

The manifest grants the service account access to two API groups and nothing else. No broader cluster access is required.

What Reagent reads

• AgentgatewayPolicy resources: guardrails, prompt enrichment, JWT and authz, external-authz hooks, and rate limits, attached to routes and backends through targetRefs.
• AgentgatewayBackend resources: the model-routing and MCP/A2A target inventory. Which LLM providers, MCP tool servers, and A2A agent endpoints the gateway is configured to reach.
• The underlying Gateway API topology: Gateway listeners, HTTPRoutes, and GatewayClasses.

---

Kong AI Gateway

Connector: kong-ai-gateway · Auth: Bearer token (Konnect API) · Requires: any plan

Kong AI Gateway extends Kong's API gateway (the Konnect cloud control plane, or self-managed Kong Gateway) with AI-specific plugins for guardrails, MCP and A2A traffic governance, model routing, and cost and token metering. Reagent connects to the Konnect Control Planes and Control Plane Config APIs and reads that governance posture: the control-plane, service, and route topology traffic flows through, the full plugin chain on any route, the consumer entitlement inventory, near-real-time per-request analytics, and the administrative audit trail. Reagent can also disable or enable a plugin, or delete a consumer.

Lights up: no discovery signal on its own. The connector reads Konnect control-plane config, the plugin chain, consumer inventory, per-request analytics, and the audit trail into Enforce and Lake, not Discover or Optimize. Plugin disable/enable and consumer delete are available as response actions.

Before you start

• You need the manage integrations permission in Reagent.
• You need rights in Konnect to create a System Account under Organization → System Accounts.
• Know the Konnect region your org was created in. It is visible in the Konnect UI URL.

Setup

1. In Konnect, go to Organization → System Accounts and create a System Account for Reagent.
2. Generate an access token for it. Scope it to the control plane or control planes you want Reagent to govern.
3. In Reagent, open Connections and click Kong AI Gateway.
4. Choose your Konnect Region. Nothing is preselected, and the form will not save without one. It must match the region your Konnect org was created in.
5. Paste the Access Token and save.

"US (default)" labels Kong's default API host. It is not a preselected value.

Permissions

Reagent reads control-plane config, analytics, and the audit trail for the scoped control planes. It needs write on plugins and consumers only for response actions.

What Reagent reads

• The control-plane, service, and route topology that AI traffic flows through.
• The full plugin chain applied to any route:

• The consumer entitlement inventory.
• Near-real-time per-request analytics for cost and usage attribution.
• The administrative audit trail.

---

AWS AgentCore Gateway

Connector: aws-aws (shared with AWS) · Auth: the IAM role your AWS connection already assumes · Requires: any plan

This tile uses the same credential as AWS. Connect AWS first and this tile activates on its own once the extra permission is granted.

Reagent governs Amazon Bedrock AgentCore Gateway: the gateway and MCP target inventory, the Cedar policy engine with its guardrail and MCP-tool allow/deny rules, workload identities, and Bedrock Guardrails configuration.

Lights up: MCP Servers in Cloud Applications (AgentCore gateways, template pack), Platform Agent Registries (workload identities, template pack).

Before you start

• Connect AWS. See Cloud.
• You need IAM rights to edit the policy attached to the role Reagent assumes, or to the IAM user or execution role it uses.

Setup

1. In Reagent, open Connections and click AWS AgentCore Gateway.

2. Copy the Additional IAM policy statement shown on the tile. It is the fixed, read-only statement below.

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "bedrock-agentcore:GetGateway",
           "bedrock-agentcore:ListGateways",
           "bedrock-agentcore:GetGatewayTarget",
           "bedrock-agentcore:ListGatewayTargets",
           "bedrock-agentcore:GetPolicyEngine",
           "bedrock-agentcore:ListPolicyEngines",
           "bedrock-agentcore:GetPolicy",
           "bedrock-agentcore:ListPolicies",
           "bedrock-agentcore:ListWorkloadIdentities",
           "bedrock:ListGuardrails",
           "bedrock:GetGuardrail"
         ],
         "Resource": "*"
       }
     ]
   }

3. In IAM, attach that statement to the policy on the role your AWS connection assumes, or to a policy on the IAM user or execution role it uses.

4. There is nothing to save in Reagent. AgentCore Gateway data starts flowing on the next scheduled pull.

Permissions

All eleven actions are read-only and are granted on Resource: "*".

What Reagent reads

• Gateway and MCP target inventory.
• The Cedar policy engine: guardrail and MCP-tool allow/deny rules.
• Workload identities.
• Bedrock Guardrails configuration.

---

Azure AI Foundry Gateway

Connector: azure-monitor (shared with Azure) · Auth: the app registration your Azure connection already uses · Requires: any plan

This tile uses the same credential as Azure. Connect Azure first and this tile activates on its own once the extra permission is granted.

Reagent governs the Azure AI Foundry gateway surface: model deployments, Responsible AI content-filter guardrail policies, and API Management LLM-policy configuration. Guardrail push needs write access, so the role is Contributor, not Reader.

Lights up: AI Prompts & Model Routing/Use, through the base Azure pack your Azure connection already lights.

Before you start

• Connect Azure. See Cloud.
• You need rights to add a role assignment at the subscription or resource group scope that covers your Foundry resources.

Setup

1. In Reagent, open Connections and click Azure AI Foundry Gateway.

2. Grant Cognitive Services Contributor to the existing app registration at the subscription or resource group scope that covers your Foundry resources. The tile shows this Azure CLI command. Substitute your app registration's client id and the subscription (or resource group) scope; nothing is filled in for you.

   az role assignment create \
     --assignee "<your-app-registration-client-id>" \
     --role "Cognitive Services Contributor" \
     --scope "/subscriptions/<subscription-id>"

3. Prefer the portal? Subscription → Access control (IAM) → Add role assignment → Cognitive Services Contributor → assign to your existing app registration.

4. There is nothing to save in Reagent. Data starts flowing on the next scheduled pull.

Permissions

What Reagent reads

• Model deployments.
• Responsible AI content-filter guardrail policies.
• API Management LLM-policy configuration.

---

Google Agent Gateway

Connector: gcp-security (shared with Google Cloud) · Auth: the service account your GCP connection already uses · Requires: any plan

This tile uses the same credential as GCP. Connect GCP first and this tile activates on its own once the extra roles are granted.

Reagent governs Google's Agent Gateway (Gemini Enterprise Agent Platform): the gateway inventory and its governed ingress and egress paths, the IAP/IAM authorization extensions and whether each is enforcing or in dry-run, and the authorization policies gating agentic MCP and A2A traffic.

Lights up: MCP Servers in Cloud Applications (template pack). Creating a DENY authorization policy on a gateway is available as a response action once the optional admin role is granted.

Before you start

• Connect GCP. See Cloud.
• You need rights to add IAM policy bindings on the projects that host the gateways.

Setup

1. In Reagent, open Connections and click Google Agent Gateway.

2. Grant two read roles to the existing service account: roles/networkservices.serviceViewer and roles/networksecurity.viewer. The tile shows these gcloud projects add-iam-policy-binding commands. Substitute the project id and the existing service account email; nothing is filled in for you.

   gcloud projects add-iam-policy-binding <project-id> \
     --member="serviceAccount:<your-existing-service-account-email>" \
     --role="roles/networkservices.serviceViewer"
   
   gcloud projects add-iam-policy-binding <project-id> \
     --member="serviceAccount:<your-existing-service-account-email>" \
     --role="roles/networksecurity.viewer"

3. Optional. To enable the containment response action, also grant roles/networksecurity.admin.

4. There is nothing to save in Reagent. Data starts flowing on the next scheduled pull.

Permissions

What Reagent reads

• Gateway inventory and governed ingress and egress paths.
• IAP/IAM authorization extensions, with enforce versus dry-run posture.
• Authorization policies gating agentic MCP and A2A traffic.