AI Agent Approval Matrix: Decide What It May Do Before It Runs

An AI agent—a system that can use tools to carry out steps across applications—may need access to customer records, email, and a billing system to prepare one follow-up. That access does not settle which actions it may take. The business owner has to decide where reading ends, where a draft waits, and who can authorize a message or record change. An approval matrix makes those decisions before the agent runs on live work.

This is a cross-provider operating guide. Our Copilot agent permissions walkthrough covers that product’s setup; the matrix here applies to the business action regardless of which agent product carries it out.

Separate access from authority

List every system the proposed task touches. For each one, name the data the agent may read, the record or message it may prepare, and the action it may actually complete. A connection that can update a customer relationship management (CRM) record should not make every CRM field available for editing. Limit the connected tool and account to the fields, records, and operations the job needs.

NIST’s AI Risk Management Framework calls for documented roles, oversight, and decisions about whether an AI system should proceed. It does not prescribe one permission ladder for every company. The four rows below are our editorial template for turning that responsibility into an operating choice.

The four rows of an agent approval matrix

• Read: Which approved sources and records may the agent inspect? Name the source owner and access boundary. A search result outside the employee’s own access should stay outside the agent’s answer.
• Draft: What may it prepare without changing a live record or contacting anyone? Identify where the draft is saved, how long it remains useful, and the person who checks factual claims.
• Propose a change: Which exact field, recipient, amount, or setting may it put forward? Show the old and proposed value, the source used, and the expected effect before a person decides.
• Act: Which narrow actions may run after approval, and which must stay with a person? Name the approver, the permitted target, the action limit, the record of the decision, and the way to stop further actions.

Sending an external email, issuing a refund, changing account ownership, and deleting a record do not have the same consequence. Put each in its own row if the owner, review evidence, or recovery path differs. A blanket “human approval required” cell leaves a reviewer unsure whether approving a draft also authorizes sending it. If one agent hands work to another, the same action rule must follow the handoff.

A worked example: the weekly customer follow-up

Consider a fictional team preparing follow-ups for accounts with unresolved service requests. The agent can read the approved account list and current request status. It can draft a short update and propose a next-contact date. It cannot invent a resolution, send the message, or change the account owner. The account manager checks the status against the source record, approves one named recipient and final message, and sends it through the ordinary email system. The CRM stores who sent it and which request it concerned.

If the source request is closed after the draft is made, the proposed message is stale. The approval should expire or recheck the status before sending. If the agent sees two possible recipients, it should stop and ask the account manager rather than choose the more likely address. These cases test whether the boundary survives ordinary changes in work, not just a clean demo.

Make the approval request worth reviewing

A reviewer should see the exact target, the old and proposed values when a record changes, the source and its date, the consequence of approving, and whether any part of the job has already run. The approval should identify this one action or a clearly limited set of actions. Record the reviewer, decision, time, and resulting external record ID. A vague “continue?” prompt cannot support a meaningful decision.

OpenAI’s Agents SDK documentation describes tool calls that pause for approval and resume after a decision. That is an implementation example, not evidence that every connected product automatically enforces the same boundary. Microsoft warns that its computer-use agent’s probabilistic requests for human review may not appear every time a person would want one. For consequential actions, enforce the boundary in the tool, workflow, or account permissions as well as in the agent’s instructions.

Test the matrix before live use

Replay cases with a correct record, a stale record, two plausible recipients, a missing approval, a changed amount, and an approver who lacks authority. Verify the agent reads only permitted sources, the proposed action shows enough detail, and denied or expired approvals cannot be reused. Test the connected account directly: if the agent can bypass the review by calling another tool or route, the matrix is only a document. Version the matrix when a connector, tool, role, or business rule changes; name the owner and next review date.

During a small pilot, count eligible cases, drafts, proposed actions, approvals, denials, wrong-target attempts, and completed actions. Keep the accepted outcome and review time beside those counts. Our AI pilot scorecard gives the broader scale-or-stop decision. Do not expand the agent when the approval queue has no owner or the team cannot tell which actions actually happened.

The decision to make on Monday

Choose one recurring job. Put its systems and four action rows on a page with a business owner, source owner, approver, and stop condition. Give the agent read and draft rights first; add one proposed action only after the team can review its exact effect. Before an agent changes live work, rehearse what happens if the action partly succeeds. Our agent recovery guide covers that next decision.

Source note: The NIST framework supports the need for defined responsibilities and risk decisions. The OpenAI and Microsoft pages describe current product mechanisms and limits as checked October 3, 2026. The four-row matrix and customer example are our operating template, not a vendor standard or a reported customer result.