TL;DR: Almost no rule names AI agents yet. One bank's regulator revised its model risk guidance and left generative and agentic AI outside it. That silence isn't permission. An examiner still asks whether you had control of the agent. Map every agent onto a control you already report on, and keep the proof.
On the same day in July, two financial firms told me opposite things about the same question.
One put its AI work under model risk management and treated it as a governed model. The other said its regulator had just revised model risk guidance and left generative and agentic AI outside the scope. Both calls were July 6, 2026. Both teams were smart. They read the same silence two different ways.
That's where most regulated businesses sit right now. Nobody has written you a rule. You still have to answer for what your agents do.
Key takeaways:
Regulatory and sovereign-cloud constraints shaped the AI question on nine client calls between March 30 and August 21, 2026. It's the constraint buyers name before they name a product.
On July 6, 2026, two financial firms read the same question in opposite ways. One governed AI as a model. The other's regulator had scoped it out.
Silence from a regulator isn't a safe harbor. Examiners ask whether you had control, not which rule you followed.
Your own environment rules out much of the AI governance market before you evaluate anything. FedRAMP Moderate and GCC High each cut the vendor list hard.
The fastest path is to map each agent onto a control you already report on, so the answer comes from a system of record instead of a memo.
Which rules apply to AI agents in a regulated business right now?
Very few, and none of them were written with an agent in mind.
You're mostly borrowing. Model risk management, third-party risk, access control, records retention. Each one was built for something else and each one partly fits. An AI agent that reads customer records and takes an action touches all of them at once, which is why no single owner picks it up.
The old anchor is the Federal Reserve's supervisory guidance on model risk management, known as SR 11-7 and issued in 2011. It defines a model as something that turns inputs into estimates, and it tells banks to validate and govern them. An agent that calls tools and changes records isn't really that. It's closer to a worker with credentials.
So the honest answer is that you're operating in the space between two rulebooks. One was written for models. One was written for people. Your agent is neither.
Why did one regulator scope AI out of model risk guidance?
Because model risk guidance covers models, and a generative system doesn't behave like one.
A regional bank holding company told me on July 6, 2026 that its regulators had revised model risk guidance and left generative and agentic AI out of scope. I'm reporting what that team told me on the call, not a published rule change, and I'd check it against your own examiner before building anything on it. The reasoning they described was practical. Validating a model means testing whether its output is accurate within known bounds. That test doesn't work on a system whose output is different every time.
Here's the part that surprised them. Scoping AI out of model risk didn't reduce their work. It moved it. The obligation didn't disappear, it just lost its owner. Model risk had a validation team, a schedule, a named owner, and a report that already went to their examiner. Once AI sat outside that, nobody owned the reporting line.
That's the real cost of being scoped out. You lose the machinery, not the duty.
Is regulatory silence the same as permission?
No. An examiner's question isn't "which rule did you follow." It's "show me you had control."
That question has the same shape whether or not a rule names your agents. Can you see them. Can you stop one. Can you trace an action back to an agent and to the person who owns it. Can you show all of that after the fact, from a record you didn't write by hand.
If you can answer those, the missing rule is an inconvenience. If you can't, the missing rule won't protect you. Nobody has ever been excused because the guidance was unclear.
This is the same proof chain that a security leader owes company leadership, and we walked through how to present it in what a CISO should tell the board about AI agents. An examiner wants the same four answers, with more evidence behind each one.
One piece of that chain does more work than the rest. Every agent needs a named human who owns it, because an agent can't be held accountable and a team can't either. We wrote that out in every AI agent needs one accountable human. An examiner will ask who owns this agent. "The platform team" isn't a person.
Why does your own environment disqualify most AI governance products?
Because the constraint comes before the evaluation, and buyers keep discovering it late.
A defense supplier told me on August 4, 2026 that it runs in GCC High, the government community cloud for regulated US defense work. That environment breaks device management features that work fine everywhere else. A healthcare clearinghouse told me on May 29, 2026 that hosting had to sit at FedRAMP Moderate, the US government's baseline authorization for cloud services holding sensitive data. That one requirement removed most of the AI governance market from its list before a single demo.
Add CMMC for defense work and the European AI Act for anything sold into Europe, and the pattern holds across sectors. Nine of my client calls between March 30 and August 21, 2026 turned on a constraint like this. In most of them the constraint, not the threat model, decided what the team could buy.
Two things follow from that. Check your authorization boundary before you shortlist anything. And expect to build more yourself than a vendor roadmap suggests, because a product that fits your environment usually has the fewest AI features.
What should you do when no rule names your agents?
Attach each agent to a control you already report on.
You already have systems that produce evidence on a schedule. Access reviews. Change management. Third-party risk. Records retention. Each of those has an owner and a report that already goes somewhere. An agent with credentials is an access story. An agent that changes code or config is a change management story. An agent running on somebody else's model is a third-party story.
Do it in this order:
List the agents that touch regulated data or take actions on their own. Not all of them. Start with the ones that would hurt.
For each one, name the human who owns it. One name, not a team.
Pick the existing control that already covers the closest thing, and add the agent to it. Access review is usually the right first home.
Write down what the agent is allowed to reach, and make widening that list a reviewed change instead of a setting.
Keep an attributed record of what the agent did, stored where you can't edit it.
None of that waits on a regulator. All of it produces the evidence an examiner asks for. And when a rule does arrive, you'll be mapping it onto controls that already run, which is a much smaller job than starting then.
The NIST AI Risk Management Framework is a reasonable scaffold if you want an external structure to point at. It's voluntary and it won't satisfy an examiner on its own. It does give you language that a risk committee recognizes, which is worth something when you're explaining why you acted before you were told to.
Frequently asked questions
Does the EU AI Act cover AI agents used inside a company?
It can, depending on what the agent does and where it's used. Regulation (EU) 2024/1689 sorts systems by risk and puts real obligations on high-risk uses, including ones inside a company. A client with European product exposure raised this on August 21, 2026. If you sell into Europe or employ people there, get a legal read on classification early, because the answer changes what you have to document.
Do we have to treat an AI agent as a model under model risk management?
That depends on your regulator and your own policy, and I've seen it settled both ways in the same week. The useful question isn't which box it goes in. It's whether the box you pick has a real owner and a report that goes somewhere. A wrong box with working machinery beats a right box with nobody in it.
What's the smallest thing we can do this quarter?
Name an owner for every agent that touches regulated data, and put those agents into your existing access review. That's usually a few weeks of work and it answers the two questions an examiner opens with.
Will a vendor product solve this for us?
Not by itself, and in a regulated environment your authorization boundary will cut the candidate list before capability does. Assume you're assembling this from controls you already run, with a product filling one part of it.
The silence won't last
Rules for AI agents are coming. They'll arrive unevenly, by sector, and they'll mostly codify what careful teams are already doing.
If your agents already sit inside a control with an owner and a report, a new rule is a mapping exercise. If they don't, it's a build. On July 6 two firms read the same silence in opposite ways, and only one of them was building the evidence either way.
I'd rather be the one who guessed wrong about the box and right about the proof.