# Agent Control Plane

Highflame's agent control plane is the operational layer for securing and governing agent systems in production. It gives teams one place to define runtime guardrails, manage Cedar policies, register MCP servers, and investigate what happened across prompts, tool calls, sessions, and traces.

The control plane is not a single proxy. It is a set of connected services and interfaces:

* **Studio** is the UI where teams configure agents, policies, MCP servers, and investigations.
* **Shield** evaluates guardrails and runtime policy decisions.
* **MCP Registry** acts as the MCP gateway and tool access boundary.
* **Observatory** exposes analytics and investigation APIs backed by ClickHouse.
* **Policy** provides the typed Cedar policy system used across products.

For developers, this means you can move from ad hoc per-agent configuration to a shared control surface with versioned policies, consistent security decisions, and project-scoped telemetry.

#### What The Control Plane Covers

The agent control plane brings together four workflows that usually end up fragmented across different tools:

* **Guardrails** for runtime inspection of prompts, outputs, tool calls, and multi-turn agent behavior
* **Policies** for formal, schema-backed authorization and enforcement logic
* **MCP Gateway** for registering MCP servers, handling client authentication, and controlling downstream tool access
* **Observability** for threat investigation, trace analysis, session analytics, and cross-product posture

These workflows are connected by shared tenant context, shared policy definitions, and shared telemetry. A policy edited in Studio can influence Shield decisions. An MCP tool called proxied by the MCP registry can be evaluated by Shield and then investigated in Observatory. The result is a control plane that keeps configuration, enforcement, and investigation in sync.

#### How It Fits Into The Platform

Highflame uses the control plane to coordinate the runtime services that sit closest to agent execution:

1. An application, SDK, or MCP client sends traffic into Highflame.
2. Shield evaluates the request or tool interaction against detectors and Cedar policies.
3. MCP gateway brokers MCP access and downstream credentials when the flow involves MCP servers.
4. Events, sessions, and traces are emitted through the observability pipeline.
5. Observatory and Studio expose those results for debugging, governance, and operational review.

This model is designed for teams that need more than a request log. It gives you a way to manage agent behavior as a first-class system concern, with explicit controls, typed policies, and evidence you can investigate later.

#### Working In Studio

In practice, teams use Studio as the entry point to the control plane. Studio provides the operational UI for:

* creating service keys and project-scoped credentials
* managing guardrail profiles and baseline protections
* editing Cedar policies with schema-aware validation
* registering MCP servers and controlling which tools are enabled
* exploring threats, sessions, traces, and Command Center views

The rest of this section covers each part of that control plane in more detail.