P134 · Safety & trust

Tool-Constraint Boundaries

Enforce capability boundaries across every available execution route.

Editorially reviewed

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A read-only reviewer loses Edit but retains Shell/HTTP writes. Teaching load-html has setcontent aliases; permission lookup by spelling misses equivalent effects.

Mechanism

Inventory reachable file/remote mutation paths and canonicalize supported aliases before permission lookup/dispatch/audit, rejecting unknown spellings. Enforce actual filesystem/network boundaries on generic execution rather than hiding names. Test editor/shell/HTTP/alias denial while preserving reads, recording host limits/gaps.

Bad example

Removing Edit proves read-only while setcontent and shell writes remain allowed.

Good example

Resolve load-html/setcontent to one write effect before read-scope checking. Enforce editor/shell/remote restrictions with controlled targets, preserving reads and rejecting unknown aliases instead of fallback execution.

Why the change matters

Aliases/generic tools reach equivalent effects. Canonicalization plus runtime constraints covers routes rather than one banned spelling.

Observable expectation

Teaching canonical/alias writes reject and reads pass; generic mutation attempts leave targets unchanged. A denial printed after writing fails protection. Audit original request/canonical effect without secrets.

Limits

Dynamic plugins add routes, so inventories require refresh. Prose/alias tables alone do not isolate execution; actual network protocols matter. One negative does not prove every bypass blocked.

Sources and evidence

Read the editorial criteria

Related methods