confirmation: fail closed on malformed tool-confirmation responses

[davidahmann]

Problem
Malformed tool-confirmation payloads can traverse edge parsing paths that are treated as implicit allow instead of hard deny. This weakens confirmation as a safety control.

Why now
Tool confirmation is a core policy boundary for sensitive tool execution. Any permissive fallback on malformed responses creates avoidable safety risk.

Evidence packet

• commit under test: 223d9a7
• runtime environment: macOS 26.3; Python 3.14.0
• minimal repro:
  1. Return malformed confirmation payload (wrong shape/type or missing required allow/deny signal).
  2. Invoke tool flow requiring confirmation.
  3. Observe execution decision.
• expected: malformed payload always blocks execution with explicit denial reason.
• actual: some malformed cases can be interpreted permissively.

Why current behavior is insufficient
Safety controls must fail closed. Parsing ambiguity that defaults to allow violates expected tool execution boundaries.

Acceptance criteria

• Confirmation parser rejects malformed payloads with explicit reason classification.
• Tool execution is blocked for all malformed confirmation responses.
• Unit tests in runner/tool-confirmation paths lock fail-closed behavior.

[surajksharma07]

@davidahmann The parser at request_confirmation.py:83-89 calls ToolConfirmation.model_validate() without strict=True, so Pydantic's lax coercion silently turns {'confirmed': 'yes'} into confirmed=True — a malformed string payload gets treated as an explicit allow.

Fix is two lines: pass strict=True to both model_validate() calls, and wrap the whole block (including json.loads) in try/except that catches JSONDecodeError, ValidationError, and any other exception, returning ToolConfirmation(confirmed=False) as the hard-deny fallback.

PR #4577 addresses this — reviewed and looks correct.

Team is looking more into it.