How to Prove a LangGraph Agent Stayed Within Its Approved Use Case After OCC Bulletin 2026-13

What the current supervisory position means for evidence design

Many teams plan agent evidence around SR 11-7. That framing needs adjusting. OCC Bulletin 2026-13, issued on April 17, 2026 as revised model risk management guidance, covers model development and use, validation and monitoring, governance and controls, and vendor and third-party products. It also states that generative AI and agentic AI models are novel and rapidly evolving and are therefore not within the scope of the guidance.

The bulletin does not set out how examiners will treat agents, and it does not say how it relates to SR 11-7 for institutions supervised by the Federal Reserve. Do not assume SR 11-7 applies to agents as a requirement.

SR 11-7 concepts still make a useful reference frame. Validation reports include a statement of model purpose and a synopsis of limitations and key assumptions. Ongoing monitoring and outcomes analysis are core elements of effective validation. Applying these to an agent is an analogy, and the practical consequence is that your evidence should be strong enough to stand on its own. The OCC also says practices should fit an organization's risk profile and the purpose of the model, so scope boundaries and evidence depth should be risk-based.

Why a scope document does not prove adherence

A LangGraph agent routes between graph nodes and, in many designs, decides which tool to call from the prompt or from earlier model output. That is the pattern OWASP describes under excessive agency: the choice of extension is delegated to the agent and determined dynamically. A document that says the agent may look up policy records and draft summaries describes intent. It does not constrain a tool call made at runtime, and it does not record what happened.

A reviewer therefore needs two things the document cannot supply. The first is evidence of what the agent was permitted to do at the moment of each call. The second is evidence of what it actually attempted, including attempts that were stopped. Application logs usually capture the second only partially, and they rarely tie a call to the specific scope rule that governed it.

Translate the approved use case into enforceable boundaries

Treat the use case as a specification you can test. Each statement in the validation document should become a rule that a policy engine can evaluate against a proposed tool call. Least privilege is the organizing principle: give each agent instance only the tools its task requires, and narrow scope within a tool where possible, such as read-only access to a single table instead of insert, update or delete rights.

Write rules against the operation, the target, the arguments and the caller's authority, not against keywords in the user prompt. Content from outside the trusted system prompt should be treated as untrusted when deciding whether an action is in scope.

• Permitted tools: An explicit allow list per agent instance. Anything not listed is denied.
• Data targets: Named datasets, tables or endpoints, with access mode such as read-only.
• Action types: Which operations are permitted, and which are irreversible or high impact.
• Escalation conditions: Risk thresholds that route a call to a named human approver instead of executing it.
• Redaction requirements: Fields that must be removed from arguments or responses before they cross a boundary.
• Scope version: An identifier so every decision can be tied to the policy in force at validation or after a reviewed change.

Where enforcement belongs in a LangGraph agent

Agent-level input and output checks have limited coverage. Validation should sit next to the tool that creates the side effect. In a graph-based agent, many nodes and routing paths can lead to the same tool, so the tool or API boundary is the most reliable point: each proposed call is evaluated before it executes, regardless of which path produced it. OWASP names LangGraph among the frameworks where policy enforcement hooks can intercept tool calls and API actions at execution time.

The outcomes at that boundary should be explicit. Allow the call if it matches a rule. Redact fields that should not leave the boundary. Block the call if it falls outside scope. Escalate high-impact actions for human approval, holding the pending action until a decision is made. Where an approval is required, the approver and the decision belong in the record.

Trussed enforces policy in the execution path across agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval, scoped to individual interactions and tool calls. The evidence it produces comes from that enforcement, not from reconstruction. It does not provide end-to-end tracing of agentic workflows, so a reviewer who needs the full path through the graph will need another source for it.

Enforcement evidence compared with reconstructed logs

The difference is not volume. It is whether the record shows a decision made before the action, under a known rule, or an inference made afterward. The table assumes a well-designed evidence record; the fields are reasoned from least-privilege and approval practice, not prescribed by any regulation.

• Link to scope: Application logs: the call is recorded, the governing rule is inferred later. Enforcement evidence: the matched rule and policy version are recorded with the call.
• Out-of-scope attempts: Application logs: found only if someone reviews and recognizes them. Enforcement evidence: blocked or escalated attempts are recorded as decisions.
• Timing: Application logs: show what happened. Enforcement evidence: shows the decision made before the side effect.
• Approvals: Application logs: approvals often live in a separate system. Enforcement evidence: the approver and outcome are kept with the held action.
• Sensitive data: Application logs: may store raw arguments. Enforcement evidence: records what was redacted and what was passed on.
• Reviewer access: Application logs: need engineering help to interpret. Enforcement evidence: structured so a reviewer can inspect it independently.

Failure modes enforcement addresses, and those it does not

Tool-level enforcement addresses several routes out of scope. Prompt injection, including indirect injection through untrusted content, is hard to catch with pattern-based filters, but a tool call it triggers can still be judged against the original user intent and its arguments. Over-permissioned tools are limited by the allow list and by narrow access modes. Unapproved data access is stopped when targets are named in rules. Scope creep after validation shows up as a change to the scope version, which can be reviewed as a change to the approved scope with an accountable owner.

Enforcement has limits. It does not assess the quality of what an agent does inside permitted actions, and it does not replace red-teaming before deployment or ongoing monitoring of outcomes. It also depends on rules being specific enough to test. A vague rule produces a clear record of a vague decision.