Everyone's buzzing about LangGraph's pre-built 'tool node' because it's convenient. But wrapping an external API call in a decorator doesn't magically solve the hard problems. You're just outsourcing your security headaches.

The real risk isn't the node itself—it's the illusion of safety. You get a clean abstraction, but you're still piping raw, often unsanitized, LLM output directly to an external service. The node handles the *mechanics*, not the *security*.

Think about it:
* **Input Injection:** The prompt crafts a payload, the node obediently sends it to your CRM/email/DB API. No inherent validation.
* **Credential Leakage:** The node needs API keys. Where do they live? In the graph's state? Injected at runtime? How are they scoped?
* **Tool Choice Abuse:** The LLM decides which tool to call. What stops a malformed response from calling `delete_user` instead of `get_weather`? The node doesn't care.

It's a classic case of a framework solving the developer experience problem while quietly inheriting all the underlying protocol and API risks. You've traded writing a few lines of HTTP client code for a false sense of a "managed" interaction.

So, what's the actual threat model here? Is it the node's code, or is it that using it encourages lazy, trust-based integration patterns that we'd rip apart in any other RPC or service mesh context?