Decide which agent tool calls need human approval

Start with the tool call, not the agent:

Tool action	Data touched	Change made	Approval mode
Search internal documentation	Public or internal reference	None	No approval
Draft a Jira ticket	Project notes	Draft only	Review before save
Update CRM status	Customer record	External business record change	Human confirmation
Rotate an access token	Credential or infrastructure	Security-sensitive operation	Separate break-glass approval

If the team cannot put every tool action into a table like this, the agent is not ready for production use.

The hard part of agent infrastructure is not connecting a model to a tool. MCP and similar patterns make connection easier by standardizing how applications expose context and capabilities to AI systems Model Context Protocol specification. The harder question is whether the agent should be allowed to use a capability without a person checking the intent, input, output, and blast radius.

Treat the approval matrix as infrastructure. It should sit next to the tool registry, runbook, access-control policy, and workflow documentation. A prompt instruction that says “ask before risky actions” is not enough.

Use this when

Use this approach when a team is moving from read-only AI assistance into connected workflows: MCP servers, internal tools, support automations, coding agents, sales operations agents, finance assistants, security triage agents, or any workflow where an AI system can call tools on behalf of a user.

It is especially useful when the workflow crosses system boundaries. Reading a document, drafting a message, creating an issue, updating a record, sending an email, running a command, and deploying code are not the same kind of action. They deserve different controls.

Use it before granting broad OAuth scopes, installing a new MCP server, exposing write tools, or letting an agent chain multiple tools together. The matrix gives reviewers a concrete object to approve instead of asking them to reason about “the agent” as one large system.

Skip it when

Skip this for low-risk personal productivity where the assistant cannot reach company systems, cannot store durable outputs, and cannot act outside the chat session. A personal brainstorming workflow does not need an enterprise approval matrix.

Do not use this as the only control for regulated, safety-critical, legal, medical, employment, high-impact financial, production security, or incident-response workflows. Those workflows need domain review, audit logging, access control, privacy review, and sometimes formal risk governance.

Also skip it when the workflow is still too vague. “Let the agent manage customer follow-up” is not reviewable. “Let the agent draft a follow-up email from a closed support ticket, then require the account owner to approve before sending” is reviewable.

What to do

1. List every tool the agent can call.
2. Split broad tools into specific actions. “GitHub access” is too broad; “read pull request diff” and “merge pull request” are different actions.
3. Record the data each action can read, including customer data, employee data, source code, credentials, contracts, incident details, and unreleased strategy.
4. Record what the action can change: no change, draft, internal record, external message, money movement, infrastructure, permissions, production state, or deletion.
5. Mark whether the change is reversible. A draft can be discarded. A sent customer email, deleted database row, published page, or revoked credential may not be easily reversible.
6. Define the approval mode: no approval, approval before save, approval before external send, approval before execution, two-person approval, or blocked.
7. Decide what evidence the reviewer sees before approval: input, proposed tool name, proposed arguments, diff, destination system, affected record, and rollback plan.
8. Log the decision in a way a later reviewer can inspect. At minimum, log who approved, what was approved, when it happened, and which tool arguments were used.
9. Re-review the matrix when tools, scopes, prompts, vendors, users, or downstream systems change.

The matrix should be boring enough to maintain:

Approval mode	Use for	Example
No approval	Read-only, low-sensitivity lookups	Search public docs
Review before save	Drafts and internal low-risk records	Create draft release notes
Confirm before execution	Durable changes with limited blast radius	Open a support ticket
Two-person approval	Sensitive, expensive, or hard-to-reverse actions	Change billing terms
Blocked	Actions the agent should not perform	Grant admin access

Cost matters. Every approval gate adds delay, reviewer effort, UI complexity, logging requirements, and exception handling. Too many gates train users to approve mechanically. Too few gates turn a useful assistant into an unreviewed automation surface. The practical target is not maximum friction; it is friction at the point where a wrong action becomes expensive, visible, sensitive, or hard to reverse.

Watch the boring risks

The obvious risk is that an agent calls the wrong tool. The more common risk is that nobody notices the tool call has become a business process.

MCP security guidance calls out authorization, consent, token handling, scope minimization, and proxy risks as implementation concerns for connected tools MCP security best practices. Those are not abstract protocol details. They affect whether a user understands what a connected tool can do, whether one client can inherit consent meant for another, and whether downstream systems can tell who initiated an action.

OWASP’s agentic AI guidance frames agent systems as autonomous systems with expanded capabilities and associated risks OWASP Agentic AI - Threats and Mitigations. That framing is useful because agent risk is not only output quality. It includes planning, tool choice, context use, delegation, memory, and execution.

NIST’s Generative AI Profile for the AI Risk Management Framework is voluntary and cross-sectoral, but its practical message applies here: controls should fit the system context, lifecycle, goals, legal requirements, and risk priorities NIST AI 600-1. A small internal draft assistant and a production support agent should not inherit the same approval policy just because both use the same model.

The NSA’s May 2026 MCP security design report highlights risks in production MCP environments including dynamic tool invocation, implicit trust relationships, and context sharing NSA MCP security design considerations. Those are exactly the risks an approval matrix should expose. If the agent can discover new tools at runtime, trust another agent’s output, or reuse long-lived context across tasks, the approval question changes.

Review these failure modes before launch:

Failure mode	What to check
Overbroad tool scope	Can the agent do more than the workflow requires?
Hidden external side effect	Can a tool send, publish, bill, delete, deploy, or notify?
Weak reviewer evidence	Does approval show the exact tool name and arguments?
Irreversible action	Is there a rollback path or a reason to block the tool?
Consent drift	Did a user approve one action while the system reused access for another?
Context leakage	Can sensitive context move into another tool call or log?
Approval fatigue	Are reviewers approving routine low-risk actions all day?

Other ways to handle it

For simple read-only workflows, avoid agent tooling entirely. A search interface, retrieval system, export, dashboard, or internal script may be cheaper to review and easier to secure.

For repeatable deterministic work, use conventional automation. If the same input should always produce the same operation, a typed form, queue worker, or rules engine may be better than an agent deciding which tool to call.

For sensitive work, separate drafting from execution. Let the agent prepare a proposed diff, message, ticket, or command, then hand execution to the existing system with its normal approval path.

For high-risk tool chains, use a dedicated service layer instead of direct tool exposure. The service can enforce schema validation, authorization, rate limits, policy checks, audit logging, and rollback constraints before any downstream system sees the request.

For early experiments, keep the agent in shadow mode. Let it propose actions and compare them with what humans actually do. Do not grant write access until the team has reviewed real examples, rejected outputs, edge cases, and exception handling.

Try this next

Pick one connected agent workflow and write a five-column matrix: tool action, data read, change made, reversibility, and approval mode. If any row says “admin,” “all records,” “send,” “delete,” “deploy,” “credential,” or “production,” require explicit human approval before that tool can run.