Checklist: Agent Governance

With the rapid expansion of AI agents, thinking about security on an organizational level is more important than ever. That’s what governance is for. Now it needs to adapt to the speed, complexity, and uncertainty of AI. 

This is a companion piece to our Operations checklist, and both are equally important.

• Governance Checklist: Decides what you allow
• Operations Checklist: For the day-to-day

While other checklists in this series describe controls, Governance is more of a meta-layer that examines whether anyone has to follow certain requirements. Ideally, this includes evidence that a control runs, not just exists. Policy, in other words, is not enough. 

With agents, we’re taking the age-old Bring Your Own Device (BYOD) problem to the extreme. That was about enabling work on devices that run approved software alongside whatever the user brings in from outside. Nowadays, even approved platforms might suddenly include agentic capabilities after the platform provider flipped a switch, without making them visible to your systems. 

And unlike before, you have to govern at the agent level because risk changes from agent to agent on any given platform.

Phase 1: Scope

"Agent" is defined in writing in a way that can be tested.

• The test leads two people to the same conclusion for edge cases like workloads without a model underneath.
• Every reviewer decides for themselves.

There is a unified inventory, and you know how complete it is.

• A single registry, together with a schedule for finding and adding new agents.
• A registry that’s updated on a whim.

Vendor-embedded agents are part of the unified inventory.

• Agents that were switched on in existing SaaS are listed beside the ones you built.
• The inventory covers only what you built.

Procurement asks about agents before signing a new vendor.

• You can evaluate what the vendor's agent reaches in your tenant, under whose identity it operates, whether you can turn it off, and what it logs.
• You learn about a vendor's agent from a release note.

Agents are risk-tiered, with requirements for each tier.

• There are tiers keyed to what the agent can do irreversibly and what data it reaches, each with its own set of controls.
• One set of controls for everything.

Agents that create other agents are in scope.

• The policy and inventory cover agents configuring or spawning agents.
• Only human-created agents are governed.

Phase 2: Decide

A gate exists before production, and you know it works.

• You have an approval step with at least one recorded rejection or forced change.
• The only gate is a rubber-stamped form.

Builders have access to standards and best practices.

• Builders can self-assess during the planning and building.
• Reviewers decide based on whims.

Someone can refuse, and they’re listened to.

• A named role that can block or stop an agent, with an escalation path.
• Governance can only issue recommendations.

Exceptions expire and are counted.

• Every exception carries an owner, a reason, and a date it goes away.
• Exceptions are indefinite, granted without a named owner.

Someone accepts the risk and is accountable for it.

• For every agent that’s allowed to operate as an exception, you know the name of the person who accepted that risk.
• Exceptions have owners but no risk acceptor counterparts, so there’s no accountability.

Regulatory classification is decided per agent.

• Every agent is assessed at registration and classified into a risk category.
• One company-level determination for every agent.

The policy names actions that no agent performs.

• A short list of actions that are too dangerous for exceptions exists.
• Anything can be approved without a policy change.

Phase 3: Evidence

The current inventory can be produced on demand.

• A dated export was created and can be parsed.
• The inventory will be assembled for the first time when someone asks.

For any agent, you can show who approved what.

• Approval, scope, tier decisions, and live exceptions are easily retrievable for each agent.
• The record is spread across tools, and some of it is missing.

You can show that a control worked.

• There’s evidence of completed reviews, expired exceptions, and retired agents.
• The policy isn’t backed by evidence.

Coverage is reported as a fraction.

• You can show how many agents meet each requirement out of the total, trended over time
• Compliance is a yes/no question.

The metrics reported upward are actionable.

• There’s a short set of metrics, each of which can be acted on.
• Agent count and monthly spend, reported with nothing attached to them

Someone outside the program has tested it.

• An internal audit, a customer security review, or a tabletop exercise identified an issue and changed the program.
• Nobody external has looked, so the first real test is an incident.