Tool Use & Security

What's Shocking

• TypeScript erases types at runtime -- that is why AgentTool objects exist. A plain function has no inspectable parameter names, types, or descriptions. The LLM API needs a JSON schema for each tool. Schema co-location is the real reason for tool wrappers.
• smolagents skips tool schemas entirely -- the LLM writes Python instead of JSON tool calls. One code block does what three JSON round-trips need. The training data IS the API.
• Stripe cuts the network, not the filesystem. The agent can rm -rf / inside its devbox -- it just cannot exfiltrate data. This inverts the Claude Code model (sandbox filesystem, allow network) and makes one-shot execution safe by construction.
• More code does not mean more security. OpenClaw (430k+ lines) has Docker sandboxing but defaults to only sandboxing subagents. NanoClaw (~24 files) sandboxes everything by default.
• The secret boundary problem is unsolved — but has a design. If the LLM SDK runs on the host (OpenClaw, Muaddib), secrets never cross into the sandbox — but host-side tools bypass the sandbox. If the SDK runs inside the sandbox (NanoClaw), secrets must cross in — five layers of protection, but the key IS in process memory. The component model solves this: the tap (tool middleware proxy) injects API keys on outbound calls. Secret never enters the box. SDK runs inside. Both properties.

See also: Patterns That Work | Systems Compared | Claude Code Internals | Kanipi (tap: credential injection in practice)

Theme: Tool architecture maps to the tap component. NanoClaw's tools look local but route through a transparent IPC proxy bus to the host — the pattern the tap component extracts. Muaddib's host/guest tool split is the cleanest privilege model: credentials physically cannot enter the VM. smolagents' code-first approach eliminates schemas entirely. Where you draw the tool boundary determines whether you can serve untrusted users.