What Is a Control Plane: Policy Without the Hot Path

A control plane is where you change the system, not where traffic runs

In networking and infrastructure, a control plane is the part of the system that decides how work should be done. Routing protocols compute paths. Kubernetes controllers reconcile desired state. An SDN controller pushes forwarding rules. None of that is the packet. The packet is the data plane.

The distinction exists because the two jobs have opposite requirements. The control plane can be slower, more strongly authenticated, and centrally operated. The data plane has to be fast, regional, and boring on the hot path. If you mix them, a configuration change becomes an outage, and a traffic spike becomes a management outage.

The terms are not RequestRocket’s. They are how any system that both governs and forwards should be split. RequestRocket applies that split to outbound API access.

What the control plane holds

RequestRocket’s control plane is the management console and the Core API. It is where you create proxies, attach credentials, define rules and filters, invite members, and read aggregated analytics. Management calls are authenticated separately from proxy calls. They never hit a proxy endpoint.

What lives here:

• Identity and tenancy. Users, memberships, roles, client metadata. Managed service providers (MSPs) manage multiple client organisations from a single console – that hierarchy is control-plane state.
• References, not secrets. Credential records are created through this API. The encrypted secret is written to the regional data plane. The control plane keeps metadata: name, type, region, timestamps. GET does not return the plaintext.
• Telemetry and the request audit trail. The telemetry API returns per-proxy and per-client usage – request counts, success and error rates, average response times, country breakdown, meter consumption – aggregated by minute, hour, day, or month. The per-request audit record itself is stored with the data plane that handled the call, with a 90-day TTL, and queried through the Requests API. Both are read from the control plane; neither is traffic.
• Notifications. System, client, and user notifications – release notes, alerts on meter limits or rule matches, policy changes – are authored and consumed through the control plane.
• Policy as configuration. Rules, filters, meters, overrides, and proxy settings are authored here and pushed to the region that will enforce them.

The two sides of the system are two different API calls. A management call creates a rule:

POST /clients/{clientId}/proxies/{proxyId}/rules
{
  "effect": "allow",
  "ruleActive": true,
  "methods": ["GET"],
  "path": {
    "path": { "pattern": "^/v1/charges" },
    "presence": "must_exist"
  }
}

A proxy call uses that rule – a caller hits the regional endpoint with a proxy credential, and the data plane evaluates the rule at request time. Different URLs, different credentials, different jobs.

The control plane does not decrypt vendor keys. It does not forward HTTP to Stripe. It does not sit in the path of an agent making a call. If it is unreachable, existing data planes keep enforcing the last pushed policy. If a data plane region has a bad day, you can still change configuration.

The product page for this split is Control Plane. The runtime half is What is a data plane.

What it is not

It is not a second proxy. Putting “management” on the same hostname, the same credential, or the same request path as traffic collapses the split. A leaked proxy key should not be able to invite members or read every credential name in the account. A leaked console session should not be the vendor API key.

It is not where you store secrets “because that is where you created them.” Creation is a control-plane call. Storage is a data-plane write, AES-256-GCM, in credentialRegion. Mixing those sentences is how people conclude the management database holds Stripe keys. It does not.

It is not a replacement for your identity provider. Members still sign in. The control plane authorizes what those members may configure. Runtime callers never become members; they present a proxy credential to the data plane.

Why the split matters for APIs you don’t own

Inbound API gateways already have this language. The new problem is outbound: agents and apps calling vendors you do not operate. The credential that unlocks the vendor, the policy that says which paths an agent may hit, and the log of what actually happened are three different things. They should not share a process, a database, or a failure domain.

Configure once, enforce everywhere the traffic is. Change a rule in the console and the regional runtime picks it up without a deploy of your app. Move the runtime to a dedicated or self-hosted region later – dedicated managed and self-hosted RequestRocket – and the control plane stays where it is. That is the point of not putting policy on the hot path.

Next steps

If you are mapping RequestRocket onto a diagram, draw two boxes. Left: console and Core API. Right: regional gateways. Arrows from left to right are configuration. Arrows from callers to the right are traffic. Read the architecture overview or the Control Plane page. RequestRocket is runtime access control for AI agents and apps calling APIs you don’t own – every call gets a least-privilege credential, a policy check, and an audit record, with no code changes.