How to Document AI Agent Tool Limitations for Model Risk Review Under the Revised Guidance

What the revised guidance changes, and what it leaves to you

The OCC issued Bulletin 2026-13, Model Risk Management: Revised Guidance, on April 17, 2026, alongside the Federal Reserve's SR 26-2. It covers model development and use, validation and monitoring, governance and controls, and vendor and third-party products. It states that its principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. It describes generative and agentic AI as novel and rapidly evolving, and says a banking organization's own risk management and governance practices should guide controls for tools, processes or systems the document does not cover. As of November 2026, that means there is no prescribed template for documenting the tools an agent calls.

Several principles still transfer directly. Validation evaluates whether a model performs as expected, including its limitations, and those limitations inform controls such as limits on use or closer monitoring. When use extends beyond the original application, sound practice calls for additional analysis of the new usage and a review of existing controls. Adding a tool to an agent is that kind of extension. The earlier SR 11-7 guidance adds background that remains useful: an inventory of models in use, documentation of issues and their resolution, tracking of known and new limitations after deployment, and analysis of overrides with documentation.

The guidance also notes that practices suited to one institution may be ineffective for another with a different risk profile or model purpose. Whatever record structure you adopt, write down the rationale and the risk-based scope so a validator can see why it fits your agents.

Why tool limitations are a separate artifact

Model documentation describes what the model was built to do and where it is weak. An agent's behavior also depends on what it can reach: an API, a database, a search function, a code interpreter or an MCP server. Two agents running the same model can carry very different risk because their tools differ. A model limitation such as a tendency to produce plausible but wrong text is a different kind of statement from a tool limitation such as this connector can read two tables and cannot write to either.

Tool limitations also behave differently under test. They can often be stated precisely, checked against configuration, and evidenced call by call. Treating them as their own artifact lets validators challenge them directly and lets monitoring teams track changes without reopening the whole model file.

Fields for the tool limitation record

No regulator mandates these fields. They are derived from the limitation-documentation expectations in the revised guidance and in NIST AI RMF and the NIST generative AI profile, together with the least-privilege pattern in OWASP's guidance on excessive agency. Keep the tool inventory alongside the model inventory and give each entry the following.

• Purpose, owner and version: The business function the tool serves, the accountable owner, and the version or configuration under review. Adding a tool or changing its permissions triggers re-review.
• Permitted and prohibited actions: Operation-level statements. OWASP's example is an agent that needs only read access to a products table and should not insert, update or delete records or reach other tables.
• Data scope: Named tables, fields, repositories or endpoints, expressed as least-privilege access rather than a general statement about the system.
• Input and output constraints: Accepted parameters, size limits, rate limits, and what must be removed or masked before returned content reaches the agent or a user.
• Known failure modes: Including tool output as an input channel: implicit trust in retrieved content, unsanitized payloads, and autonomous action without confirmation.
• Enforcement and approval: For each limit, the enforcing control, whether human approval applies before high-impact actions, and the evidence the control produces.

Documented limits versus limits enforced at runtime

Validators need to know which statements in the record are tested facts about the execution path and which are intentions. Mark every limit as one or the other. A documented-only limit is not worthless, but it relies on the agent, the prompt or a person behaving as described, and the record should say so. The examples below show how different limits typically fall.

• Read-only access to named tables: Can be enforced on each call by blocking write operations and out-of-scope tables. Evidence: a decision record for each allowed or blocked call.
• Sensitive fields in tool responses: Can be enforced by redacting before content reaches the agent or user. Evidence: a record that redaction applied to that call.
• High-impact actions: Can be enforced by escalating for human approval before execution. Evidence: the request, the approver and the outcome.
• Call volume: Can be enforced with rate limits per tool. Evidence: records of throttled calls.
• Instruction-like content in tool output: Sanitization is a control with its own limits. Document what it catches and what it does not, and test it.
• Which tool the agent selects: Selection is non-deterministic and is best documented as a behavior. Enforce what any selected tool may do, rather than relying on predicting the choice.

Mapping the record to documentation, validation and monitoring

For documentation, the record supports the expectation of an inventory, a statement of limitations and a trail of issues and resolutions. NIST AI RMF MAP 2.2 calls for documenting knowledge limits and how output may be used and overseen by humans. MEASURE 2.1 calls for documenting the tools used in testing and evaluation and the limits of generalizability. The NIST generative AI profile adds regular review of security and safety controls in novel operating circumstances.

For validation, effective challenge means comparing the documented limit with observed behavior. A validator can attempt an out-of-scope call, review the decision records for it, and check whether the outcome matches the record. Because tool output can carry instructions, testing should include returned content from web pages, files, APIs and databases, not only the agent's prompts.

For ongoing monitoring, track blocked and escalated calls, human approvals and overrides, and any new limitations that surface. Define in advance what triggers re-review: a new tool, a changed permission, a new data source or a changed enforcement rule. Retain override and approval records so override analysis can be documented.

Where runtime enforcement fits

Documentation alone leaves a gap between what the record says and what the agent does. Closing it requires policy enforcement in the execution path, applied to individual interactions and tool calls, so that each limit in the record corresponds to a control that acts when the agent runs. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, using allow, redact, block, rate limit and escalate for human approval. That enforcement generates audit-ready evidence mapped to frameworks including NIST and NYDFS.

Trussed is deepest in insurance, a regulated financial sector, and runs under one policy plane across 100+ models. Its scope is policy enforcement and evidence at the level of individual interactions and tool calls. It does not provide end-to-end tracing of agentic workflows or model lineage, so those questions need other records. Whatever tooling you use, the test is the same: can you show a validator, for a specific call, what was allowed and what happened?