AI Agent Tiering by Tool Authority Under the 2026 Model Risk Guidance

What changed in model risk guidance, and what it leaves open

On April 17, 2026, the OCC, the Federal Reserve Board and the FDIC issued revised interagency model risk management guidance (OCC Bulletin 2026-13, SR 26-2). It rescinds prior model risk management guidance and keeps a risk-based approach. SR 26-2 describes itself as an update in light of experience since SR 11-7, so any internal policy that cites SR 11-7 as the current reference should be reviewed. The guidance says practices should be risk-based, tailored, and commensurate with a bank's size, complexity, and extent of model use. It also says practices suitable for one bank may be inappropriate for another with a different risk profile or model purpose.

A footnote calls generative and agentic AI models novel and rapidly evolving. The stated principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. For tools, processes or systems the document does not cover, a bank's own risk management and governance practices should guide controls. The agencies plan to issue a request for information on model risk management that considers AI, including generative and agentic AI. Separately, OCC Bulletin 2026-54, dated November 4, 2026, emphasizes that control intensity could increase with the potential consequences of an agent's failure or misuse. All of this is current as of November 2026.

Taken together, the guidance leaves each bank to document its own tailored approach for agents. Consequence is the axis the OCC bulletin points to, and consequence for an agent is determined mainly by its tools. A complexity-based tier rates the model. It says little about whether the agent can update a customer record, send a message to a customer, or initiate a payment. NIST AI 600-1 notes that organizations may apply existing risk tiering to generative AI systems or revise risk levels to address them. Keeping the existing tiers and adding tool authority as a further axis fits that approach.

Defining the tiers

Assign the tier to the tool, not the agent. Each tool an agent can call gets a tier based on the most consequential action it permits. An agent's tier is then the highest tier among the tools it can reach. This keeps the unit of classification aligned with the unit of enforcement, which is the tool call.

The four tiers below are a proposed starting point. Banks will adjust the boundaries to their own products and risk appetite.

Three modifiers raise or lower the control set within a tier. Data sensitivity matters because a read tool over customer identifiers is not equivalent to one over public policy documents. Autonomy matters because an action taken with no human in the loop warrants stronger controls than the same action drafted for review. Model attributes, including type, size and complexity, remain relevant for validation depth and monitoring, but they do not set the tier. A simple model holding a Tier 4 tool is a Tier 4 agent.

• Tier 1: Read: Retrieval and summarization over internal or external data. No state changes. Sensitivity of the data drives the controls.
• Tier 2: Reversible write: Creates or modifies records where changes can be reviewed and undone, such as draft case notes or internal tickets.
• Tier 3: External communication: Sends content outside the bank, such as customer emails or messages to third parties. Disclosure cannot be recalled.
• Tier 4: Irreversible or value-moving: Moves funds, changes system-of-record customer data, or takes actions that cannot be reliably reversed.

Mapping tiers to enforcement on each tool call

A tier is only useful if it changes what happens at execution time. NIST design tenets for agent identity place continuous verification on individual tool invocations, API calls and resource accesses, based on current state, context and risk profile. That makes the tool call the natural enforcement point. A review after the fact can find a problem but cannot prevent it.

For Tier 1, the default is allow within the agent's granted scope, with redaction of sensitive fields the task does not need and rate limits that catch bulk retrieval. For Tier 2, allow writes to permitted record types, block writes outside that scope, and rate limit write volume so a looping agent cannot alter many records quickly. For Tier 3, block unapproved recipients and channels, redact content that should not leave the bank, and escalate for human approval when the recipient or content pattern is new. For Tier 4, escalate for human approval by default, and block outright any call above limits the bank defines.

The specific thresholds are a bank decision. Rate limits, value limits and the conditions that trigger approval should be set against the bank's own tolerances and recorded in the tier standard. Numeric values should come from the bank's risk appetite, not from a generic template. Where a tier allows an action without approval, the standard should state why that is acceptable for the consequence involved.

Designing approval and delegation so tiers hold

Human approval is a control that degrades if overused. Frequent escalations can lead to habitual approval, which reduces the control to a formality. Reserve escalation for conditions that matter: Tier 4 actions, new Tier 3 patterns, and anomalies against an agent's normal behavior. Route each escalation to someone with authority over that action, and give the approver the tool, parameters and context needed to decide.

Delegation needs the same discipline. Scopes should narrow as authority passes down, so a sub-agent or downstream service never holds more authority than its parent. An action initiated by an agent under a different scope does not extend authority to the parent or to other agents. Credentials should be ephemeral and task-scoped rather than long-lived tokens or static secrets, because a reusable credential can bypass tier limits entirely. The enforcement layer should also be able to contain or revoke an agent's authority if anomalous behavior or context drift is detected.

Start from least privilege. Inventory every tool each agent can call, record which tier each tool falls into, and remove tools the task does not need. OWASP guidance on excessive agency makes the same point: limit the extensions an agent can call to the minimum necessary, and grant only the tool, data and action authority the task requires. The inventory also answers the first question an examiner is likely to ask, which is what each agent was permitted to do.

Evidence each tier should produce

Examiners and internal audit need two answers: what the agent was allowed to do, and what it did. Permission evidence is static and should be versioned. Action evidence is generated on every tool call. Both should be retained in a form that can be produced without reconstruction.

The field list below is a proposed design, not a prescribed schema. The depth scales with the tier. Tier 1 evidence may be summarized at volume, while Tier 3 and Tier 4 evidence should be complete for every call. Approver evidence matters most at the top tier, because it shows that the escalation reached an accountable person and what that person decided.

Retention periods and data residency should follow the bank's records policy. Evidence that itself contains sensitive content should be redacted consistently with the tier's data rules.

• Tier assignment record: Each agent's tool inventory, the tier of each tool, and the date and owner of the last review.
• Policy version: The policy and thresholds in force when each call was evaluated.
• Tool call: Agent identity, tool, action type and parameters, with sensitive values redacted as the tier requires.
• Decision: Allow, redact, block, rate limit or escalate, with the rule that produced it.
• Approver record: For escalations, who approved or declined, when, and what they were shown.
• Tier changes: Any change to a tool's tier or an agent's scope, with approval and rationale.

Where runtime policy enforcement fits

The tier standard belongs to the bank. Enforcement is the part that has to run in the path of each call. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact, block, rate limit and escalate for human approval to individual interactions and tool calls. That enforcement produces continuous, audit-ready evidence mapped to frameworks that include NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

Trussed has run continuously in production in a regulated enterprise for more than 18 months, and supports 100+ models under one policy plane. Its customers sit in insurance, pharma, healthcare and education, with insurance the regulated financial sector where it is deepest. Trussed does not trace complete agentic workflows or provide model lineage. A bank would still need its own tier definitions, validation practices and governance around them. The point of runtime enforcement is that those definitions are applied as the call is made, and that the evidence comes from the same decision rather than from a separate reconstruction.