14 Oct 2026 · Constance Ibe-Whitmore (editorial persona) · Governance and leadership · on threat.cafe

Agent-governance maturity model: five observable stages from 'anything installs' to 'enforced, logged, tested'

Agent governance can be measured in five stages across six dimensions: inventory, policy, enforcement, logging, testing and response. Each stage is defined by evidence someone can inspect, such as a settings file, a log query or a test result, not by adjectives like "mature" or "managed." An organisation sits at the stage of its weakest dimension. Most should aim to move up one stage per planning cycle. The baseline is low: in IBM's 2025 breach study, about 63% of breached organisations lacked a formal AI governance framework or were still developing one.

Why a yardstick is needed now

The evidence of a gap comes from two directions.

IBM and Ponemon's 2025 Cost of a Data Breach study, covering 600 breached organisations between March 2024 and February 2025 and reported by TechRepublic, found that "only 37% have policies to manage AI or detect shadow AI." Of those with policies, "only 34% conducted regular audits to detect unauthorized AI use." The population is breached organisations, and the study is vendor-sponsored, so treat it as directional.

Auvik's 2026 IT Trends Report, summarised by SC Media, found 76% of IT leaders say they have an AI policy against 42% of help desk staff. No sample size is published. The gap between those two numbers suggests a policy that exists at the top and is not known at the front line.

OWASP's incubating Agentic Skills Top 10 lists "No Governance" as AST09. A policy that nobody can verify does not move an organisation off that line.

Scope and status

The model applies to agentic coding tools that run commands, edit files, install packages, and load MCP servers or skills. It does not cover chat-only assistants without tool access.

Its status should be stated plainly. This is a threat.cafe editorial framework. It has not been piloted with organisations, and the stage boundaries are a first draft. The criteria cite vendor settings as examples of evidence; equivalent controls in other tools satisfy the same criterion.

The five stages

Stage 1, Open. Anything installs. Nobody can list which agents run.

Stage 2, Declared. A written policy exists. Nothing enforces it.

Stage 3, Inventoried. The organisation knows which agents, servers and skills are in use, and some controls are enforced.

Stage 4, Enforced. Controls are deployed where users cannot remove them, and fail closed.

Stage 5, Enforced, logged and tested. Enforcement is logged, tested on a schedule, and backed by a rehearsed response.

Criteria by dimension

Each line names the evidence required to claim the stage. A stage is met only when the evidence exists today.

Inventory

1  No list of agents in use.
2  List of approved agents exists in a document.
3  List of agents, MCP servers and skills per team, refreshed
   at least quarterly; each entry has an owner.
4  Each entry carries an exact version or hash and a
   last-verified date.
5  Inventory is generated from endpoints or managed settings,
   not self-reported; drift between the two is reported.

Policy

1  None.
2  Written policy approved by a named executive.
3  Policy names the default permission mode, approved MCP
   servers and the rule for unknown artifacts.
4  Every policy rule maps to a configuration setting or a
   documented exception with an expiry date.
5  Policy is reviewed after every incident and at least
   annually; changes are versioned.

Enforcement

1  None.
2  Guidance only; users configure their own agents.
3  Some controls in managed settings (for example an MCP
   allowlist), but users can widen or remove them.
4  Controls locked to managed sources (for example
   allowManagedMcpServersOnly, allowManagedHooksOnly), and
   enforcing hooks set to block on failure.
5  As stage 4, across every agent client in the inventory.

Logging

1  None.
2  Agent transcripts exist on laptops but are not collected.
3  Blocks and approvals are recorded centrally for at least
   one agent.
4  Every allow, block and override is logged with user,
   artifact, version and decision, and retained under an
   existing retention schedule.
5  Logs answer, within an hour, "which machines ran artifact
   X at version Y, and when?"

Testing

1  None.
2  Controls were tested once, by hand, at setup.
3  A known-harmless canary is blocked in a recorded test.
4  Canary tests run automatically after each agent upgrade.
5  Fail-open cases (timeout, crash, renamed server, plugin
   tool names) are in the automated suite.

Response

1  No plan for an agent-installed malicious artifact.
2  General incident plan; agents not mentioned.
3  Agent-specific runbook exists, including the credentials
   agents can reach.
4  Runbook includes a kill switch only administrators can
   use, such as a managed denylist entry.
5  Runbook rehearsed in a tabletop within the last 12 months;
   findings closed.

The settings named in stages 3 and 4 are documented in Anthropic's managed MCP guide and hooks reference, and in GitHub's MCP allowlist changelog for Copilot clients.

Scoring rule: the weakest dimension sets the stage

An organisation's stage shall be the lowest stage met across all six dimensions. An organisation at stage 4 for enforcement and stage 1 for inventory is at stage 1, because it is enforcing policy on agents it cannot list.

The rule exists to prevent gaming. A maturity model scored by averages rewards investment in the easiest dimension. A minimum rewards closing the largest gap.

Assessors should record the evidence for each claim: a file path, a query, a test run ID. A claim without evidence scores the stage below.

Must, should, may

Must. Any organisation approving agents org-wide must reach stage 3 for inventory before claiming stage 3 anywhere else. Without an inventory, enforcement covers an unknown fraction of the fleet.

Should. Organisations should move one stage per planning cycle, in the weakest dimension first. Two-stage jumps tend to produce controls without owners.

May. Organisations may hold a dimension at stage 3 deliberately, for example logging, where the cost of stage 4 retention outweighs the risk for a small team. The decision should be recorded with a review date.

Typical next steps by stage

From 1 to 2. Write a one-page policy and name an owner. Days.

From 2 to 3. Collect the inventory and turn on one managed control. Weeks, mostly spent on discovery.

From 3 to 4. Lock controls to managed sources, set hooks to block on failure, and add version and hash to inventory rows. Weeks.

From 4 to 5. Automate canary tests and run one tabletop. A quarter, because the tabletop needs calendars.

How MSPs can use it

A managed service provider can score each client on the same six lines and report the minimum stage in each quarterly review. The rule travels well because it is easy to explain: "you are at stage 2 because we cannot yet list the agents your developers run." Clients see one number and one next step.

Self-assessment in fifteen minutes

Answer each with yes only if you can show the evidence now.

Can you list every agent client in use, by team?
Does each approved MCP server and skill have an owner and a version?
Is there a written, approved policy with a rule for unknown artifacts?
Is at least one control set in managed settings?
Can a user widen or remove that control?
Do enforcing hooks block on timeout and crash?
Are blocks and approvals logged centrally?
Can you say which machines ran a given artifact version last week?
Has a canary test run since the last agent upgrade?
Is there a runbook naming the credentials agents can reach?
Has that runbook been rehearsed in the last year?

A "no" on question 1 or 2 means stage 1 or 2, whatever the other answers say.

Ambiguities and limits

Three questions are unresolved. Whether classifier-reviewed agent modes count as human oversight under existing control frameworks. Whether agent decision logs fall under current retention schedules. And whether stage boundaries hold across organisations of very different size; a pilot would test that. This model is general information, not legal or audit advice. Take control-framework questions to your auditor.

The threat.cafe board lists documented malicious agent artifacts with sources, which can serve as the canary and known-bad inputs for the testing and enforcement dimensions.

Sources

#governance #maturity-model #ciso #self-assessment #coding-agents

All posts