Control Plane Overview

The Control Plane is the management API for the Agent Gateway. The LLM Gateway sits on the data path, verifying and recording each agent’s traffic. The Control Plane is the management path: it registers agents, holds their records and operating profiles, publishes the plugins and configurations the gateway enforces, and serves the audit history the gateway captures.

Most users work with the Control Plane through Guardian, which calls it for agent registration, the agent inventory, agent configuration, the gateway audit trail, and plugin configurations. Integrators call it directly to mint registration tokens from a pipeline, export audit exchanges and state history, manage operating profiles, or publish plugins as code.

The Control Plane is part of the gateway stack, which is optional and disabled by default. Its URL is the one Guardian is configured with for gateway features, usually on its own host and ending in /api, such as https://control-plane.example.com/api. Ask your administrator if you don’t know it.

What the Control Plane Owns

• Agent records, their signing keys and bound users, their status, and their revoke, restore, and deregister history
• Agent registration tokens, which Viper exchanges with the gateway to register an agent
• Operating profiles and their versions, the tool inventory each agent reports, configuration snapshots, and their validation findings
• Project membership and trust evidence, and the credentials each agent presents in a project. Projects themselves belong to Guardian: the Control Plane keys this state by the project’s UUID and keeps no copy of the project
• Agent certifications attached by Governance Service or an auditor
• Plugin definitions, signed plugin artifacts, and plugin secrets, and plugin configurations, globally and per project
• Configuration validation rules
• Platform users and their roles
• Read access to audit exchanges, plugin events, state history, and the blobs they reference
• VirusTotal verdicts for the blobs callers look up, when scanning is enabled

What the Control Plane Depends On

The Control Plane relies on Auth Service to validate tokens and check permissions, including on Guardian projects, which it reads from Guardian, and Integrity Service to read and check the status of membership, compliance, and certification credentials. It shares the gateway database with the LLM Gateway, which creates its tables, and stores plugin artifacts in object storage.

Authorization fails closed: while Auth Service is unavailable, requests that need a token or permission check are refused. While Integrity Service is unavailable, submitting membership, trust, or certification evidence fails with 503, and stored credential statuses stop refreshing. A project membership or agent certification plugin with max_status_age_seconds set then denies requests once those statuses are older than the limit.

Where to Go Next

• Use the Agent Gateway guides for end-user workflows.
• Use the Control Plane API reference for exact request and response shapes. A running Control Plane also serves its own spec at /api/openapi.json.
• Use Chart Values to enable the gateway stack.

Related

• Control Plane Architecture — how it works with the LLM Gateway, Guardian, and the platform services
• Control Plane Authentication and RBAC — accepted credentials and the roles that gate each route
• Control Plane Configuration — the settings an operator must provide
• Control Plane Operations — health checks, upgrade order, and symptom checks
• Gateway Basics — the data path the Control Plane manages
• LLM Gateway Overview — the service that enforces what the Control Plane publishes