From Approval Button to Control Plane: Implementing Human Review for AI Agents

Human approval is not useful just because a workflow pauses.

It becomes useful when the system can prove what was proposed, why review was required, who reviewed it, what evidence they saw, what scope they approved, what executed, and whether the outcome matched the approved intent.

That is the difference between an approval button and an approval control plane.

The first article in this series focused on the approval design problem: scope, timing, timeout behavior, exception routing, and decision paths. This article moves into implementation. It looks at the architecture patterns needed to make human review enforceable when AI agents can actually act across enterprise systems.

The core idea is simple:

The agent may propose an action, but the approval system must control authority.

That means approval cannot live only in the prompt. It cannot live only in the chat interface. It cannot depend on the model remembering what it was allowed to do.

A production-ready approval path needs policy, evidence, enforcement, audit, and ownership.

Approval Needs an Enforcement Point

A common anti-pattern is to give the agent direct access to tools and ask it to request approval before using them.

That relies too much on the agent behaving correctly.

A safer design puts an enforcement point between the agent and the target system. That enforcement point may be a tool broker, workflow orchestrator, API gateway, automation service, or custom control layer.

The name matters less than the responsibility.

The enforcement point should:

• Inspect proposed tool calls.
• Classify action type and risk.
• Check policy.
• Require evidence.
• Route approvals.
• Enforce the approved payload.
• Block unapproved or modified actions.
• Log the decision and execution result.
• Preserve audit records.

The agent can reason and propose.

The control plane decides whether the proposed action is allowed to execute.

Control Plane Architecture for Agent Approval

The diagram below shows the pattern. What to notice is the separation of responsibility. The agent does not directly execute high-impact actions. The policy layer evaluates the request, the approval workflow captures the human decision, and the tool broker enforces only the approved payload.

This design gives the organization a place to enforce approval decisions outside the model.

That matters because the model should not be responsible for policing its own authority. It can generate useful plans, but policy enforcement belongs in a deterministic layer that can validate payloads, permissions, evidence, and state.

The Approval Package: What the Human Should Actually See

Approvers need evidence, not persuasion.

A model-generated explanation can help, but it should not be the only thing a human sees. The approval request should include structured evidence from the workflow, tool broker, policy engine, and target platform.

At minimum, a serious approval package should include:

The human should not have to infer the real action from a short summary.

For example, this is weak:

The agent wants to restart the unhealthy service.

This is much stronger:

{
  "run_id": "run-2026-07-05-10482",
  "incident_id": "INC-10482",
  "tool": "restart_service",
  "environment": "production",
  "target": "api-worker-03",
  "arguments": {
    "restart_mode": "single_instance",
    "drain_connections": true,
    "timeout_seconds": 120
  },
  "risk_classification": "production_operational_change",
  "matched_policy_rule": "require-owner-approval-for-production-restart",
  "rollback_plan": "If health check fails after restart, remove instance from rotation and escalate to service owner.",
  "approval_valid_for": "10 minutes"
}

The first version asks the human to trust the summary.

The second version gives the human and the system an enforceable approval boundary.

Validate the Actual Payload, Not Just the Summary

One of the most important implementation rules is this:

The approved payload and executed payload must match.

It is not enough for the human to approve a natural language description. The approval system should record the exact tool name, arguments, target resource, and scope. The tool broker should then compare the execution request against the approved payload before allowing it to proceed.

This prevents several common failure modes:

A practical enforcement rule might look like this:

Before execution:
1. Confirm approval is still valid.
2. Confirm run ID matches.
3. Confirm tool name matches.
4. Confirm target resource matches.
5. Confirm arguments match approved parameters.
6. Confirm environment has not changed.
7. Confirm policy version is still valid or accepted.
8. Confirm approver had authority for this action.
9. Execute only the approved payload.
10. Record result and post-action state.

This is how approval becomes enforceable instead of symbolic.

Policy as Configuration

Approval rules should not be hidden in an agent prompt.

Prompts are useful for behavior guidance, but they are not a reliable place to define enterprise authority. Approval behavior should be expressed in a policy layer that is inspectable, testable, versioned, and owned.

The following YAML is a vendor-neutral example. It is not meant to match a specific product schema. The purpose is to show how approval behavior can be represented as configuration instead of being buried in a prompt or hardcoded into a button.

apiVersion: dtd.ai/v1
kind: AgentApprovalPolicy
metadata:
  name: infra-remediation-approval-policy
  owner: platform-operations
spec:
  defaultDecision: deny

  evidenceRequired:
    - run_id
    - user_request
    - proposed_tool
    - tool_arguments
    - target_resource
    - environment
    - impact_summary
    - risk_classification
    - matched_policy_rule
    - rollback_plan

  rules:
    - name: allow-read-only-investigation
      match:
        action_category: read
        environment: any
      decision: allow
      audit:
        level: standard

    - name: require-owner-approval-for-production-restart
      match:
        action_category: operational_change
        tool: restart_service
        environment: production
      conditions:
        required_evidence:
          - incident_id
          - affected_service
          - rollback_plan
          - recent_change_summary
      approval:
        scope: single_action
        approver_role: service_owner
        timeout: PT15M
        on_timeout: escalate
        escalation_role: incident_commander
        approval_valid_for: PT10M
      audit:
        level: detailed

    - name: require-change-record-for-production-config-change
      match:
        action_category: configuration_change
        environment: production
      conditions:
        required_evidence:
          - change_ticket
          - dry_run_diff
          - rollback_plan
          - business_impact
      approval:
        scope: bounded_batch
        approver_role: change_authority
        timeout: PT30M
        on_timeout: expire
        approval_valid_for: PT15M
      audit:
        level: detailed

    - name: deny-destructive-production-actions
      match:
        action_category: destructive
        environment: production
      decision: deny
      reason: "Destructive production actions require a separate break-glass workflow."

    - name: break-glass-security-containment
      match:
        action_category: security_containment
        environment: production
        severity: critical
      conditions:
        required_evidence:
          - incident_id
          - security_signal
          - containment_scope
      approval:
        scope: bounded_action
        approver_role: incident_commander
        secondary_approver_role: security_lead
        timeout: PT5M
        on_timeout: escalate
        approval_valid_for: PT5M
      audit:
        level: forensic
        post_action_review_required: true

The important part is not the exact field names.

The important pattern is that approval behavior is declarative. The organization can now answer real governance questions:

• Which actions are allowed without review?
• Which actions require human approval?
• Which actions are denied outright?
• Who approves each action type?
• What evidence is required?
• How long is approval valid?
• What happens when the approver does not respond?
• Which decisions require secondary approval?
• Which actions require post-action review?

That is a very different operating model from “ask the model to get approval before doing risky things.”

Approval as a State Machine

Approval is not a single event.

It is a state machine.

That matters because enterprise workflows are not instantaneous. People step away. Incidents evolve. Tickets change. Resources are modified by other systems. Evidence becomes stale. A safe action at one point in time may not be safe ten minutes later.

A practical approval state model looks like this:

Each transition should have rules.

For example:

This is the difference between a UI pause and a workflow control.

Accountability: The Agent Is Not the Owner

An AI agent can execute a task.

It cannot own the consequence.

Accountability needs to be assigned before the workflow runs. Otherwise, failure creates a familiar enterprise problem: operations blames the tool, security blames the workflow, the business blames IT, and everyone agrees the AI “did something unexpected.”

That is not an accountability model.

A production approval path should define these roles:

The approver is not always the only accountable party.

If a service owner approves a restart based on incomplete evidence, that is one problem.

If the workflow never required a rollback plan, that is a workflow ownership problem.

If the agent had broad credentials that allowed it to exceed the approved scope, that is an identity and policy design problem.

If nobody reviews post-execution outcomes, that is an operational governance problem.

Good approval design makes those boundaries visible.

Operational Implementation Notes

Put a Tool Broker Between the Agent and Target Systems

Do not let the model call high-impact tools directly.

Use a tool broker, orchestration layer, API gateway, workflow service, or automation layer that can inspect requests before execution. This layer should enforce schemas, validate payloads, check policy, attach evidence, verify identity, and record outcomes.

The model can propose a tool call.

The broker decides whether that call may proceed.

Keep Downstream Authorization in Place

Human approval should not bypass identity and access controls.

The tool identity should still have only the permissions it needs. The target system should still enforce authorization. The approval layer should complement IAM, RBAC, change control, and data access policy.

Approval is not a substitute for least privilege.

It is an additional control.

Separate Approval Authority from Execution Identity

The person approving an action and the identity executing the action are usually not the same thing.

That separation is fine, but it needs to be recorded.

The audit trail should show:

• The human or role that approved the action.
• The service identity that executed it.
• The permissions used.
• The target system affected.
• The result of the action.

Without that record, it becomes difficult to understand whether a failure was caused by a bad decision, excessive tool permission, an execution bug, or a target system issue.

Require Post-Action Review for Exceptions

Not every approval needs a meeting.

But some actions should automatically trigger post-action review:

• Break-glass actions.
• Emergency containment.
• Failed execution after approval.
• Actions that required secondary approval.
• Actions involving sensitive data.
• Actions where the executed result differed from expected state.
• Any approval that was escalated because of timeout.

Post-action review is where the organization improves the policy model. It should not only ask whether the agent behaved correctly. It should ask whether the approval path gave the human enough information and whether the control plane enforced the decision correctly.

Testing the Approval Path

Approval workflows need test cases.

If you only test the happy path, the design is still theoretical.

Useful test scenarios include:

These tests should be part of the workflow lifecycle, not a one-time design exercise.

If the approval path cannot handle expired approvals, missing evidence, payload drift, and execution failure, it is not ready for production use.

What Good Looks Like

This is not about slowing down AI adoption.

It is about creating enough control for agents to be useful in real operating environments.

Conclusion

Human approval is not a button.

It is a control plane function.

For AI agents that can actually act, approval needs to be implemented as a governed workflow with policy rules, evidence packages, timeout behavior, enforcement points, audit records, and clear accountability.

The agent should not be responsible for deciding whether its own action is authorized.

The approver should not be asked to approve a vague summary.

The tool layer should not execute anything outside the approved boundary.

The organization should be able to prove what happened afterward.

That is the standard for production agentic AI.

Not “someone clicked approve.”

But:

The right person approved the right action, with the right evidence, under the right policy, for the right scope, and the system executed only that approved action.

That is when human-in-the-loop becomes real.

External References

NIST AI Risk Management Framework Core
https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

NIST AI RMF Playbook
https://airc.nist.gov/airmf-resources/playbook/

OWASP Top 10 for LLM Applications, LLM06:2025 Excessive Agency
https://genai.owasp.org/llmrisk/llm06-sensitive-information-disclosure/

OWASP Top 10 for Agentic Applications 2026
https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

OpenAI API: Guardrails and Human Review
https://developers.openai.com/api/docs/guides/agents/guardrails-approvals/

OpenAI Agents SDK: Human-in-the-Loop
https://openai.github.io/openai-agents-python/human_in_the_loop/

The post From Approval Button to Control Plane: Implementing Human Review for AI Agents appeared first on Digital Thought Disruption.