Introduction
AI agents are showing up inside regulated businesses faster than anyone is writing them down. The headlines are about frontier AI labs, but the exposure most of us actually have is a lot more ordinary: an agent nobody owns is an unmanaged employee.
Here is the short version, before we get into it:
- AI agent governance is not a new discipline. It is the one you already run on your customers and your vendors.
- An agent without a named owner is an unmanaged employee with system access.
- You do not need a new regulation to start. You need a list with a person’s name on every line.
AI Agents Are Already Working Inside Your Business
What happens at your company when a new person starts? Now ask the same question about the AI agent somebody turned on last Thursday.
We brought a new team member on recently and I sat in for part of the first morning. There is a rhythm to it by now. Paperwork. A background check. An introduction to the person they report to. An account set up with access to the systems the role actually needs and nothing more. A review was already on the calendar before they answered their first ticket.
None of that is bureaucracy. It is how you bring somebody into a business you are responsible for, and we do more or less the same thing when we take on a new vendor.
Now think about the last piece of software your organization turned on that can read a mailbox, pull documents, and make a decision without asking anybody first.
- Who is its manager?
- What is it allowed to touch?
- Who approved it, and when does it come back up for review?
When I ask those questions, the answer is usually a pause. The pause is not because anyone was careless. Nobody has decided yet that these things need an owner.
Why AI Agent Governance Is Suddenly Urgent
The news this past week has been loud about the dangers of AI:
- The European Commission told tech firms to get their advanced models “under control” after autonomous agents escaped a testing environment and breached Hugging Face’s infrastructure.
- NSA, CISA and the FBI put out a joint warning about foreign extraction of U.S. model capabilities.
- A committee in the UK Parliament said the current rules are fragmented and lean far too heavily on voluntary compliance.
- Bills are circulating now for kill switches and outright bans.
There is a detail in that first story that did not get much attention. OpenAI did not know its own agents were responsible until Hugging Face disclosed the breach publicly, roughly a week after the first signs showed up. The company that built the agents could not say what they were reaching or what they were doing.
So what is the honest answer at a two hundred person credit union? A regional clinic? A lender running a couple of vendor copilots and a document intake bot an engineer stood up one afternoon?
None of that requires a superintelligence. It is an accountability problem, and we have solved those before.
AI Agent Governance Starts With Treating the Agent Like a Person
An AI agent is a worker, and workers get managed. You already have a process for bringing a person into the organization, and another for a customer who gets screened and then reviewed again on a schedule. An agent fits that shape better than people expect.
| What you already do for a person or vendor | What it looks like for an AI agent |
|---|---|
| Reports to a named manager | A named owner, not a department |
| Role-based system access | A written data and system scope |
| Background check and approval | A documented risk decision before go-live |
| Performance and access reviews | A recertification date, typically every 90 days |
| HR file and audit history | An approval and activity record an examiner can read |
1. Give it an owner
A named individual, not a department. “IT owns it” is not an owner. It is a place for responsibility to go and quietly disappear.
Somebody should be able to say out loud that the AML triage agent is theirs, the same way a manager owns a direct report. And when that person leaves the company, the agent gets reassigned rather than orphaned.
2. Write down what it can reach
A customer service assistant that can read one shared inbox is a very different risk than one that can read every mailbox in the tenant, and the difference is usually a checkbox somebody clicked during setup.
Record what data and which systems the agent is authorized to touch, in plain language, so that somebody outside of IT can read it and understand what they are approving. If you already run vendor risk management this will feel familiar, because it is the same question asked of a different kind of supplier.
3. Find them, do not wait to be told
A registry that depends on people volunteering their own agents is a spreadsheet, and it will be out of date within a month.
The managed security tooling already running in your environment is watching identities and OAuth grants right now. The signal usually exists. What is missing is the step that turns “new application connected” into a case with somebody’s name on it.
4. Put a review date on it
You already run periodic reviews on your customers. Agents deserve the same treatment, for the same reason. What was true at approval is often not true ninety days later. Permissions get widened, or a vendor ships an update that quietly changes what the thing can do.
5. Keep the record of who said yes
Who approved it, and what they understood the risk to be at the time.
That record is what turns a technical alert into something a compliance officer or an examiner can actually work with. Trust but verify applies here the same as it does everywhere else in the business.
Where the Regulators Stand Right Now
The regulatory picture behind AI agent governance is uneven.
When the banking agencies replaced their model risk guidance back in April, they set generative and agentic AI aside as novel and rapidly evolving. So there is no formal rule for banks today, just a widening gap between what institutions are doing and what they can prove.
Healthcare has gone the other direction. Documentation expectations are already landing on covered entities using AI in clinical decision support.
The question is coming either way. The organizations that answer it well will be the ones who started keeping the record before somebody asked for it. That readiness is usually less about tooling and more about people, which is the same argument we made in AI adoption fails without change management.
What AI Agent Governance Looks Like in Verify
This is the work our compliance and workflow team has been focused on.
Verify, our compliance orchestration platform, already governs regulated subjects for a living. A customer comes in, gets screened against KYC, KYB, AML, OFAC and adverse media criteria, gets an owner and a documented approval, and then comes back around for periodic review on a schedule the institution sets. Vendors run through the same engine. Everything that happens to a file lands in an audit history somebody can pull up later.
An AI agent is another regulated subject. So we are adding a new entity record type to Verify for AI agents, sitting right beside the customer record and running on the same workflow, approval and audit trail engine we already maintain. Each agent gets:
- A named owner
- A stated business purpose
- A risk tier
- A written data and system scope
- An approval history
- A recertification date that brings it back for review
The piece that separates this from a generic AI governance tool is that agents do not have to be reported by hand. Verify is being built to take discovery signals from the endpoint and identity security tools already deployed in a client environment, so that a raw technical event turns into a governed compliance case rather than one more alert nobody closes.
A few examples of how that is meant to work:
Low risk AML triage. A bank turns on an AI helper to clear low risk AML alerts. Verify routes it to Compliance and IT for sign off, logs every alert the agent clears against its record, and flags it for review every ninety days.
A new OAuth grant. Huntress flags a new OAuth grant for Microsoft Copilot with mailbox access. Verify opens a draft record in Pending status and notifies a designated owner. It cannot move to Approved until a named person documents a risk decision, so it stays visible as an open item instead of a resolved one.
An agent nobody announced. An engineering team connects an agent to pull applicant documents, and SentinelOne or CrowdStrike detects the new identity. Verify creates the record and flags it as unreviewed before it reaches production use.
The point is that AI agent governance does not have to be a separate platform bolted onto the side of the business. It runs on the compliance engine our clients already use every day, which means the AI agent file looks and behaves like the customer file sitting next to it.
This capability is in development rather than live today, and we are deliberately talking with a small number of organizations who want to help shape how it works before we finish building it.
Where to Start This Week
You do not need a platform or a mandate to start on AI agent governance. Open a document this week and list:
- Every AI agent, copilot and assistant you know is running in your environment
- A human name beside each one
- What each one can read or reach, in plain language
- A date to look at the list again
You will probably find the list is longer than you expected, and that a few entries have nobody’s name on them at all. That hour is worth spending.
If you would rather not start from a blank page, our affiliate company, Dev Information Technology Ltd. (Dev IT), provides a free AI readiness assessment that walks through this kind of inventory question alongside the rest of your AI posture.
Ultimately, you as the business leader get to decide how much structure this deserves in your organization. But the companies that treat AI agents as software they installed are going to keep being surprised by them. The ones that treat them as workers who have to be managed will not.
Frequently Asked Questions
AI agent governance is the practice of managing autonomous AI systems the way you manage employees and vendors. Each agent has a named owner, a documented purpose, a defined scope of data and system access, a recorded approval, and a scheduled review. It is less about the technology and more about accountability.
Model governance asks whether a model’s outputs are accurate, fair and explainable. Agent governance asks what the agent is allowed to do: which mailboxes it reads, which records it changes, which decisions it makes without a human in the loop. A well validated model connected to the wrong systems is still an unmanaged risk.
A named individual with enough context to explain the business purpose and enough authority to approve the access. Usually that is the business owner of the process the agent supports, with IT and compliance as reviewers. A department name is not an owner.
Ninety days is a sensible default for anything touching customer data or regulated decisions, with lower risk agents on an annual cycle. The trigger that matters most is change. A permission widened or a vendor update can alter what the agent can do without anyone filing a ticket.
There is no single formal rule for U.S. banks yet, because the agencies set generative and agentic AI aside as novel and rapidly evolving when they refreshed model risk guidance. Healthcare has moved faster, with documentation expectations already reaching covered entities using AI in clinical decision support. In both cases, the examiner’s question will be whether you can produce the record.
Through the identity and endpoint tooling you already run, which is where our managed IT and security teams usually start. New OAuth grants, new service identities and new application connections are visible today in platforms like Huntress, SentinelOne and CrowdStrike. The missing step is routing that signal into a compliance case with an owner attached, rather than into an alert queue.
Related Blogs
