> 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/3.canonical-governance-architecture/3.6-control-plane-execution-plane.md).

# 3.6 Control Plane / Execution Plane

The architecture separates the system that controls legitimacy and authorization state from the system that produces external effects.

The two trust domains are:

```
Control Plane (CP)
≠
Execution Plane (EP)
```

This separation is a core anti-self-authorization principle.

#### Control Plane

The Control Plane maintains or evaluates governance state required for execution authorization.

Reference components may include:

* identity and principal verification,
* authority lifecycle services,
* revocation state,
* scope registry,
* versioned policy state,
* risk or consequence inputs,
* the LPP Admission Kernel,
* Permit issuance,
* artifact signing,
* and tamper-evident governance records.

The Control Plane may issue:

* an Execution Permit,
* a denial result,
* revocation state,
* or signed governance evidence,

according to the applicable implementation.

#### Execution Plane

The Execution Plane is where external action occurs.

Reference components may include:

* agent runtime,
* tool executor,
* function executor,
* API connectors,
* infrastructure connectors,
* databases,
* payment systems,
* deployment systems,
* or physical effectors.

The Execution Plane may:

* construct or propose Execution Intent,
* request admission,
* present an Execution Permit,
* execute when the Permit is valid,
* and report execution outcome.

It may not:

* alter authority state,
* grant itself authority,
* mint its own valid Permit,
* override revocation,
* rewrite admission history,
* or redefine admission conditions in order to execute.

#### Zero-Trust Relationship

No implicit trust is assumed merely because CP and EP belong to the same application or organization.

The reference security model requires authenticated and governed interaction between the planes.

The central principles are:

**No implicit trust across planes**

EP requests do not become legitimate simply because they originate inside the system.

**EP cannot self-authorize**

EP may request execution.

CP determines whether applicable authorization can be issued.

**EP cannot mutate CP authority state**

Execution logic cannot rewrite the state that decides whether execution is legitimate.

**Fail-closed behavior**

If required verification fails, the architecture does not silently treat uncertainty as permission.

**Execution gating is enforcement**

Permit verification occurs in the execution path rather than as optional agent reasoning.

#### Logical vs Physical Separation

Control Plane / Execution Plane separation is a governance and security requirement.

The exact deployment topology may vary.

A reference deployment may use:

* separate processes,
* separate services,
* separate networks,
* isolated trust domains,
* enclaves,
* independent issuers,
* or hardware-mediated enforcement.

The canonical principle concerns authority separation.

It does not require every implementation to use identical infrastructure.

#### Why Separation Matters

Without CP / EP separation, the following failure becomes possible:

```
Agent proposes action
        ↓
Agent evaluates itself
        ↓
Agent approves itself
        ↓
Agent executes
```

That architecture turns governance into self-attestation.

LPP instead requires:

```
Execution Plane proposes
        ↓
Independent governance state is evaluated
        ↓
Permit is issued only when conditions hold
        ↓
Execution Plane verifies Permit
        ↓
Execution occurs
```

The distinction converts authority from a model assertion into a structural control boundary.

***