AI Agent Governance: A Framework a Mid-Market CIO Can Run

You are not governing a model. You are governing a workforce.

AI governance policies written in 2024 mostly regulate content: what employees may paste into a chat window, which models are approved, whether output gets reviewed. Those policies are about people using a tool.

Agents are different. An agent holds credentials, runs on a schedule without a person present, takes multiple steps, and can call other systems. Governing it looks less like an acceptable use policy and more like managing a contractor who has a badge and works nights.

The framework below is what actually gets asked for in a mid-market retail audit, ordered by how early you need it.

Start with a registry, not a policy

You cannot govern what you have not counted. The first artifact is a register of every agent running against company data, with seven fields per entry.

• Owner. A named person, not a team. Teams do not answer pages.
• Purpose. One sentence. If it takes three, the agent is doing two jobs and should be two agents.
• Data scope. Which systems, which tables, read or write.
• Action tier. Read-only, propose-and-approve, or autonomous, using the definitions below.
• Model and provider. Including fallback, because your fallback provider is also a data processor.
• Trigger. Scheduled, event-driven, or user-invoked.
• Review date. Quarterly for autonomous, semi-annually for everything else.

Most retailers who build this register for the first time find between 4 and 15 agents they did not know about. That discovery is the point.

Three action tiers, and the rule for each

Tier 1, read and report. The agent queries, computes, ranks, and notifies. Nothing changes in a system of record. Approval requirement: standard vendor risk review and a read-only credential. This covers roughly 80% of useful retail AI work.

Tier 2, propose and approve. The agent drafts an order, a price change, a task, or a journal entry, and a named human approves before it applies. Approval requirement: everything in tier 1, plus a logged approval record per action and a defined approver role.

Tier 3, autonomous action. The agent writes to a system of record without a human in the path. Approval requirement: everything in tier 2, plus a dollar or unit cap per action and per day, a documented rollback procedure, and sign-off from the business owner and the CIO.

The governance rule that keeps this simple: an agent may only be promoted a tier after running at the lower tier for a defined period with a measured approval rate. Ninety days and 90% is a defensible bar. Promotion by demo is how you end up rolling back.

Every agent gets its own identity

The most common finding in an AI access review is a shared service account used by three agents and two integrations, with a password set in 2023 by someone who has left.

The rule: one agent, one identity, scoped to the minimum tables it needs, with credentials that expire. If two agents share an identity, your logs cannot tell you which one ran the query that matters, which means your audit trail does not exist.

Practically this means service principals or workload identities, short-lived tokens rather than static keys, and a quarterly access review that treats agent identities exactly like employee identities. They are non-human identities and every major identity vendor now has a name for them.

What has to be in the log

The retention question comes up in every vendor review and the answer is usually vague. Be specific. Six fields, per agent invocation:

• Timestamp, agent identity, and trigger
• The prompt or task, in full
• Every query or API call the agent made, in full text
• The output returned to a human or a system
• The model and version used
• The approver, for anything above tier 1

Retain for the same period you retain the underlying system's audit log. If your ERP keeps seven years, an agent that reads the ERP and makes recommendations from it should not keep 30 days.

The query text is the field people skip and it is the one that matters. Without it you cannot answer the only question that will ever be asked, which is "how did it get that number."

The five contract terms to fight for

Governance depends on what your vendor agreed to, and most standard terms are written for a chat product rather than an agent with production access.

No training on your data, stated for the vendor and for every subprocessor model provider they route to.

Named subprocessors with change notice. If they switch model providers, you need to know, because that changes where your data goes.

Data residency and retention at the prompt and output level, not just at the storage level.

Read-only by default, written into the contract rather than left as a configuration choice that a support engineer can change.

Export of your own audit log, so the record survives the end of the relationship. Your obligation to explain a decision outlives your subscription.

What you can skip for now

Mid-market retailers do not need an AI ethics board, a model risk management function modeled on banking, or a bias audit for an agent that monitors on-shelf availability. Applying financial-services model governance to a stockout monitor is how programs die of process.

Scale the governance to the action tier. A tier 1 read-only monitor needs a registry entry, a scoped identity, and a log. That is genuinely it. Save the heavy apparatus for tier 3 and for anything touching customer-level data or employment decisions, where it is warranted and where regulators are actually looking.

How Ward fits the framework

Ward runs at tier 1 by default and tier 2 by explicit configuration. Read-only credentials, one identity per deployment, full query text in the audit trail, exportable, with your own model keys if you want the inference to stay on your provider contract.

The registry entry writes itself, which is the point. An agent you cannot describe in seven fields is an agent you should not be running.