ROADMAP-05 — P0 — http_fetch: LLM-controlled timeout/max_chars unclamped; binary content-types decoded #97

Series: ROADMAP — filed from the 2026-10-27 whole-project assessment · Backlog task: M14-T05 · Priority: P0 · Effort: small

Problem

http_fetch's SSRF defense is strong (per-hop revalidation, post-connect peer check), but the resource knobs are not:

1. timeout_s and max_chars are LLM-controlled arguments with no clamp — a negative timeout_s throws; a huge max_chars up-shifts the memory budget toward the 8 MB ceiling per call, per step.
2. Content type is ignored entirely — an application/octet-stream/binary body is decoded UTF-8 with errors="replace" and fed to the LLM as prompt content.
3. No per-host/egress rate limiting exists (only the global API limiter bounds requests).

Evidence

• agentkit/tools/builtin/http_fetch.py:172–175 — unclamped timeout_s / max_chars
• agentkit/tools/builtin/http_fetch.py:214 — unconditional UTF-8 decode
• Contrast: web_search clamps its max_results analog already

Suggested fix / acceptance criteria

• timeout_s and max_chars clamped to configured bounds regardless of the model-supplied values
• Non-text content types rejected (or length-capped) before any decode
• Regression tests for negative/huge arguments and a binary content type
• (Optional, separate PR acceptable) simple per-provider egress limiter

Suggested branch / commit

fix/http-fetch-clamps-content-type · fix(tools): clamp http_fetch resource knobs and gate binary content types