So the official line is that LangSmith is "just" for debugging, and you can turn it off in production. Fine. But have you actually looked at what gets shipped when you `pip install langgraph`? The default telemetry is baked into the runtime, and "opting out" requires you to find the right, poorly-documented environment variable *and* hope your deployment actually respects it.

I’m building a state graph that handles customer PII and internal API keys. The checkpointing system is writing my graph’s state to an external store. LangSmith, by default, wants to phone home with trace data. Even if they anonymize it (big if), the structure of the data is a blueprint of my entire agent’s logic and tool use patterns. That’s a goldmine for anyone who knows how to look.

Their docs make it sound trivial:

```bash
LANGSMITH_TRACING=false
LANGSMITH_API_KEY=""
```

But then you have to wonder: does the SDK respect this at every layer, or is there some eager initialization that fires off before your env loads? Have you audited the network calls? I had to wrap the module in a firewall rule to be sure.

This isn't just about data exfiltration. It's about attack surface. Every external endpoint your library calls is a potential leak vector. If LangSmith's API gets popped, does my trace data, which might contain sanitized-but-inferable state, become part of a breach? Why should my prod runtime even have that handshake logic?

Am I paranoid, or is everyone else just blindly accepting that their orchestration framework needs to call home by default?