Sentinel architecture: control plane and gateways

SUPERWISE® Sentinel has two parts: a control plane in the SUPERWISE cloud, where you manage guardrails and read telemetry, and Sentinel gateways that run on your machine or in your own network, where every AI request is inspected. Prompts go from the gateway straight to the model provider; only operational metadata reaches the control plane.

The diagram shows:

Your applications (Application A to D) run inside your network, here a customer VPC.
Sentinel gateways (Sentinel Node A and B) run in the same network. Each application sends its AI requests to a gateway, and the gateway intercepts and checks them.
The model providers: each gateway forwards the checked request to the OpenAI API, the Anthropic API, the Gemini API, or a custom provider.
The SUPERWISE control plane in the SaaS cloud: each gateway sends it telemetry and receives its configuration. The control plane manages your Sentinels and provides operational and financial (token usage) reports.

The two planes

Control plane (SaaS cloud)

The control plane is part of the SUPERWISE Agentic Management Platform (AMP), which SUPERWISE hosts as a SaaS service. It acts as the central orchestrator and is responsible for:

Managing your global Sentinel gateway registry
Providing holistic operational, latency, and security remediation reports
Serving each gateway's guardrail configuration, which gateways pull over their outbound heartbeat connection

Data plane (your machine or network)

The local Sentinel gateways act as high-performance, stateless reverse proxies running directly where your applications live: on a PC with the Windows app or the CLI, or in your own cloud or cluster. They handle all of the traffic interception, real-time guardrail execution, and direct upstream routing to AI models.

Core technical features

Containerized deployment & scale

The Sentinel is distributed natively as a lightweight Docker image. For local development and quick staging, it can be spun up in seconds using Docker containers. For production-scale deployments across high-availability clusters, SUPERWISE provides a standardized Helm chart to deploy and auto-scale Sentinels inside Kubernetes. See Deploy a gateway.

Which providers does Sentinel support?

Out of the box, the Sentinel engine integrates with major foundation model APIs. It maps and translates incoming client payloads to the following covered providers:

OpenAI API
Anthropic API
Gemini API
Custom providers: any OpenAI-compatible endpoint (see Custom providers)

Configuration-based routing (zero code changes)

Traffic is redirected to the gateway purely through standard environment configuration. Because the Sentinel exposes open-standard endpoints, developers do not need to rewrite their code or change their underlying SDK libraries. To instrument any application, you simply update the provider's base URL to point to your running Sentinel instance. See Connect your applications.

How does Sentinel intercept a request?

The gateway is a reverse proxy: your applications send their LLM traffic to it, and it forwards each request upstream. It sits only in your LLM path, not in front of all your traffic, and intercepts the primary text-generation routes:

Provider	Intercepted endpoint route
OpenAI	v1/chat/completions
Anthropic	v1/messages
Gemini	generateContent

Based on the provider given, only the intercepted endpoint routes listed above are processed by the proxy. All other routes pass through as usual without interception (for example, the embeddings API for OpenAI or any other non-generation endpoint).

What happens to the request payload?

When a generation route is triggered:

The Sentinel extracts and parses the request payload — the prompts and messages, and any images attached to them
The extracted content is run through the local guardrail stack: text guardrails check the prompts and messages, and the image guardrails (resolution and sharpness) check the attached images
Pass-through execution: Aside from the content analyzed and modified by the active guardrails, all other application parameters and metadata are passed as-is to the upstream LLM provider
Response pass-through: The upstream provider's response is streamed back to the client application unmodified, with its original structure intact. Guardrails currently run on inbound prompts only.

For what stays on your side and what reaches SUPERWISE, see Data privacy.

Failure modes and limits

What a gateway checks, and what it leaves alone:

Inbound prompts only. Guardrails run on the prompt before it is forwarded. The provider's response is streamed back to your application unmodified, so model output is never checked or redacted.
Generation routes only. The gateway checks OpenAI v1/chat/completions, Anthropic v1/messages, and Gemini generateContent. Every other route, such as OpenAI embeddings, passes through unchecked. A custom provider is checked on v1/chat/completions unless you set its target_routes.
Text and images. Most guardrails read the text of the prompt and messages; the image resolution and image sharpness guardrails check the images attached to a prompt. Other non-text and multimodal fields pass to the provider as sent.
Redirected traffic only. A tool is covered when its provider base URL points at the gateway. The gateway sees nothing that calls a provider directly. To stop traffic going around it, allow only the gateway to reach the providers' APIs at your firewall.
Policy changes on the next heartbeat. Each gateway calls the control plane every 60 seconds and pulls its policy in the reply, so a saved change takes effect within about a minute.
Status follows the heartbeat. A gateway that misses 10 consecutive heartbeats, 10 minutes, shows as Pending in the app. See Gateway states.
Diagnostic traffic is not recorded. Requests to the gateway's /test route never appear in Live activity or the dashboards.

Not yet documented

These behaviors are not yet documented:

Whether a gateway forwards requests (fails open) or rejects them (fails closed) when it cannot reach the control plane, and which policy it enforces in the meantime.
What a gateway does with a request when a guardrail check itself errors.
Measured latency the gateway adds to a request. Until then, Live activity shows the Policy latency of every request your own gateways handle, and the Operational dashboard shows its average, P95, and P99.

What do the terms in these docs mean?

These docs use one name for each concept:

Term	Meaning
AI gateway	Software that sits between your applications and the large language models they call, and inspects and controls every request.
SUPERWISE Sentinel	The SUPERWISE AI gateway. "Sentinel" for short.
Sentinel gateway, or a Sentinel	One running instance of Sentinel, on a PC or in your network. Each one is registered in the SUPERWISE app's Sentinels list with its own ID, state, and policy.
Guardrail	One check a gateway runs on each inbound prompt. Most check the prompt's text — secret and credential detection, PII redaction, rudeness and toxicity, language check — and image resolution and image sharpness check the images attached to it.
Policy	The full set of definitions a Sentinel pulls from the control plane and enforces — both the guardrails it runs on each inbound prompt, in order, with the action each takes on a match, and the token-optimization techniques it applies. The guardrail part is managed on the Guardrails tab; see Manage guardrails. In the platform, a policy is a separate thing: a monitoring rule with a metric and a condition.
Remediate	The guardrail action that replaces each matched value with a placeholder, `{{REDACTED}}` by default, and forwards the request.
Block	The guardrail action that rejects the request, so it never reaches the model provider.
Control plane	The part of the platform, hosted in the SUPERWISE cloud, that registers your Sentinels, serves each one its policy, and receives their operational metadata.
Heartbeat	The outbound call each gateway makes to the control plane every 60 seconds to report its status and pull its policy.
Model provider	The company whose model answers the prompt, such as OpenAI, Anthropic, or Google (Gemini).

For plain-English definitions of wider AI governance terms, see the AI glossary on superwise.ai.

Architecture