Fail-closed high-risk tool execution when confirmation policy is missing

[davidahmann]

Problem observed

High-risk tools can still execute when confirmation policy configuration is missing or permissive, especially when tool registration is dynamic (function tools and MCP tool wrappers). The practical effect is that a configuration omission can silently broaden execution authority. For operators, that means unsafe actions may run in contexts where explicit approval should have been a hard requirement.

Why it matters operationally

Tool safety boundaries are a core contract in multi-agent systems because tool calls are where external side effects occur. If high-risk tools run without explicit confirmation policy, incident response and audit trails lose reliability. This is a repeated friction point in production rollout reviews: teams need deterministic, fail-closed behavior so missing policy is treated as an error, not a permissive default.

Minimal repro

uv run pytest tests/unittests/tools/test_function_tool.py -k high_risk_without_confirmation_policy
uv run pytest tests/unittests/tools/mcp_tool/test_mcp_tool.py -k high_risk_without_confirmation_policy
python - <<'PY'
print('configure high-risk tool without require_confirmation')
PY

Fix approach

The change adds is_high_risk signaling to FunctionTool and MCP tools, propagates it through MCP toolset creation, and enforces a fail-closed guard before tool execution. If a high-risk tool resolves to a non-confirmed policy, execution returns a deterministic error and does not proceed. The patch intentionally keeps scope narrow: no broad lifecycle changes, only explicit gating at tool execution contracts.

Validation evidence

• uv run pyink --check --diff ... passed for all changed files.
• Focused unit tests for function and MCP tool high-risk fail-closed behavior passed.
• Regression subset around existing require_confirmation paths passed.

Open follow-up question for maintainers

Should we standardize a dedicated high-risk error type/code for downstream programmatic handling in agent orchestration logs?

This contribution was informed by patterns from Wrkr. Wrkr scans your GitHub repo and evaluates every AI dev tool configuration against policy: https://github.com/Clyra-AI/wrkr