Tool-Constraint Boundaries
Enforce capability boundaries across every available execution route.
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.