Runtime AI Control Planes

Why runtime control planes are the 2026 layer

The 2024–2025 conversation about AI governance was still mostly about policy documents. In 2026 it is about runtime. CIOs are no longer asking 'what should our AI usage policy say?' — they are asking 'what is actually running, who has access, and what controls are enforced when the agent moves?' Those are runtime questions, and answering them requires a control plane, not a PDF.

The forcing function is agent proliferation. Copilot, Claude, ChatGPT Enterprise, GitHub Copilot, Cursor, custom LangGraph agents, MCP servers — a midmarket tenant now routinely runs 10–30 AI surfaces, most of them acquired without central procurement. Vendor consoles see their own tool well and everyone else's not at all.

The four layers

A control plane is not a monolith. It is four cooperating layers, each of which can be swapped, but none of which can be omitted:

• Identity — SSO + device trust + service-account registry. Personal-account sign-ins to sanctioned tools are blocked at the identity provider.
• Policy — the rule engine that decides which principal can invoke which tool under which approval tier. Versioned in git alongside the reference architecture.
• Model routing — the proxy that resolves 'which model for which workflow at which quality floor?' — including cross-provider and self-hosted routing.
• Execution telemetry — the tamper-evident audit trail: append-only, hash-chained, exported to SIEM within minutes of each call.

Tool classification — the least-glamorous, most-load-bearing step

Every tool exposed to an agent gets one of four action classes: read, recommend, write, execute. Read actions typically run without approval. Recommend actions produce drafts for humans. Write actions require policy checks + approval routing. Execute actions — external send, financial commitment, record deletion, provisioning — require approval tokens with named approvers.

The classification is boring, and it is the single most important act of design in the control plane. Without it, everything collapses into either 'nothing works because everything needs approval' or 'nothing is safe because nothing needs approval'.

Kill-switch design and drills

A control plane's most-tested code path should be the kill-switch. Revocation must be possible per user, per agent, per connector, and per tool scope, in under five minutes, without paging the platform owner.

The right test is a drill, not a document. In our engagements, week 14 is always a live kill-switch exercise across all four scopes. It is the first time the security team sleeps through a rumor.

Reference architecture

The pattern we install:

• Users + service accounts authenticate via SSO with device-trust posture checks.
• All sanctioned agent traffic enters through a gateway (LiteLLM or equivalent) fronting the policy engine (OPA-shaped).
• The policy engine evaluates principal + tool + action class + risk score + approval tier.
• The router selects the model that meets the workflow's quality floor at the lowest cost.
• Tool adapters (native + MCP) execute the call; human-approval service pauses runs that need it.
• Every event — decision, tool call, arguments, model choice, latency, outcome — writes to an append-only audit store and streams to SIEM.

10–16 week implementation sequence

• Weeks 1–3: inventory (identity logs + egress + expense + admin exports); tool classification; policy-graph v1.
• Weeks 4–7: gateway + policy engine build; SSO + tenant-account enforcement.
• Weeks 8–10: model router; human-approval service in Slack / Teams.
• Weeks 11–13: audit store + SIEM integration; kill-switch controls.
• Weeks 14–16: rollout to sanctioned agents; kill-switch drills; runbook handoff.

Failure modes to avoid

• Incomplete inventory — every unknown agent is a bypass channel. Re-run discovery quarterly.
• Approval fatigue — classification tunes thresholds by risk tier; low-risk read stays frictionless.
• Inconsistent identity — enforce SSO + service-account registry; ban personal-account sign-ins.
• Audit tampering — separate write scope from read scope; hash-chain the log; ingest into SIEM within minutes.
• 'Governance platform' vendor lock-in — most vendor platforms cover their own agent well and everyone else's poorly. Vendor-neutral is a design goal.