Should teams use LangChain, LangGraph, and LangSmith together or separately?

Why This Matters for Security Teams

Teams often treat LangChain, LangGraph, and LangSmith as separate developer choices, but the operational risk changes once a workflow can branch, retain state, retrieve context, or invoke tools with real-world impact. At that point, security teams need to understand not just the library stack, but how decisions, prompts, traces, and approvals are governed across the full execution path. The most common mistake is assuming observability alone creates control.

That distinction matters because agentic systems can fail in ways that look like normal application errors but actually reflect unsafe autonomy, weak authorization boundaries, or unreviewed tool use. Guidance from the NIST Cybersecurity Framework 2.0 is useful here: identify the system, protect the control plane, detect abnormal behaviour, and ensure response actions are defined before the agent is allowed to act. In practice, many security teams encounter the governance gap only after an agent has already made a business-impacting call rather than through intentional design.

How It Works in Practice

LangChain is typically the orchestration layer for chaining model calls, tools, retrievers, and application logic. LangGraph adds explicit state, branching, and longer-running workflows, which makes it more suitable when execution is not linear and when the system needs checkpoints or conditional paths. LangSmith is the evaluation and tracing layer, giving teams visibility into prompts, runs, latency, failures, and test outcomes. Used together, they can form a coherent AI application stack, but they do not automatically create security controls.

For security and governance, the practical question is whether the stack is deployed as a simple assistant, a workflow engine, or an agentic system with tool authority. Once tools can write data, trigger tickets, query internal systems, or move money or content, the stack should be treated as one controlled service with defined ownership. That means:

• boundaries for who can change prompts, tools, and routing logic
• logging that preserves input, output, state changes, and tool calls
• approval gates for high-impact actions
• evaluation suites that test prompt injection, unsafe tool use, and refusal behaviour
• separation between development telemetry and production evidence

From a governance perspective, the OWASP Top 10 for LLM Applications is a strong reference point for injection, insecure output handling, and excessive agency, while MITRE ATLAS helps teams think about adversarial manipulation of model-driven systems. Current guidance suggests the safest pattern is not “choose one framework,” but define whether the system is composable, stateful, and auditable enough to justify the added control surface. These controls tend to break down when teams let developers assemble live tool chains without a single owner for state, permissions, and release approval.

Common Variations and Edge Cases

Tighter governance often increases delivery friction, requiring organisations to balance speed of iteration against the cost of review, testing, and traceability. That tradeoff is especially visible when teams want the agility of LangChain but also the branching control of LangGraph and the telemetry of LangSmith.

There is no universal standard for this yet, so best practice is evolving. Smaller assistants that only generate text may not need the full stack, and forcing LangGraph into a linear workflow can add unnecessary complexity. Conversely, once a system persists state or invokes sensitive tools, separating the frameworks purely by developer preference becomes risky because accountability fragments across code, workflow, and monitoring. In those cases, security teams should define one operational control boundary, even if the codebase uses all three components.

LangSmith is also often misunderstood as a governance control when it is really an observability and testing capability. It supports evidence collection, but it does not replace access control, change management, or human approval. For organisations aligning to NIST Cybersecurity Framework 2.0, the practical move is to attach the stack to clear asset ownership, risk decisions, and incident response paths. If the system must operate across regulated or high-impact functions, teams should assume the combined stack is a single security object, not three independent product decisions.

Related resources from NHI Mgmt Group

• How do IAM and PAM teams use AD intelligence together?
• How should security teams use SCIM and SAML together in IAM programmes?
• How should security teams use audits and penetration tests together?
• How should IAM teams use ISO 27001 and ISO 27002 together?