A scoped view of client tool policy

Each gate returns on failure, so a denied call never reaches the gates below it.

You are here

SourceAuthorizationSink

1. The gate order

Client-mode tool authorization runs these gates in order. Each one returns on failure, so the case that stops at enablement never reaches the authorization check, and its reason names the gate that actually closed.

AllowlistIs the tool listed for this session?
- BLOCKEDempty allowlist: Tool 'search' not in session allowlist
EnablementIs a destructive tool enabled at all?
- BLOCKEDshell_execute disabled: Destructive tool 'shell_execute' not enabled
AuthorizationIs there a matching authorization event?
- BLOCKEDshell_execute enabled, no authorization: Destructive tool 'shell_execute' requires authorization
PermittedContinues to rate limiting and binding.
- ALLOWEDNon-destructive tool, implicit allow
- ALLOWEDAuthorization verified

Restricted decision matrix

Tool	Enablement / allowlist	Authorization	Decision	Generated reason
search	not restricted	none	Allow	`Non-destructive tool, implicit allow`
search	empty allowlist	none	Deny	`Tool 'search' not in session allowlist`
shell_execute	disabled	none	Deny	`Destructive tool 'shell_execute' not enabled`
shell_execute	enabled	missing	Deny	`Destructive tool 'shell_execute' requires authorization`
shell_execute	enabled	matching	Allow	`Authorization verified`

Evidence, scope, and reproduction

Scope and instrumentation

These lanes assume principal trust, denylist, capability scopes, contamination and escalation policy, message binding, action and bidirectional scope checks, TTL, rate policy, and request binding have not already denied the call.

Adversary A1/A2AuthorizationT-IN5 · T-IN12A-AS2Source: PolicyEngine.check_tool_executionTest: tests/test_demo_scenarios.py

Exact fixture test: tests/test_demo_scenarios.py::test_policy_fixture

.venv/bin/python -m pytest tests/test_demo_scenarios.py::test_policy_fixture -q

Generated fixture