Treat the stack as three different control layers. Use the framework layer for composition, the graph layer for stateful execution, and the observability layer for investigation, but enforce authorisation separately from tracing. If tool access is not scoped before execution, better orchestration only makes misuse easier to perform and harder to contain.
Three control layers, three different jobs
Teams should govern LangChain, LangGraph and LangSmith as separate layers rather than as one blended platform. LangChain is the composition layer for assembling model calls, tools and prompts; LangGraph is the execution layer for stateful workflows and branching; LangSmith is the investigation layer for traces, evaluation and debugging. That split matters because the right control for orchestration is not automatically the right control for access.
Start by defining which decisions belong to code composition, which belong to runtime execution, and which belong to post hoc inspection. A graph can show you how an agent moved through a task, but it should not be the place where tool rights are casually implied. If you do not separate those responsibilities, observability can create confidence while leaving the actual permissions model untouched.
Governance is strongest when each layer has its own owner, policy surface and review cadence. Composition changes should be reviewed for allowed tool patterns, graph changes for execution paths and escalation points, and observability changes for what is logged, retained and searchable. That gives teams a clean way to approve capability growth without turning every new chain or node into an implicit privilege increase.
Why authorisation must sit outside tracing
Authorisation needs to be enforced before a tool is executed, not inferred from the fact that the agent can be traced afterward. LangSmith can help investigate what happened, but tracing is not a substitute for access control, and a good trace does not make an unsafe action safe. The governance rule is simple: if an agent is not allowed to call a tool, no amount of observability should make that call acceptable.
This is especially important when teams use the same agent across multiple workflows with different data sensitivity or blast radius. A graph that is safe for summarisation may be unsafe for ticket mutation, and a chain that is safe in a test tenant may be risky in production. The control point therefore has to be the decision to invoke a tool, not the later ability to explain that the tool was invoked.
Scoped delegation, short-lived credentials and per-action policy checks are the practical controls that keep execution bounded. AI Agent Authorisation Guide is useful here because it frames least privilege as task-scoped, action-scoped and approval-aware rather than as a blanket agent entitlement. That is the right mental model for agents that can chain several tools in one run.
How to govern agent stacks across build, run and review
In practice, teams need a control model that follows the agent lifecycle. The build layer should define which tools, prompts and workflows are even eligible to ship; the run layer should decide whether a specific action is allowed at runtime; the review layer should record what happened, why it happened and whether the outcome was acceptable. If any one of those layers is missing, the stack becomes either too brittle to operate or too permissive to trust.
LangGraph deserves particular attention because stateful execution creates hidden persistence, retries and branching decisions that can expand impact if they are not designed carefully. The more state an agent carries forward, the more important it becomes to know when a branch can write, call, persist or escalate. Governance should therefore treat graph design as a security-relevant architecture decision, not just an application convenience.
That is also where identity and delegation become material. For agentic systems, Agentic AI Identity Guide helps teams think about registration, delegation and retirement as lifecycle controls, while Zero Trust for AI Agents reinforces the idea that each request should be evaluated on context, principal and action, not on the assumption that the agent remains trustworthy because it started trusted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent governance here depends on preventing unchecked agent privileges and tool access. |
| Recommendation — Enforce per-action authorization and least privilege before any agent tool call. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agent tool use and service-to-service calls need authenticated machine interactions. |
| AC-6 — Least Privilege | Agents should only receive the minimum tool permissions needed for each task. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | LangSmith-style traces support investigation, review and incident analysis. | |
| Recommendation — Require authenticated service-to-service access for agent actions and tool invocation. Scope agent permissions to the minimum tool set needed for the current task. Review agent telemetry and traces to detect misuse and validate action paths. | ||
| NIST Zero Trust (SP 800-207) | 3.4 — Policy Decision Point and Policy Enforcement Point | The answer centers on separating request decisions from execution and tracing. |
| Recommendation — Place authorization decisions at a policy point separate from execution and logging. | ||
Practitioner Guidance
What to prioritise: Put runtime tool authorisation ahead of tracing maturity. If the agent can already reach a sensitive tool, the most important question is whether it should, not how well you can reconstruct the event afterward.
What to verify: Check that every tool call has an explicit policy decision point, a bounded credential or delegation path, and a clear owner for approval exceptions. If you cannot show those three things, the agent is effectively operating with implied privilege.
Common mistake: Teams often instrument LangSmith first because it improves visibility, then assume visibility equals control. That reverses the governance order, and it usually leaves the highest-risk part, tool execution, under-specified.
What good looks like: A well-governed stack can explain which layer changed, who approved it, which tools were in scope and which actions were blocked. The observable state is that better orchestration increases efficiency without increasing the set of actions the agent can perform unreviewed.
Practitioner takeaway: Treat orchestration, execution and investigation as distinct control planes, and never let observability become the substitute for authorisation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org