Control Plane vs. Execution Plane

Keep policy and authority in trusted services; give each execution only the context and capabilities its task requires.

By E. M. AbdullahPublished Updated

Control Plane vs. Execution Plane

Keep policy and authority in trusted services; give each execution only the context and capabilities its task requires.

Context.

A procurement team asks a model to assess a vendor contract. The organisation holds pricing, bank details, negotiation history, and other contracts for that vendor. The assessment needs delivery clauses and quality obligations. Giving the model a database credential is an expensive way to avoid writing a careful reader.

The workflow needs trusted decisions about identity, context, models, and permitted effects. It also needs stochastic computation whose output cannot be trusted merely because the organisation requested it. Those responsibilities should have different homes.

Problem.

When the same component assembles arbitrary context, holds credentials, invokes a model, and executes its suggestions, the model's practical authority is hard to describe. A prompt can ask it to use fewer privileges, but cannot remove privileges from the process around it.

The question is therefore concrete: which bytes can this execution read, which requests can it make, and which effects can it cause? A diagram with two boxes is insufficient if both boxes share a powerful identity or unrestricted network route.

Forces.

  • Useful work needs context, while unnecessary context increases disclosure risk and inference cost.
  • Isolation must cover credentials, storage, network access, resource consumption, and cross-request residue.
  • Shared policy needs consistent enforcement without making one central process a dependency for every local decision.
  • Model services can be remote. A local sandbox does not enclose the provider's infrastructure or control its retention.
  • Capability selection, context compilation, and validation must retain their versions as teams and models change.

Pattern.

Separate authority from computation. The Control Plane authenticates the caller, applies policy, selects an allowed strategy and model, and compiles bounded context. It controls access to protected resources and records the authority it grants. Domain data may remain in its owning service; trusted readers retrieve only authorised material.

The Execution Plane receives an execution capsule: a manifest of supplied context, selected model, output contract, resource limits, and permitted capabilities. Its output is a candidate, returned through an airlock before becoming accepted State or causing an effect. Governance can be deterministic around that candidate without making model generation deterministic.

Start with no tools and no general network access. If a later step needs more evidence, return a request for the Control Plane to authorise and compile a new capsule. Where mediated tool proposals are supported, a trusted broker checks each proposal and its arguments. The sandbox never inherits the broker's credentials or authority.

This borrows the separation of management from runtime work seen in Kubernetes components, Envoy's dynamic configuration, and Istio's architecture. These are precedents for responsibilities, not proof that a service mesh makes an AI workflow safe. V8 isolates in Cloudflare Workers provide another isolation precedent; the appropriate runtime boundary still depends on the code and threats you accept.

Implementation.

For the procurement assessment, begin with a read-only capsule. This illustrative specification describes the enforcement contract between the compiler and runtime. Its numbers are example limits, not measured guarantees.

capsule_id: procurement.cap-8472-1
workflow_id: procurement.review-8472
step: assess-delivery-risk
tenant_id: tenant-7
issuer: procurement-control
policy_version: vendor-review.v6
strategy_version: delivery-risk.v3
expires_at: "2026-09-28T14:05:00Z"
context:
  manifest_ref: evidence/vendor-8472-context-v1
  digest: illustrative-context-digest
  allowed_fields: [delivery_clauses, quality_obligations]
  source_revision: contract-8472.v12
model:
  route: approved-contract-reviewer
  configuration_version: model-route.v4
output_contract: DeliveryRiskAssessment.v2
runtime:
  identity: capsule-scoped
  filesystem: ephemeral
  network: deny
  tools: []
  memory_mb: 256
  wall_time_ms: 8000
  maximum_output_tokens: 1200
completion:
  airlock: procurement-assessment.v2
  accepted_state_writer: procurement-control
  direct_mutation: forbidden

The trusted compiler authenticates the procurement user and checks access to contract 8472. A domain reader extracts the permitted fields from revision 12. The compiler stores the actual context under restricted access and records its digest. A runtime resolver obtains those bytes and mounts them read-only before execution; the worker receives no general storage credential. References in the manifest are not permissions to fetch arbitrary objects.

The runtime validates the issuer, tenant, expiry, and manifest integrity before starting. Enforce limits using the runtime and infrastructure, not instructions in the prompt. Destroy temporary files and request-local caches on completion. Shared caches need explicit tenant separation and retention rules. Preserve durable business memory through newly authorised context, rather than an invisible worker session.

With a hosted model, a trusted adapter sends the approved context to the selected provider. The worker's network prohibition does not mean that no data leaves the organisation: the adapter is the controlled egress path. Record the actual model identifier and destination, and apply the organisation's data-handling policy before sending. Any sensitive detail included in a summary is still disclosed to that provider.

The result passes through the named airlock. A timeout, refusal, malformed result, or exhausted budget becomes an explicit attempt outcome. Retry only within a bounded policy and record a new attempt. The runtime cannot loosen limits to finish the job. If mandatory lineage capture is unavailable, do not release an accepted result without durable local evidence.

Distribute enforcement with clear ownership. The platform team supplies identity, runtime controls, and policy distribution. Procurement owns the permitted task and domain validators. The data service retains final access control. Local enforcers pin a policy version for explanation and check current revocation rules before effects. Define a maximum policy age; stop affected work when freshness cannot be established. A stale cache is not an unlimited grant.

Consequences.

The organisation gains a bounded answer to what an execution could access. A faulty or hostile model has fewer routes to protected state, and model replacement need not change business permissions. Context manifests also make disclosure reviews and cost attribution more practical.

Compilation, isolation startup, trusted retrieval, and validation add latency. Capsule manifests and retained context increase storage. Operators must maintain identities, brokers, policy distribution, sandbox updates, and cleanup. Organisational friction appears when domain teams request broader access and platform teams need evidence for granting it.

Measure compilation and execution separately, including queue time and tail latency. Bound concurrency per tenant so one workflow cannot consume all capacity. The Control Plane remains a valuable attack target: compromise there can grant excessive authority. Separate administrative duties and narrow service credentials within that plane too. Logical separation is a useful start, but enforceable boundaries carry the security claim.

Anti-patterns.

Two names, one credential. Both planes share a database identity with unrestricted access. Rename nothing until the runtime can demonstrably refuse an unauthorised read or write.

The prompt sandbox. Instructions say that tools are forbidden while tools remain callable. Remove the capability at the adapter and infrastructure boundary.

The central decision queue. Every prompt or local retrieval change needs a shared service release. Delegate composition within governed contracts and keep local enforcement mandatory.

Test.

Run a hostile candidate that requests another tenant's data, attempts network access, exceeds its deadline, and tries a direct write. Inspect actual denials and cleanup, then retrieve the capsule, effective policy, supplied context, and result verdict. Repeat during a policy outage. If the boundary depends on the model cooperating or an expired authority remains usable, the separation is incomplete.

Related.

This is the isolation layer of Vertical AI Foundation. Causal Lineage preserves its scope decisions, AI Airlocks govern the return path, and a steward authors the rules. Thin Boundary explains how teams compose work within those rules without creating the bottleneck described in The AI Mainframe Trap.