What I ran into

While using the HTTP source/tool for a third-party API, I noticed full upstream error bodies were being returned back through toolbox responses. In my case this included detailed provider diagnostics that I would not want exposed to model output or downstream clients.

From code reading, this appears to come from:

• internal/sources/http/http.go
  • on non-2xx, returns:
    • fmt.Errorf("unexpected status code: %d, response body: %s", ...)
• error then flows through generic handling and often ends up returned as an agent-visible error string.

Why this matters

If upstream error payloads contain sensitive details (internal IDs, stack traces, request metadata, token hints, etc.), toolbox currently reflects that content back to callers.

This creates a data-leak path from upstream services into agent/client-visible outputs.

Expected

For non-2xx upstream responses, toolbox should return a sanitized error message to callers and avoid reflecting raw response body content.

Suggested fix

• Do not include raw upstream response body in returned errors.
• Return a normalized/sanitized message (status code + brief reason).
• Optionally log a redacted/truncated body only at debug level.
• Add tests verifying non-2xx responses do not leak body content in client-visible errors.

I can open a PR with a minimal patch if maintainers agree with this direction.