The AI Agent Question SR 26-2 Leaves Your Bank to Answer

On April 17, 2026, the Federal Reserve, OCC and FDIC replaced fifteen years of model risk management guidance with SR 26-2, superseding SR 11-7. The revised guidance emphasizes a risk-based approach tailored to a bank’s size, complexity and model use. It is expected to be most relevant to institutions with more than $30 billion in assets, although it may also be relevant to smaller banks with significant model risk.

For banks deploying agents, a consequential line appears in a footnote. The guidance excludes generative and agentic AI models because they are novel and rapidly evolving. But the same footnote says a banking organization’s own risk management and governance practices should guide appropriate controls for anything the document does not cover.

That exclusion does not establish a regulatory exemption. It leaves banks with an implementation question: 

“How should their existing governance commitments translate into controls for agents that can take action?”

One place to start is authorization. When an agent takes an action inside your bank, can you establish which agent it was, whose authority it was exercising and what it was permitted to do at that moment?

Consider an agent assigned to reconcile a ledger. It needs access to transactions and supporting records. It may need to flag discrepancies. That assignment should not give it permission to move funds even if the employee who initiated the task has that permission. This is a typical backend, non-interactive agent workflow, where no human is present to approve each step in real time.

A record of what the agent did is useful. Evidence that the system constrained what it could do is stronger.

What Treasury and NIST's AI Frameworks Cover

The financial sector has been building resources to help institutions manage AI risk.

In February 2026, Treasury released two resources for the sector: a shared AI Lexicon and the Financial Services AI Risk Management Framework. Developed through public-private collaboration with the Cyber Risk Institute, the framework adapts the NIST AI Risk Management Framework to financial services. It provides tools for evaluating AI use cases and embedding accountability across the AI lifecycle.

The NIST AI RMF covers AI products, services and systems. Its breadth is useful, but institutions still need to translate its objectives into specific controls for their agent workflows, including identity and authorization.

Identity also has its own industry workstream, co-chaired by the American Bankers Association and the Better Identity Coalition. Its papers on mitigating AI-powered attacks against identity and authentication address threats including deepfakes, synthetic identities and emerging agent-related attacks. A companion paper proposes twenty actions for policymakers and regulators.

The focus here is on agents as potential adversaries: something to defend against and detect. That is important work, but it addresses a different question from how your own authorized agents receive an identity, a scope and an audit trail.

These efforts contribute different pieces. Model risk guidance places agentic AI outside its scope. The sector risk framework provides broader governance objectives. The identity workstream focuses on attacks against identity systems. But banks still need to determine how an authorized agent acts inside their systems on someone’s behalf.

Defining Agent Identity and Authorization

Other work addresses those implementation questions more directly.

Singapore’s IMDA launched its Model AI Governance Framework for Agentic AI in January 2026. It recognizes the additional risks introduced when agents can access sensitive data and change their environment, including making payments or updating customer records. Its governance approach addresses the scope of agent activity, human accountability and technical safeguards.

NIST’s NCCoE has gone further into the mechanics. Its February 2026 concept paper on software and AI agent identity and authorization proposes work on agent identification, authorization, access delegation and logging. It explores how existing standards and practices can support agents and where further work is needed.

NIST made the argument more explicit in its August update on agent identity: agents need their own identifiers, credentials and entitlements, connected to the user or system operating them. It also highlights the risks of shared credentials and long-lived access.

The direction is clear even where implementation details are still evolving. Governing agents requires control over their identity, authority and actions, alongside evaluation of their outputs and behavior.We've written more on how identity and access management applies specifically to AI agents.

Why Service Accounts and User Tokens Aren't Enough for AI Agents

Two implementation shortcuts can make that control difficult.

The first is to give the agent a long-lived service-account credential with broad permissions and no record of delegated authority. This is operationally easy, but it can leave a serious gap in the evidence. The audit log may identify the agent without showing which user or organizational mandate authorized the action. You can establish that the agent did something, but struggle to demonstrate that it was permitted to do it.

The weakness is the broad, standing access and missing delegation context. Service accounts themselves are not inherently unsuitable.

The second shortcut is to hand the agent the user’s own token and let it act as the user, without preserving a separate agent identity. Downstream systems may then be unable to distinguish the agent’s actions from the human’s. If the token carries permissions beyond what the task requires, the agent also receives unnecessary access.

Both patterns can obscure the distinction between the actor and the source of its authority. That becomes more difficult to manage when agents delegate work and act in chains that cross systems. OAuth Token Exchange already supports delegation semantics that distinguish the actor from the party it represents. The work is making those semantics meaningful and enforceable throughout the workflow.

Extending Zero Trust Principles to AI Agents

For institutions already implementing zero trust, much of this work extends familiar commitments: explicit authorization, limited privileges and access decisions that respond to changing context.

Agents introduce additional questions about how those commitments operate. What constitutes a task? How much authority can an agent delegate? What happens when the task changes? How quickly can access be withdrawn?

A bank does not need to resolve every aspect of agent governance before addressing these questions. It can start with the access paths through which agents read data and take action.

Eight Controls for Enforceable Agent Authorization

If you are defining controls for agents, these are the ones that help make authorization enforceable and produce evidence of how it worked.

• Give each agent a distinct identity and use ephemeral clients where appropriate. Avoid shared credentials that obscure which agent acted and maintain enough execution context to distinguish individual runs. Creating a permanent client registration for every agent run can lead to unnecessary administrative overhead. Use short-lived, task-scoped clients where possible while preserving an accountable owner and durable audit context.

• Preserve the source of authority. When an agent acts for a user, downstream systems should be able to establish both identities and the delegation relationship — a question closely tied to how user consent should work for AI agents acting on someone's behalf.When it acts under an organizational mandate, preserve that mandate and its accountable owner. A credential carrying both actor and subject information is one way to support this.

• Bind access to the task. An agent’s access should not outlive the work it was issued for. Scope it to the interaction and give it a limited lifetime. This reduces standing privilege and the exposure window if a credential is compromised.

• Provide a way to stop access before expiry. Short-lived credentials do not eliminate the need to respond to compromise. Test how to disable the agent, prevent further credential issuance and deny subsequent requests across affected systems.

• Bind scope to purpose. An agent authorized to reconcile a ledger should not hold credentials that let it move funds, even briefly, even if nothing in its instructions tells it to.

• Evaluate authorization at every step. Agents act in chains. A decision that was correct when the chain started may no longer be correct four calls later. Each protected action should be checked against applicable policy, and delegation should preserve or narrow the authorized scope.

• Log the chain as well as the call. A useful audit record establishes which agent called an API, under whose authority, with what scope, what the system decided and what action resulted. Preserve the context needed to trace that sequence across services.

Require approval for high-impact actions. Identify actions that warrant explicit human approval, such as releasing a payment or changing sensitive records. Bind that approval to the specific action being authorized. These controls form one part of a wider agent risk program. They do not replace testing, monitoring, data protection or incident response. They make the access decisions underneath that program explicit and reviewable.

Established OAuth capabilities provide building blocks for much of this work. Their effectiveness depends on how APIs, policy enforcement and audit systems use them.

Three Questions to Assess Your Agent Authorization Controls

You do not need to wait for further guidance to assess your controls. Choose one production workflow and ask three questions:

1. Can you identify every agent that can access the workflow’s APIs, along with its owner and permissions?

2. For any action an agent took last week, can you establish its source of authority and the authorization decision?

3. If an agent were compromised mid-task, what would you do to stop further access, and how quickly would that take effect?

Test the answers against an actual execution. Trace the ledger-reconciliation task from its initial authorization through its downstream calls. Check whether an attempted funds transfer would be denied. Then test what happens when access is withdrawn.

That exercise turns a governance discussion into a control assessment.

How Curity's Access Intelligence Applies These Controls

Curity’s work focuses on the access layer underneath APIs. Access Intelligence extends that layer to non-human callers through scoped access, distinct agent and user identities, and authorization evaluated across API requests. It also supports explicit approval for high-risk actions and operates alongside an institution’s existing identity infrastructure.

Access Intelligence reinforces the API security foundation we have helped customers build for years. Our customers are already using that foundation to run AI in production, from customer-facing assistants to trading agents.

At If Insurance, IfGPT uses the same API security architecture that protects the company’s other digital channels. As If puts it: “Curity protects most of our AI projects. We don’t do anything radically new - it’s about following the established best practices.”

Another customer has AI trading agents in production, secured through the API foundation it established before introducing those agents. Access Intelligence builds on that work, extending established access controls as agents take on more responsibility.

Whatever future guidance requires, banks deploying agents need a defensible answer today: who was the agent, under what authority did it act, and what was it allowed to do?

That is worth being able to answer before someone asks.