AI agents become useful when they can change systems: open a pull request, update a CRM record, restart a service or issue a refund. The same ability makes an unrestricted agent risky. Human approval should be a designed control in the workflow, not a vague instruction in the system prompt.
Classify actions by impact
Separate read-only operations, reversible writes and high-impact operations. Reading a ticket may need no approval. Adding an internal note may need a lightweight confirmation. Deleting data, changing billing, rotating production credentials or deploying infrastructure should require stronger authorization and sometimes a second approver.
Show the exact action before approval
Present the target resource, proposed change, affected environment, expected side effects and rollback path. Avoid a generic “Approve agent action?” prompt. Bind the approval to a canonical action payload or hash so an agent cannot silently change the target after a person approves it.
Make execution idempotent
Approval and execution are separate events. A timeout after a write can leave the agent unsure whether the action succeeded. Use an idempotency key and store the result against that key. A retry should return the original outcome instead of creating a duplicate payment, ticket or deployment.
approval = request_approval(action_digest, approver)
if approval.allowed:
result = execute_once(action, idempotency_key=action.id)
audit.record(approval, result)
Handle expiry and revocation
Approvals should expire. Revalidate permissions immediately before execution because a user’s role or the target system’s state may have changed while the request waited. If the action payload changes, invalidate the approval and ask again.
Keep an audit trail
Record the initiating user, agent identity, tool, resource, action digest, approval decision, approver, timestamps and execution result. Do not store secrets or full sensitive payloads unnecessarily. Make audit records tamper-resistant and searchable by incident responders.
Test failure paths
- Approver rejects or ignores the request.
- Approval expires before execution.
- Permissions change after approval.
- Tool times out after the remote action succeeds.
- The agent retries or submits a modified payload.
Well-designed approvals preserve automation while keeping authority with accountable people. For adjacent controls, read agent runtime control standards and AI agent kill switches.
Engineering considerations
Classify agent actions by impact, reversibility, scope and confidence. Reading a record may be low risk, while changing a production firewall rule or issuing a refund has a larger blast radius. Include the environment and number of affected records in the decision. Define which actions can run automatically, which need one approver and which require two-person review. Revisit the matrix whenever the agent gains a new tool or wider permissions; a harmless test-tenant action can become high impact in production.
Implementation details
An approval screen should identify the requesting user, agent, connected account, target resource and exact proposed change. Explain expected side effects and show a before-and-after diff whenever possible. Include the reason the agent believes the action is needed, but label generated reasoning as a proposal rather than verified fact. A reviewer should be able to inspect the underlying record without copying secrets into the approval interface. Avoid asking people to approve opaque batches of unrelated operations.
Security and reliability controls
Serialize the proposed action into a canonical representation and calculate a digest before presenting it for approval. Store the digest with the approver, timestamp, expiry and policy version. At execution time, recompute the digest and reject the action if a meaningful field has changed. This prevents an agent from obtaining approval for a harmless operation and then substituting a different account, amount or environment. Any change should create a new preview and approval request.
Testing strategy
Use a stable idempotency key for retries of the same approved action. Persist execution state before calling the remote system and reconcile uncertain outcomes by querying the target. A network timeout does not prove the remote operation failed. Distinguish pending, succeeded, failed and unknown states; never blindly repeat a non-idempotent operation. If the upstream system has no idempotency support, create a reconciliation check using a unique operation reference.
Operational monitoring
Approvals should expire and be invalidated when the user’s role, target resource or relevant system state changes. Immediately before execution, re-check authorization, resource ownership and preconditions. A server restart may no longer be appropriate if an incident has been resolved while approval was waiting. Store approvals server-side and never trust a client-supplied boolean flag as proof that a person approved the action.
Failure diagnosis
Design failure handling for rejection, expiry, partial success and tool outages. If a person rejects an action, record the decision and return a concise explanation to the agent. If a workflow partially succeeds across systems, report completed steps and provide compensating actions where possible. Do not label a workflow successful until the downstream system confirms the result. Approval is not a replacement for transaction design, backups or rollback planning.
Rollout and maintenance
Record the request, action digest, policy decision, approver, expiry, execution attempts and final result. Redact credentials and unnecessary personal data. Test tampered payloads, duplicate callbacks, expired approvals, revoked permissions, concurrent approvals and remote timeouts. Include an emergency disable switch for an agent or individual tool. Review rejection reasons to improve the workflow, but never optimize approval rates by pressuring reviewers.
Operational handover
Before handing this capability to an operations team, document the configuration owner, supported versions, dependency map and escalation path. Include the commands or dashboard views needed to verify normal operation, along with the expected values and known limitations. Store configuration in version control, review changes through the normal deployment process and keep a tested rollback procedure. Schedule periodic reviews because upstream components, security requirements and workload patterns change. A short runbook should explain how to identify a failed component, what evidence to collect, which actions are safe to retry and when to escalate. Test that runbook during a maintenance exercise rather than waiting for an outage. Finally, measure the result against a baseline: reliability improvements should be visible in error rates, latency, resource consumption, recovery time or reduced manual work. This makes the implementation maintainable after the original developer has moved to another project.
Example approval policy
A practical policy can map action classes to safeguards: read operations run within the caller’s existing permissions; reversible low-impact changes require a preview and one confirmation; production changes require an authorized operator; and irreversible or financial actions require a second approver. Keep the policy in a versioned configuration file and test it with positive and negative examples. The executor should reject unknown action types by default. It should also check whether the target is still in the expected state, because a person may approve a change that becomes unsafe after another operator has intervened. Keep approval decisions separate from tool execution logs so auditors can distinguish what was authorized from what actually happened.
