---
title: "How to Add Human Approval to an AI Operating System | Maanav Sunderaraman"
description: "Maanav Sunderaraman explains where AI systems must stop, what evidence people need, and how approval should control downstream action."
canonical_url: "https://maanavs.com/writing/human-approval-ai-operating-systems"
markdown_url: "https://maanavs.com/writing/human-approval-ai-operating-systems.md"
---

# How to Add Human Approval to an AI Operating System

A practical method for deciding where an AI system must stop, what evidence it should prepare, and what it can do after approval.

By [Maanav Sunderaraman](https://maanavs.com/about)

Published: 2026-08-17

Topics: AI operations, Human approval, Governance, Workflow recovery

## Human approval controls authority

AI systems can prepare decisions, but preparation does not give a system permission to act. A person must approve actions that use credentials, change a budget, make a public commitment, or create an irreversible result.

I use approval points to separate automated preparation from human authority. The system can collect evidence, compare options, and prepare a recommendation before it stops. The person can then approve, reject, or request a change.

## Define approval before execution

An approval step works only when the system knows what decision a person must make. Before a workflow starts, I define the action, the approver, the required evidence, and the effect of approval.

The workflow also defines what happens after rejection or when evidence is missing. Clear rules prevent a vague review step from becoming a routine click.

## Block every downstream path

A visible approval button is not enough. Every path that can create the protected action must check the same approval state.

VANTAGE uses this rule for executive briefing work. The system prepares bilingual briefings from approved sources. It cannot send assigned work until an authorised person approves the briefing. It also blocks the final decision record.

The control applies at the point of action, not only in the interface. A retry, schedule, or direct request must pass the same check.

## Keep evidence with the decision

An approver needs enough evidence to make the decision. The review package should include the source material, proposed action, known gaps, and exact version under review.

After a decision, the system records who approved it, what the person reviewed, and which version received approval. The decision record remains separate from assigned work. One record proves the decision, and the other tells people what to do.

## Handle rejection and changed inputs

Rejection is a valid result, so the workflow must preserve the reason and return only the affected work for revision. It should not discard approved evidence or restart unrelated tasks.

Approval must expire when an important input changes. A person approved one version of the evidence and proposed action, not every later version.

AEGIS applies the same rule before it uses credentials, adds a paid tool, or increases a budget. The request remains blocked until a person approves the exact change.

## Test the authority boundary

A successful workflow does not prove that an approval control is safe. Tests must try to bypass the control through retries, schedules, concurrent tasks, stale approvals, and failure recovery.

Each protected path should stop with a clear reason and preserve enough state for a safe restart. When every path blocks correctly, approval controls the system instead of decorating the interface.

## Related work

- [AEGIS](https://maanavs.com/work/aegis)
- [VANTAGE](https://maanavs.com/work/vantage)
- [AI Operations](https://maanavs.com/capabilities/ai-operations)