> 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.1-authority-security-boundary.md).

# 8.1 Authority Security Boundary

The **Authority Security Boundary** is the security boundary around the authority state used by the LPP Admission Kernel.

Its purpose is to protect the transition:

```
Principal
→ Authority
→ Scope
→ Admissibility
→ Execution
```

from being rewritten by the system that wants to execute.

The hardened Authority Layer model defines a governance state conceptually as:

```
G = (A, D, S, R, P, T)
```

where:

* `A` = authority state,
* `D` = delegation graph,
* `S` = scope mapping,
* `R` = risk / consequence state,
* `P` = policy state,
* `T` = time state.

An execution proposal may be represented as:

```
E = (
    principal,
    function,
    parameters,
    target,
    hash
)
```

The security objective is that execution does not become valid merely because `E` exists.

The relevant authority state must remain valid.

#### Threat Model

The current Authority Layer Security Specification assumes that an adversary may attempt to:

* control or manipulate model output,
* inject prompts,
* spoof identity,
* replay previous authorization,
* expand scope,
* downgrade policy,
* exploit revocation timing,
* or compromise the Control Plane.

The baseline threat model assumes that the underlying cryptographic primitives themselves are not broken and that protected authority registries and signing material have not already been successfully subverted beyond the modeled controls.

That assumption matters.

LPP security does not make cryptographic compromise impossible.

It structures what must remain protected.

#### Core Authority Invariants

The hardened model defines six principal security invariants.

**I1 — Authority Validity**

Successful admissibility requires an applicable active authority state.

Conceptually:

```
Admit(E, G) = TRUE
⇒
∃ a ∈ A such that:

a applies to E.principal
∧ a remains valid
∧ a is not expired
∧ a is not revoked
```

**I2 — Scope Containment**

The execution proposal must remain inside authorized scope.

```
ExecutionIntent
⊆
AuthorizedScope
```

**I3 — Delegation Acyclicity**

Delegation must not form circular authority paths.

```
¬Cycle(D)
```

**I4 — Single-Use Authorization**

Previously consumed authorization material must not become reusable authority for another execution.

**I5 — Continuous Admissibility**

Where the execution profile requires continuous enforcement, authority must remain valid throughout the relevant execution window.

**I6 — Fail-Closed**

Undefined mandatory admissibility state must not become permission.

```
Admit = undefined
        ↓
No execution
```

#### Security Properties

If the required invariants actually hold in a deployment, the intended properties include:

* no execution without valid authority,
* no silent scope expansion,
* no circular delegation,
* no valid replay,
* no continued reliance after revocation,
* no execution under unresolved mandatory authority state,
* and reconstructable governance evidence.

These are **conditional architectural properties**.

Their strength in production depends on the strength of the actual enforcement topology.