> 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/12.-interoperability-and-standards/12.5-capability-authorization-mapping.md).

# 12.5 Capability / Authorization Mapping

LPP is adjacent to capability and authorization systems but occupies a different governance layer.

Paper 4 establishes the core distinction:

```
Capability Token
=
Constrained ability
```

```
Authority Object
=
Legitimacy basis
for that constrained ability
```

#### Capability Systems

A capability mechanism may determine that a principal possesses the ability to perform:

```
Action X
```

under defined constraints.

This is useful for execution security.

LPP asks an upstream question:

> **Should that capability legitimately be usable for this particular AI-triggered action?**

#### Access Tokens

An access token may permit:

```
API invocation
```

or:

```
resource access.
```

It does not by itself prove that the resulting action has:

* valid upstream authority,
* preserved intent,
* valid lifecycle state,
* revocation clearance,
* or constitutional admissibility.

#### Macaroons / Attenuated Credentials

The Authority Objects research identifies contextual caveat systems such as Macaroons as conceptually relevant because they support attenuation based on conditions such as:

* where,
* when,
* by whom,
* or under what constraints

a credential may be used.

This makes them useful adjacent mechanisms for:

* delegated authorization,
* scope attenuation,
* contextual restrictions,
* and Permit-like execution constraints.

The governance distinction remains:

```
Attenuated Capability
=
bounded ability
```

while:

```
Authority Object
=
upstream legitimacy basis
```

#### Runtime Authorization

Policy or capability systems commonly answer:

```
Does this request satisfy
the current authorization rule?
```

LPP asks:

```
Does this request possess
a legitimate authority basis
that should be evaluated at all?
```

#### Mapping Direction

The preferred relationship is:

```
Authority Object
        ↓
LPP Admission
        ↓
Execution Permit
        ↓
Capability / Authorization Enforcement
        ↓
Execution
```

A deployment may implement these functions differently.

The semantic rule is:

> **Runtime capability must not be mistaken for constitutional authority.**

#### Layer 1 Can Restrict

A capability or authorization system may further narrow the Permit.

For example:

```
LPP Permit:
write within Scope S
```

may become:

```
Runtime capability:
read-only during current incident state
```

That is valid.

The reverse expansion is not.

```
Layer 1 authorization
may restrict Layer 0
but may not create missing Layer 0 legitimacy.
```