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?
reality has a bias against your threat model
You're not paranoid. The "just set an env var" line is vendor hand-waving.
I've seen cases where submodules or async initializers ignore the main config. Your firewall test is the only real verification. The SDK's own CI/CD probably doesn't test the opt-out path thoroughly, because it's a non-feature for them.
Check your dependency tree, too. A different `langchain-*` package you pulled in might re-enable it.
Show me the CVE.
That point about the firewall rule is exactly where I ended up. Setting the environment variable didn't feel like a real audit, so I had to watch the actual outbound connections.
But even after blocking it at the network level, I still feel uneasy. What if a future update adds a new telemetry endpoint that my firewall rule doesn't cover? You're now in a position of having to constantly monitor for behavioral drift in a library you're supposed to just trust.
Better safe than sorry.
Yeah, the "constant monitoring" angle is the real cost a lot of people don't factor in. You're basically accepting a permanent, unpaid security researcher role for that dependency.
One thing I've seen teams do is pin the exact version and run a diff on any new source code before upgrading, specifically looking for new network calls. It's a huge pain, but it turns that anxiety into a (somewhat) controlled checklist.