AI Agent Governance Framework: Template and Policy

Before you start

What this framework is for

It is

A structure for your internal agent policy
Example clauses written in plain language
Aligned with NIST AI RMF, OWASP agentic threats and the AWS scoping matrix
Designed so every rule has an enforcement point

It is not

Legal advice for your jurisdiction
A certification or standard
Complete for high-risk uses without legal review
A replacement for your existing AI policy

Use it as a starting draft. Cut what does not apply, and add your own approvers, tools and review dates.

Keep the clause numbers even when you cut clauses. Stable numbers make audit trails and tickets easier to follow.

Every clause should name the system that enforces it. The enforcement map further down shows how.

PART 1Scope and definitions PART 2Roles PART 3Agent register PART 4Agency tiers PART 5Tools and MCP PART 6Web access PART 7Identity and data PART 8Human oversight PART 9Logging and incidents PART 10Review and retirement

The framework

Ten parts with example clauses

Clause numbers make the policy easy to reference in tickets and audits.

1

Scope and definitionsWhat counts as an agent, and which agents this policy covers.

1.1An AI agent is any software that uses an AI model to choose and take actions, including calling tools or opening web pages.

1.2This policy covers agents built in-house, agents configured on vendor platforms, and vendor agents acting for our staff.

1.3An action page is any web page where an agent can create an account, reset a password, buy, subscribe, upload, post or comment.

2

RolesEvery agent has a person who answers for it.

2.1Each agent has one named owner, who is accountable for its behaviour and its review.

2.2The AI platform team approves tools and MCP servers. The security team sets web and network rules.

2.3Risk and legal decide whether an agent falls into a regulated or high-risk use.

3

Agent registerNo register entry, no production.

3.1No agent may run in production without an entry in the agent register.

3.2The entry records purpose, owner, tier, tools, credentials, data classes, web policy and review date.

3.3Agents discovered outside the register are paused until registered or retired.

4

Agency tiersHow much an agent may do on its own.

4.1Each agent is assigned one tier: Tier 1 answers only, Tier 2 follows fixed workflows, Tier 3 plans with approvals, Tier 4 acts on its own.

4.2Controls in parts 5 to 9 apply by tier, as shown in the tier table.

4.3Any new tool or permission triggers a tier review before it is enabled.

5

Tools and MCP serversOnly approved tools, only the parts that are needed.

5.1Agents may only use tools and MCP servers on the approved list.

5.2Approval is per tool, not per server. Write and delete tools need a separate approval.

5.3Third-party MCP servers are reviewed before approval and re-reviewed when they change version.

5.4Tools that send company data outside the organisation need approval from the owner of that data.

6

Web accessWhat agents may open on the internet.

6.1Agents may open read pages, such as pricing, documentation, blogs and legal pages, where their purpose requires it.

6.2Agents may not open action pages (signup, password reset, cart, checkout, subscribe, upload, post, comment) unless the register grants an exception.

6.3Destinations that cannot be classified are denied for Tier 3 and Tier 4 agents.

6.4Web rules are expressed as page types, not domain lists, and enforced before each request.

Clause 6.4 is what makes 6.1 to 6.3 enforceable. An AI agent allow list supplies page types for 40M+ domains.

7

Identity and dataLeast privilege, short-lived access.

7.1Agents use their own service identities, never a person's credentials.

7.2Credentials are scoped to the task and expire within the shortest workable period.

7.3Agents may only process the data classes listed in their register entry.

8

Human oversightPeople decide what matters.

8.1Tier 3 agents route denied action pages to their owner for approval instead of retrying.

8.2Every agent can be stopped at once by its owner or by security.

8.3Approval requests are limited in number so reviewers can read each one.

9

Logging and incidentsIf it is not logged, it did not happen.

9.1Every tool call and every web request made by an agent is logged with agent, target, decision and reason.

9.2Logs are kept for at least twelve months, or longer where law requires.

9.3Suspected agent incidents follow the security incident process, with the agent owner involved.

10

Review and retirementAgents change. Reviews catch it.

10.1Each agent is reviewed at least every 90 days, and after any model, tool or tier change.

10.2Retired agents lose all credentials, tool approvals and network access on the retirement date.

10.3The register keeps retired agent records and logs for the retention period.

Controls by tier

What each agency tier requires

Control	Tier 1: answers only	Tier 2: fixed workflow	Tier 3: plans with approval	Tier 4: acts alone
Register entry	Required	Required	Required	Required
Tool approval	Not applicable	Per workflow	Per tool	Per tool, write tools reviewed
Web read pages	Not applicable	Listed pages only	Allowed by purpose	Allowed by purpose
Web action pages	Not applicable	Denied	Denied, owner may approve	Denied
Unclassified hosts	Not applicable	Denied	Denied	Denied
Credential lifetime	None needed	Per run	Hours	Minutes to hours
Logging	Prompts	Workflow steps	Every request	Every request, alerting
Review cycle	Yearly	6 months	90 days	90 days and after changes

Tiers follow the same idea as the AWS agentic AI security scoping matrix. See our framework comparison.

Three example register entries

Support answer agent

Tier 2: fixed workflow
Tools: help desk read, knowledge base search
Web: status and help_center pages of three vendors
Review: every 6 months

Vendor research agent

Tier 3: plans with approval
Tools: CRM read, browse
Web: read pages allowed, action pages go to the owner
Review: every 90 days

Coding agent

Tier 4: acts on its own in a sandbox
Tools: repository, test runner, documentation fetch
Web: documentation only, all else denied
Review: 90 days and after every tool change

Policy as code

Part 6 written so a machine can enforce it

The register holds this file per agent. Your gateway, proxy or fetch tool reads it and checks each URL against page types.

# agent-policy.yaml (illustrative) agent: vendor-research owner: head-of-procurement tier: 3 tools: [crm.read, web.browse] web: allow_page_types: [pricing, documentation, about, legal, security, status, case_studies] deny_page_types: [signup, password_reset, cart, checkout, subscribe, upload, post_create, comment] unclassified: deny on_deny: request_owner_approval egress_rules: library-default # ~40 URL-pattern rules on any domain host_list: high-value-default # ~60 always-denied hosts logging: every_request review_by: 2026-12-31

Full schema: agent policy YAML. Enforcement: build a policy engine.

Approval workflow

From idea to production in five steps

STEP 1RequestOwner files the register entry with purpose and tools.

STEP 2TierRisk assigns the agency tier and data classes.

STEP 3ControlsPlatform approves tools. Security sets web policy.

STEP 4TestRun the agent against denied pages. Confirm the denials log.

STEP 5LaunchOwner signs off. Review date is set.

Step 4 is often skipped. It is the only step that proves the written web rules actually run.

What to test in step 4

Open a known signup page: expect deny
Open a known checkout page: expect deny
Open a pricing page: expect allow
Open an unclassified host: expect deny for Tier 3 and 4

What to keep as evidence

The test URLs and the decisions returned
The log lines with agent name and reason
The owner's sign-off with the date
The next review date in the register

Mapping

How the ten parts map to known frameworks

Part	NIST AI RMF	OWASP agentic threats	EU AI Act theme
1 to 3 Scope, roles, register	Govern, Map	T13 rogue agents	Risk management
4 Agency tiers	Map	Excessive agency	Risk management
5 Tools and MCP	Manage	T2 tool misuse	Accuracy and robustness
6 Web access	Manage	T2, T3, T9, T11	Human oversight
7 Identity and data	Manage	T3, T9	Data governance
8 Human oversight	Govern	T10	Human oversight
9 Logging and incidents	Measure, Manage	T8	Record keeping
10 Review and retirement	Govern	T13	Post-market monitoring

Mappings are a starting point, not a legal opinion. Confirm with your risk and legal teams.

Part 6 maps to four OWASP threats at once, which is why web rules pay off early.

Measuring it

Eight KPIs for the framework

Coverage

Registered agents as a share of discovered agents
Agents with a named owner
Agents reviewed on schedule
Vendor agents recorded

Enforcement

Denied action-page attempts per agent
Requests to unclassified hosts
Owner approvals granted and refused
Days from retirement decision to access removed

The enforcement KPIs come from decision logs. Without page-level enforcement, the first two cannot be measured at all.

Report both sets monthly to the committee that signed off the framework, with one line of commentary per KPI.

Adopting it

Rolling the framework out in 60 days

WEEK 1 TO 2Adapt the textEdit the clauses, name the approvers, agree the tiers.

WEEK 3 TO 4Build the registerDiscover agents and create entries with owners.

WEEK 5 TO 6Switch on enforcementTool allowlists, identities and page-level web policy.

WEEK 7 TO 8Report and reviewFirst KPI report. First round of reviews.

Quick wins

Deny the 8 action page types for every agent
Deny unclassified hosts for Tier 3 and 4
Name an owner for every agent

Takes longer

Recording vendor agents
Moving agents to their own identities
Legal review of high-risk uses

Exceptions

Granting an exception to clause 6.2

Some agents do need an action page. A purchasing agent may place orders with one approved supplier.

1Name the page typeFor example checkout, not "the supplier site".

2Name the domainOne supplier domain, not a category.

3Set a limitAmount, frequency or approval per action.

4Set an end dateExceptions expire and must be renewed.

5Record itIn the register, visible to the auditor.

# Exception, narrow by design exceptions: - page_type: checkout domain: approved-supplier.example limit: owner_approval_per_order expires: 2027-03-31

Enforcement map

Which system enforces which part

Part	Enforced by	Evidence produced
3 Agent register	Deployment pipeline refuses unregistered agents	Register entries and pipeline logs
5 Tools and MCP	MCP gateway or tool allowlist	Tool call logs with decisions
6 Web access	Page-type check in fetch tool, gateway or proxy	Per-URL allow and deny log
7 Identity	Identity platform with scoped, expiring credentials	Token issue and expiry records
8 Oversight	Approval queue on denied action pages	Approval history
9 Logging	Central log store and SIEM	Retained logs, incident tickets
10 Retirement	Identity and gateway revocation	Revocation timestamps

If a part has no row in your own version of this table, it is a statement of intent, not a control.

Fill the gaps in order of risk. For agents that browse the web, Part 6 usually comes first.

Would Part 6 have stopped the 2026 incidents?

Clause 6.2 denies uploads, posts and signups. Clause 6.3 denies unclassified hosts.
The incidents involved wiki edits, a plugin install, WebDAV folders and dataset uploads.
In our replay, page data plus egress rules would have stopped almost all of them.

Would your agents have been stopped? Check the incident analysis The second swarm case

The honest fine print — the same two assumptions we publish, plus two operational ones

The policy engine must see every request — an agent with raw socket access or a second network path bypasses everything; enforcement belongs at the egress proxy/network layer, not only in an SDK hook.
Default-deny must be on. In flag-only mode these become alerts within minutes rather than prevention — still a large improvement on a timeline measured in weeks (the DseWiki edits ran from late May to late June 2026, per the researchers), but not a block.
For full URL+method matching on HTTPS you need to be the proxy or in-process hook — SNI alone shows only the host, which still catches the entire host-list layer.
Policy can’t read intent inside a legitimately allowed action: an agent whose job is publishing packages keeps registry access. In our replay of the 2026 incidents, no crossing fits any plausible allowlist for the agents’ documented tasks.

Governance platforms

Five types of tools that can hold this framework.

Default-deny policy design

How to roll out clause 6.3 without breaking agents.

For legal and compliance teams

Who approves the allow list, and how.

Pricing

Page-type data from $99 a month.

FAQ

Governance framework questions

What should an AI agent governance framework include?

At minimum: scope and definitions, roles, an agent register, agency tiers, tool rules, web access rules, identity and data rules, human oversight, logging and incidents, and review and retirement.

Is there an AI agent governance policy template?

This page is one. Each of the ten parts has example clauses you can adapt to your own organisation, with your own approvers and review dates.

How is agent governance different from general AI governance?

Agents act. So agent governance adds rules for tools, credentials and web access, and needs enforcement points that can block an action before it happens.

How do I enforce the web access rules?

Check every URL before the agent opens it, using page-type data. An AI agent allow list classifies 40M+ domains into 28 page types, so action pages can be denied by type.

How often should agents be reviewed?

Every 90 days for agents that plan or act on their own, and after any change to model, tools or tier. Simpler agents can be reviewed less often.

Can an agent ever be allowed to buy or sign up?

Yes, through a narrow exception: one page type, one domain, a limit, an end date, and a record in the register. Everything else stays denied.

Who should sign off the framework?

Usually the risk or AI governance committee, with security, the AI platform team and legal consulted. Name the approvers in Part 2.

Where can I test page-level enforcement?

Use the free 100-domain sample, then the lookup API from $99 a month. See pricing.

Make Part 6 enforceable from day one

Page types for 40M+ domains, checked before every agent request.

Download the sample

AI Agent Governance Framework Template