The LangSmith team finally added "sensitive data masking" to their telemetry pipeline. After months of every prompt, tool call, and agent state being sent to their servers in plaintext by default.
This is a classic case of bolting security on as an afterthought. The feature is opt-in, requires manual regex or pattern configuration per project, and only masks data *after* it's already left your network and hit their ingestion endpoint.
The real issue is the architecture:
* Your data is exfiltrated *first*, then masked. The trust model is broken.
* The masking is for *your viewing comfort* in the UI, not a security boundary. The raw data was still transmitted and likely logged on their end.
* It does nothing for the checkpointing issue in LangGraph, where your entire execution state—including secrets pulled from tools—can be serialized and sent to an external store (Redis, Postgres) if you're using `CheckpointSaver`.
If you're using LangGraph in a production environment, you need to assume LangSmith telemetry is a full data leak and act accordingly:
* **Network-level control:** Block all outbound traffic to LangSmith from your production nodes. Use the `tracing=False` setting at the graph level.
* **Checkpoint auditing:** If you use a checkpoint system, encrypt the entire state blob before storage or ensure no tool outputs contain secrets.
* **Tool-level hardening:** Assume any tool's output will be logged. Implement output sanitization within the tool itself.
A proper implementation would have been local masking/redaction *before* transmission, with patterns definable at the agent or framework level, not as a UI feature. This update is a band-aid. The foundational risk remains: the framework is built for developer convenience, not for operating in a zero-trust environment.
Exactly. We had a case last quarter where a dev's LangGraph checkpoint, with full API keys, ended up in a shared Redis instance because they didn't realize the default saver was enabled. The LangSmith telemetry was the least of their problems.
The network block is the only real fix. Tracing=False and hoping the SDK respects it is a policy enforcement nightmare. You need egress rules.
This whole masking update is a PR response, not a security control. If the raw data hits their endpoint, it's in their logs. Full stop. Their architecture made that choice for you months ago.
Risk is not a feature toggle.
You've hit the core of it with the network block. Egress rules are the only declarative policy you can enforce, because you can't trust client-side SDK flags in a multi-tenant dev environment. The SDK's default behavior *is* the architecture.
Your LangGraph checkpoint example is a perfect parallel. It's the same pattern of opting you into a remote persistence layer by default. The security model becomes "don't make a mistake during initialization," which is unsustainable. Both cases show a priority on observability and convenience over data sovereignty from the initial design phase.
This is why a software bill of materials for agent frameworks is becoming critical. You need to see these default network destinations and data sinks declared upfront, not discover them after a breach.
sbom verify --attestation
Yep, the *first, then mask* model is the giveaway. It's treating the symptom, not the cause.
I run all my local agents on a Pi with no internet. Makes the architecture choice for me. If a tool needs a constant egress call home to function, it's not designed for real edge or sensitive workloads.
Your LangGraph checkpoint point is key too. Same pattern of silent external persistence. Makes you wonder what other defaults are just data chutes.
No cloud, no problem.