> For the complete documentation index, see [llms.txt](https://docs.lpp-minduniverse.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lpp-minduniverse.org/lingua-pactum-protocol-lpp-documentation/8.-security-and-enforcement/8.2-control-plane-execution-plane-separation.md).

# 8.2 Control Plane / Execution Plane Separation

The most important security separation in the reference architecture is:

> **Control Plane (CP) ≠ Execution Plane (EP)**

The two planes operate in different trust roles.

#### Control Plane

The Control Plane maintains or evaluates governance state.

Reference responsibilities include:

* identity and principal verification,
* Authority Object lifecycle,
* revocation state,
* versioned policy state,
* consequence or risk inputs,
* LPP Admission Kernel evaluation,
* Execution Permit issuance,
* and Admission Artifact signing.

Conceptually:

```
Control Plane
=
Authority + Admission + Permit State
```

#### Execution Plane

The Execution Plane is where external action occurs.

It may contain:

* agent runtime,
* LLM or agent orchestrator,
* tool executor,
* API connector,
* database connector,
* infrastructure controller,
* payment connector,
* deployment system,
* or physical effector interface.

Its valid role is:

```
Propose
Request
Verify
Execute
```

not:

```
Propose
Authorize itself
Execute
```

#### Zero-Trust Boundary Principles

The reference CP / EP model defines five core boundary principles.

**ZTB-1 — No Implicit Trust Across Planes**

An EP request does not become trusted merely because it originates from an internal agent.

EP → CP interactions should be authenticated, authorized, logged, and appropriately constrained.

**ZTB-2 — EP Cannot Self-Authorize**

The Execution Plane may request authorization.

It may not issue itself the valid Permit required for governed execution.

**ZTB-3 — EP Cannot Mutate CP Authority State**

The Execution Plane must not be able to rewrite:

* authority state,
* revocation state,
* policy state,
* or Control Plane signing material

as part of its ordinary execution privileges.

**ZTB-4 — Fail-Closed by Topology**

If required CP verification is unavailable or fails, the EP does not silently continue with governed execution.

**ZTB-5 — Execution Gating Is Enforcement, Not Advice**

Permit verification belongs inside the execution path.

It is not merely an instruction to the language model.

#### Non-Bypassable Chokepoint

The reference pattern is:

```
Agent / Runtime
        ↓
Execution Request
        ↓
ExecutionHook.VerifyPermit()
        ↓
     Valid?
    /     \
   No      Yes
   ↓        ↓
 BLOCK    EXECUTE
```

Effect-producing tools and connectors must not expose an alternative governed route that bypasses the Permit check.

#### Separation Strength

The reference architecture defines multiple deployment strengths.

**Logical Separation**

Separate CP services, access boundaries, protected keys, and enforced executor-hook verification.

**Strong Separation**

Stronger network segmentation, attested workloads, immutable policy state, and continuous revocation mechanisms.

**High-Assurance Separation**

Separate administrative trust domains, independent Permit issuance, dual control, or multi-party authority mechanisms.

**Physical Enforcement**

Optional hardware-mediated gating or circuit-breaker mechanisms.

These represent increasing enforcement strength.

They must not be confused with current MVP validation status.

***