AI agent governance framework template for regulated firms

A fill-in template for governing AI agents: register entry, autonomy tiers, approval gates, logging, identity, kill switch and staged rollout.

An AI agent governance framework is a register entry for every agent, autonomy set by the consequence of each action, human approval on anything irreversible, logs that show what actually ran, and a named owner who can switch the agent off.

Since late 2025, Singapore, OWASP, NIST, FINRA and the Bank of England have all published or discussed controls for AI agents, and they land in almost the same place. This guide turns that common ground into a template you can fill in for each agent before it goes live. It assumes you already have a general AI governance policy. If you don't, start with A practical guide to AI governance.

Why do agents need their own controls?

When a model gets something wrong, someone usually catches it in the draft. When an agent gets something wrong, the payment has already gone, the email has already been sent or the record has already been changed. General AI policies were written for the first case. Agent controls are for the second.

No jurisdiction has an agent-specific law yet. What exists is a set of frameworks and supervisory statements:

Singapore's Model AI Governance Framework for Agentic AI (January 2026)
the OWASP Top 10 for Agentic Applications (December 2025)
NIST's AI Agent Standards Initiative (February 2026)
FINRA's 2026 regulatory oversight report (December 2025)
the Bank of England and FCA AI Consortium's discussion of kill switches (minutes published August 2026)

Read side by side, they return to the same seven controls: least-privilege tools and permissions, a separate identity for each agent, human approval for high-impact or irreversible actions, a log of the plan, every tool call, the output and the approver, staged rollout with monitoring, a kill switch with a named owner, and an owner and review date for every agent. The template below covers all seven.

What goes in an agent register entry?

Every agent gets one entry, completed before it touches production. If a field can't be filled in, the agent isn't ready.

Field	What to record	Example (an invoice-matching agent)
Agent name and ID	A unique ID that appears in every log line	AP-MATCH-01
Owner	One named person accountable for what the agent does	Head of accounts payable, by name
Purpose	The job it does, and what it must never do	Matches invoices to purchase orders. Never releases payment
Tools and permissions	Each system it can call, and whether it reads or writes	ERP: read orders, write match status. Email: none
Data it can touch	Data categories, including personal or sensitive data	Supplier names and invoice values. No bank details
Autonomy tier	A tier for each action, from the table below	Look-up: tier 1. Match: tier 3. Release a hold: tier 4
Approval gates	Which actions need a person, who approves, what they see	Matches outside tolerance go to an AP supervisor
Logging	What is recorded, where it is kept, and for how long	Plan, tool calls, outputs, approvals, per your retention policy
Identity and credentials	Its own identity, and how long credentials last	Dedicated identity. Credentials expire daily
Kill switch owner	Who can stop it, how, and when it was last tested	AP systems lead. Tested at go-live, then quarterly
Rollout stage	Shadow, limited or full	Limited: one supplier group
Review date	When the entry is next checked and re-approved	Quarterly, and on any change of model, tool or scope

To use it, copy the first two columns into a spreadsheet and add one column per agent. The owner field is the one most often fudged. "Finance" is not an owner. A name is.

How should you set autonomy tiers?

Tier the action, not the agent. The same agent can read freely, propose changes and need sign-off to release money. Set each tier by asking what happens if that action is wrong.

Tier	The agent can	Use it for	Main control
1. Read only	Look up, retrieve and summarise	Answering questions, gathering case facts	Least-privilege read access and logging
2. Propose only	Draft an action for a person to carry out	New agents, and anything customer-facing at first	A person executes. The proposal and the decision are both logged
3. Act within limits	Act alone inside hard limits on value, volume and scope	Reversible, internal, high-volume work	Limits enforced by permissions, not instructions. Sampled review
4. Act with approval	Act only after a named person approves	Irreversible or high-impact actions	An approval gate that shows the exact action

One point matters more than the table. A limit written into the agent's instructions is not a control. If the agent mustn't pay over a certain amount, its permissions have to make that impossible.

Does a human need to approve every agent action?

No, and trying is a mistake. Sarah Breeden, a Bank of England deputy governor, said in June that requiring human approval for every agent action is unlikely to be realistic (as reported by Reuters). She's right. An approver who clears every action all day stops reading them. That isn't oversight. The ICO's draft guidance on automated decisions makes the same point from another direction: human involvement has to be active, not tokenistic.

So gate by consequence. The frameworks single out four kinds of action for a human: moving money, sending communications, deleting data and changing who has access to what. Everything else should sit inside hard limits or be reviewed by sample.

Two rules for the gate itself:

The approver sees the raw action, not the agent's summary of it. The payee and amount. The recipient list. The record being deleted.
The approver can refuse, and refusals are logged too. A gate that has never refused anything is worth a closer look.

What should an agent log?

Four things for every run: the plan the agent made, every tool call with its inputs and result, the output, and who approved what.

Then the one most logs miss: what the approver was shown, next to what actually ran. OWASP's agentic guidance calls this out. If the approval screen said one thing and the executed call did another, only that comparison will show it.

Write the log for the person who will read it in a dispute. Someone in risk should be able to rebuild a decision without an engineer translating. And if the agent sits in an EU high-risk use, deployers will have to keep logs for at least six months from December 2027.

The AI evidence pack guide sets out how those logs fit into the records a regulator or auditor will ask for.

Why does each agent need its own identity?

If three agents share one service account, your logs can tell you the account did something but not which agent did it. Give each agent its own identity, credentials that expire quickly, and only the permissions in its register entry. Keep read and write separate.

Identity is a focus of NIST's agent work and the subject of OWASP's "identity and privilege abuse" risk. It is also the control that makes every other record believable.

Who owns the kill switch?

Every agent needs a way to stop it at once, a named person allowed to use it, and a fallback for the work it was doing. According to a published summary of its minutes, the Bank of England and FCA AI Consortium discussed kill switches for higher-risk consumer-facing agents. Test yours before go-live and on a schedule. A kill switch nobody has ever pulled is an assumption, not a control.

How do you roll out a new agent?

Complete the register entry. Every field. A blank is a blocker.
Set a tier for each action. Start one tier lower than you think it needs, and promote it on evidence.
Issue the identity and permissions. Exactly what the entry says, with read and write separated.
Build the gates and the logging. Check that the approval screen shows the raw action and that the log captures what was shown and what ran.
Test before go-live. Run the agent against a fixed set of cases, awkward ones included, with pass marks agreed in advance. Pull the kill switch once.
Run in shadow. The agent proposes and people act. Compare its proposals with what people actually did.
Release to a limited scope. One team, one supplier group or one region. Watch errors, refusals and approval rates closely.
Widen on evidence. Promote a tier or extend scope only when the owner signs off on the results, and record why.
Review on the date. Re-approve, change or retire. An agent past its review date goes back to propose only.

How do regulators view agent governance?

FINRA (US broker-dealers). Its 2026 oversight report says AI agents may need their actions tracked and their system access restricted.
US banks (SR 26-2). The April 2026 model risk guidance says generative and agentic AI are not within its scope and leaves them to each bank's own risk management and governance. For agents, your framework is the governance. There is no federal template to lean on.
Canadian financial institutions (OSFI E-23). From 1 May 2027, E-23 covers AI, machine learning and vendor models. An agent's underlying model should be in the inventory with a risk rating, and the register entry is a natural place to hold that rating.
EU AI Act. There are no agent-specific articles. But where an agent sits inside an Annex III use such as credit, insurance pricing or employment, Article 12 (automatic logs) and Article 14 (human oversight, including the ability to override or stop) apply from 2 December 2027.
UK. The FCA has no AI-specific rules and relies on the Consumer Duty and the Senior Managers and Certification Regime. Accountability runs to a named senior manager, which is why the owner field matters.

How ETT can help

We build agents on UiPath with every action logged and every exception routed to a named person. Each agent ships with an evaluation set: the test cases it must pass before go-live. More on Agentic Automation on UiPath.

FAQ

Is there a standard AI agent governance framework to adopt?

Not a single one. Singapore's framework was written specifically for agents, OWASP covers the security risks, and NIST's work is still in progress. Use them as sources for a template like the one above, then check it against the rules for your sector.

How is agent governance different from model risk management?

Model risk management asks whether a model's output can be relied on. Agent governance also asks what the agent was allowed to do with that output, and who said so. Regulated firms need both, and in Canada E-23 will expect the models agents run on to be in the inventory.

How often should agents be reviewed?

Set the cadence by consequence, so agents with tier 4 actions are reviewed more often than read-only ones. We'd suggest no longer than quarterly for any agent that acts. Review straight away on any change of model, tool, permission or scope.

What's the difference between an approval gate and a kill switch?

An approval gate stops one action before it runs. A kill switch stops the whole agent. You need both, with different owners if possible, because the person approving routine actions isn't always the right person to shut a process down.

Sources

Agentic AIAI GovernanceControls

An AI agent governance framework: a control template for regulated firms