> 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.4-scope-escalation.md).

# 8.4 Scope Escalation

> **Scope escalation** occurs when an execution proposal exceeds the authority boundary legitimately granted upstream.
>
> The canonical invariant is:
>
> ```
> ExecutionIntent
> ⊆
> AuthorizedScope
> ```
>
> #### Common Escalation Paths
>
> The Authority Layer threat model identifies several relevant paths, including:
>
> * prompt injection,
> * function chaining,
> * implicit privilege inheritance,
> * target expansion,
> * delegated scope expansion,
> * and action transformation.
>
> A task can therefore begin with legitimate authority and still become unauthorized as execution scope grows.
>
> #### Function Chaining
>
> Suppose a Permit authorizes:
>
> ```
> read_configuration
> ```
>
> An agent must not infer that it may therefore perform:
>
> ```
> read_configuration
> → modify_configuration
> → restart_system
> → modify_network
> ```
>
> merely because those actions form a useful task chain.
>
> Each consequential action must remain inside the authorized envelope.
>
> #### Parameter Escalation
>
> The function may remain the same while parameters change the actual authority boundary.
>
> For example:
>
> ```
> delete_record(
>     customer_id = 42
> )
> ```
>
> is not equivalent to:
>
> ```
> delete_records(
>     all_customers = true
> )
> ```
>
> Scope validation must therefore include the relevant parameters rather than only the function name.
>
> #### Target Escalation
>
> Likewise:
>
> ```
> Host A
> ```
>
> must not silently become:
>
> ```
> Production Cluster
> ```
>
> simply because the underlying connector is capable of reaching both.
>
> #### Privilege Inheritance
>
> A downstream agent or tool must not acquire broader authority simply because an upstream principal had access to a privileged environment.
>
> ```
> Inherited capability
> ≠
> Inherited authority
> ```
>
> #### Mitigation Structure
>
> The existing security model associates scope protection with:
>
> * intent canonicalization,
> * execution-hash binding,
> * strict scope containment,
> * delegated-authority constraints,
> * and acyclic delegation.
>
> The important public invariant is:
>
> > **No scope expansion may be silently converted into valid execution.**
>
> A materially changed scope may instead require:
>
> * denial,
> * new authority,
> * modified authorized intent,
> * or re-admission,
>
> depending on the governing condition.