> 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/2.lpp-positioning/2.7-lpp-vs-runtime-security-functional-safety.md).

# 2.7 LPP vs Runtime Security / Functional Safety

LPP is complementary to runtime security and functional safety.

It addresses a different question.

#### Runtime Security

Runtime security asks whether system execution satisfies operational security constraints.

It may govern:

* tool calls,
* API access,
* resource access,
* sandbox restrictions,
* inter-agent communication,
* runtime permissions,
* environment constraints,
* or security policy enforcement.

These mechanisms are necessary.

They answer questions such as:

> Is this caller permitted to use this tool?

> Is this operation allowed under current security policy?

> Should this request be blocked at runtime?

LPP asks an upstream question:

> **Does this AI-triggered action have a legitimate authority basis to become a subject of runtime authorization at all?**

A secure execution environment can faithfully execute an illegitimate request.

Security of execution and legitimacy of execution are therefore distinct.

#### Functional Safety

Functional safety primarily addresses whether physical or technical systems remain safe under operating and failure conditions.

For example, a robotic platform may contain systems responsible for:

* obstacle avoidance,
* torque limits,
* safe operating envelopes,
* emergency stopping,
* equipment protection,
* or fail-safe behavior.

LPP does not replace these mechanisms.

Consider an autonomous mobile robot.

The robot may be:

```
Technically capable of entering Zone A
```

and:

```
Able to enter Zone A safely
```

while still lacking:

```
Legitimate authority to enter Zone A.
```

The reverse distinction also matters.

Valid authority to perform an action does not prove that the action is physically safe.

Therefore:

```
Admissibility
≠ Functional Safety

Admissibility
≠ Runtime Security
```

A complete high-consequence system may require all of them.

#### Different Failure Questions

Runtime security asks:

```
Can this execution path be exploited
or violate current security policy?
```

Functional safety asks:

```
Can this system operate without creating
unacceptable physical or technical hazard?
```

LPP asks:

```
Who legitimately authorized
this specific consequential action,
and does that legitimacy still hold?
```

These layers should complement rather than replace one another.