How to Monitor LangGraph Agents in Production for SR 26-2 Ongoing Monitoring

What ongoing monitoring has to demonstrate

Ongoing monitoring for a deployed agent has to answer two questions a reviewer will ask: what was the agent permitted to do, and what did it actually do. Trace review alone answers only the second, and only after the fact. NIST AI 800-4 explains why that is not enough on its own: post-deployment monitoring is needed to validate real-world operation and to catch unforeseen outputs caused by model non-determinism or dynamic input conditions. It also notes that monitoring best practices and terminology are still nascent, so many design choices will be yours to make and document.

LangGraph makes the problem concrete. A graph carries state across nodes, branches along edges, calls tools, and can pause at human-in-the-loop interrupts. Two runs with the same input can take different paths. Monitoring therefore has to be attached to the structure of the graph, not just to the final response.

This guide is an engineering mapping. The NIST AI RMF offers supporting reference points, namely GOVERN 1.5 on ongoing monitoring and periodic review, and MANAGE 4.1 on post-deployment monitoring plans. Your model risk function decides how each signal and record is documented against SR 26-2.

Choosing signals, thresholds and escalation paths

NIST AI 800-4 describes categories such as functionality monitoring (does the system continue to work as intended) and operational monitoring (does it maintain consistent service across its infrastructure). Agent-specific sources add drift, unexpected tool use, permission use and approval or escalation events. For a LangGraph agent this gives five practical groups: output quality and drift, tool-call behavior, policy violations, escalation rates, and latency and failure modes.

NIST guidance on agent identity says thresholds and metrics should be agent-specific, and that risk grows with long-running or persistent agents and agents that act across many tools. Define the thresholds before go-live, record who set them and why. Typical examples are a rise in blocked tool calls, a tool invoked outside its usual pattern, an escalation rate moving away from baseline, or repeated node failures on one branch.

Each threshold needs an owner. The same NIST material says organizations define the risk thresholds that initiate human review of agentic actions, and that technology components should be able to trigger escalation to the correct authority. Write the routing down: which breach goes to platform on-call, which to the application owner, which to model risk.

Two decisions remain open in NIST's own framing: monitoring cadence, and the balance between automated and human-validated monitoring. Make both explicit, with rationale. Also size the observation window for drift. NIST notes that longitudinal tracking of agents may need extra logging and a longer window to expose degradation that is not immediately obvious.

Separating observation from runtime policy enforcement

Observation is telemetry about what happened. Enforcement is a decision made before an action completes. NIST treats per-invocation runtime verification of tool calls, API calls and resource accesses, based on current state, context and risk, as distinct from monitoring and detection. A NIST-hosted agentic security presentation puts the monitoring side bluntly: do not run agents without telemetry. Both layers are needed, and neither replaces the other.

In practice, telemetry tells you a tool was used unexpectedly. Enforcement determines whether that call was allowed to run. For a model risk reviewer, the second is stronger evidence, because it shows the control operated at the moment of the action and not only that someone noticed later.

Trussed is one way to implement the enforcement layer. It enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. The available decisions are allow, redact, block, rate limit, and escalate for human approval. Because enforcement happens at runtime, not after the fact, each decision produces audit-ready evidence of what the agent was permitted to do and what it did. Trussed does not provide end-to-end tracing of agentic workflows or model lineage, so graph-level observability, evaluation of output quality and drift analysis still need other tooling.

Retaining evidence for model risk and audit review

Evidence has to outlive the run and be readable by someone who did not build the agent. NCCoE discussion material, which is community input and not final guidance, lists the relevant controls: preserving audit records of workflow context, tool usage and approval events in a tamper-resistant manner where appropriate, along with retention and deletion controls and detection and redaction of sensitive data.

For platform teams this translates into a few decisions. Decide the retention period for each record type and who approves it. Decide where records live, since data residency is a separate decision from retention. Decide reviewer access, so model risk and internal audit can query records without engineering assistance. Where agent components run on separate infrastructure, plan for log aggregation early, because NIST flags capture and aggregation across logically separated components as difficult.

Trussed supports this with self-managed deployment in the customer cloud, with configurable retention and data residency. Its evidence is generated continuously by enforcement and mapped to frameworks including NIST. In one regulated enterprise it has run in continuous production for more than 18 months at 99.95% uptime on live traffic, generating over 30 GB of audit evidence per day.