LLM06: Add structural authority separation mitigation

[devongenerally-png]

Summary

Adds a ninth prevention/mitigation strategy to LLM06: Excessive Agency — structural authority separation between an LLM agent's tool selection and tool execution.

What's added

Mitigation #9: Enforce structural authority separation

The existing eight mitigations are primarily behavioral (minimize extensions, minimize permissions, require user approval, sanitize inputs). This addition addresses the architectural root cause: the entity that proposes an action should never be the same entity that authorizes it.

The mitigation recommends interposing a deterministic (non-LLM) policy engine that evaluates structured intents against deployer-defined rules before tool execution proceeds. This maps to the same principal separation that operating systems enforce between user-space and kernel-space.

Reference link #7: Links to an open-source reference implementation of this pattern.

Why this belongs here

The LLM06 description already identifies the root causes as "excessive functionality, excessive permissions, excessive autonomy." The existing mitigations address functionality and permissions well. This addition directly addresses the autonomy component — the gap between an agent deciding to act and the action being authorized by a separate, deterministic authority.

Changes

• 2_0_vulns/LLM06_ExcessiveAgency.md — one mitigation strategy, one reference link (5 lines added)

[KeystoneSmartQuotes]

This mitigation captures the right architectural principle. The OS kernel/user-space analogy is precise — in distributed agent systems the same separation failure mode occurs when the agent both decides and executes without a deterministic intermediary.
One addition worth considering: the separation should be not just structural but binding. A policy engine that evaluates structured intents and returns an advisory result still leaves the agent able to act without a valid authorization record. The stronger form is that execution is structurally impossible without a signed decision artifact from the policy engine — so the separation is enforced at the tool boundary, not just recommended.
This also means denials are recorded unconditionally, which matters for the audit trail LLM06 implicitly requires.