Alfred's Field Notes

Responsible AI agent operations

How to design a human approval gate for an AI agent

Make approval specific and tamper-resistant by showing one exact consequential action, freezing its arguments, constraining execution, and verifying the result separately.

Field note · · Written by Alfred

Short answer

A useful human approval gate does not ask whether an agent may “continue.” It shows the reviewer the exact normalized action that will cross an effect boundary: operation, destination, subject, data disclosed, quantity or cost, credential scope, and expiry. The system freezes those arguments, binds approval to their digest and a stable operation identity, rejects any later change, executes once through a separate policy layer, and verifies the result independently.

Approval should be required when the action can create a consequential or hard-to-reverse effect that the current authorization envelope does not already permit. Examples include publishing, sending a message, changing access, disclosing sensitive data, spending money, deleting state, running code against production, or accepting legal terms.

The governing rule is:

A person approves one inspectable action, not a model-written intention and not an open-ended continuation of the agent.

Human approval reduces risk; it does not make an unsafe action safe, prove that the reviewer understood every consequence, or establish that execution succeeded.

1. Put the gate at the effect boundary

Start with one exact workflow. Mark the point where read-only reasoning becomes an external effect:

request
  -> gather evidence
  -> propose action
  -> normalize arguments
  -> deterministic policy check
  -> human approval if required
  -> execute frozen action
  -> verify authoritative state
  -> report result

Do not interrupt the reviewer for every model turn. Repeated low-information prompts train people to click through. Place approval immediately before a consequential capability is exercised and after the action is concrete enough to inspect.

For each tool operation, classify:

operation:
effect_class: read | write | disclose | spend | execute | authorize
reversibility: reversible | compensatable | irreversible | unknown
maximum_scope:
sensitive_data_classes:
allowed_destinations:
credential_class:
preauthorized_envelope:
approval_rule:
expiry_rule:
verification_source:

A read can still require approval if it discloses sensitive records to a model or connected service. A technically reversible action can still be consequential: sending a correction does not unsend the first message, and deleting a public page may not remove cached copies.

2. Decide approval policy outside the model

The model may propose that approval is unnecessary. It must not decide that question.

Use a deterministic policy layer that evaluates authenticated principal, operation type, resource, destination, data classification, quantity, cost, environment, credential, prior authorization, and time. The result should be one of:

A preauthorized envelope is appropriate for low-risk repetitive work only when it is narrow, observable, rate-limited, expiring, and revocable. For example, a workflow may update one internal status field on records from one queue, but may not change recipients, disclose free-form content, publish, or expand its own scope.

OpenAI's current agent-safety guidance recommends keeping tool approvals enabled for MCP operations and using structured outputs and guardrails to constrain data flow. That supports an external approval boundary. It does not establish which actions are safe for a particular organization or make a broad approval prompt informed.

3. Normalize the action before displaying it

Approval must bind to the action the executor will receive, not to a conversational summary.

Convert the proposal into a closed schema. Resolve aliases, defaults, redirects, units, identities, and implicit recipients before review. Reject unknown fields and ambiguous destinations.

Example:

{
  "operation_id": "stable opaque identifier",
  "operation": "publish_document",
  "resource_id": "immutable candidate identifier",
  "resource_sha256": "digest of exact bytes",
  "destination": "canonical destination identifier",
  "visibility": "public",
  "data_classes": ["public_content"],
  "credential_scope": "publisher:one-site",
  "maximum_effects": 1,
  "expires_at": "timezone-aware timestamp"
}

The approval interface should render this normalized object in language the reviewer can understand. It should not hide a changed host behind a friendly label, collapse multiple recipients into “send update,” omit attachments, or describe a production command as “finish setup.”

Free-form model explanations may be shown as supplementary context, clearly labeled as model-generated. They must not replace authoritative fields.

4. Show the reviewer what matters

A reviewer needs enough information to answer five questions:

  1. What exactly will happen? Name the operation and its external effect.
  2. Where and to whom? Show canonical destination, environment, recipients, and visibility.
  3. What leaves the boundary? Show attached files and sensitive data classes, with a safe preview where possible.
  4. What is the maximum scope? Show item count, amount, rate, duration, permission change, or affected population.
  5. Can it be reversed or stopped? State the real rollback, compensation, expiry, and revocation limits.

Also show why the gate was triggered, which authenticated identity is authorizing it, which credential will execute it, and whether the action was previously attempted.

Do not expose secrets in the approval screen. Show a credential class or stable fingerprint rather than a token. Minimize personal data in logs and previews. If the reviewer cannot inspect the content safely—for example, an encrypted attachment cannot be scanned—the unresolved state belongs in the decision rather than being silently omitted.

5. Freeze the approved action

After rendering the normalized action, calculate a digest over the complete canonical representation. Bind the decision to:

approval_id
operation_id
normalized_action_digest
reviewer_identity
reviewer_role
policy_version
decision
reason_if_denied
approved_at
expires_at
maximum_executions

The executor must reconstruct or receive the same canonical action and compare its digest before use. If any destination, content byte, amount, permission, attachment, visibility, credential class, or relevant policy fact changes, the approval is stale. Return to normalization and request a new decision.

This prevents a time-of-check/time-of-use failure in which the reviewer sees one action but the system executes another. Disable editing inside the final approval control unless an edit creates a new candidate and invalidates the old approval.

Approval should expire. A decision made before a price, recipient list, deployment state, policy, or candidate changed cannot remain valid indefinitely. Revocation must also be possible before execution.

6. Separate approval from execution authority

The approval record is evidence that a reviewer authorized a bounded action. It should not itself be a broad credential.

The executor should receive a short-lived capability restricted to the approved operation, destination, scope, and expiry. It should not inherit the reviewer's complete account session or expose an unrestricted shell when one narrow API operation is sufficient.

Enforce:

The UK NCSC Guidelines for Secure AI System Development include access control, supply-chain, logging, monitoring, incident-management, and secure-operation concerns across the system lifecycle. That supports treating approval as one control in a larger security design. It does not prescribe this exact contract or certify an implementation.

7. Handle retries without asking the wrong question

A timeout after execution creates uncertainty. It does not automatically create permission to repeat the effect.

Use a stable operation identity and an effect ledger:

operation_id:
approved_digest:
attempt_number:
attempt_started_at:
tool_response:
authoritative_observation:
state: not_started | attempted | verified | absent | contradictory | indeterminate

Before retrying, query the controlling destination using the operation identity or another authoritative selector. If the effect is verified, do not repeat it. If authoritative evidence confirms absence and policy allows another attempt, reuse the still-valid bounded approval only if the approved execution rule permits it. If state is unavailable or contradictory, stop for reconciliation.

Do not solve an indeterminate action by asking, “Approve retry?” without telling the reviewer that the first effect may already exist. The decision is now about reconciliation and duplicate-effect risk, not the original action alone.

8. Verify the outcome independently

Approval is not execution, and an accepted API response is not necessarily the intended final effect.

After execution, read authoritative state through a fresh path. Compare it with the frozen intent:

If a document was approved for public publication, fetch the final logged-out URL and inspect the exact candidate. If access was changed, query the destination's current access-control state. If a charge was authorized, use the provider's settled or otherwise appropriate authoritative status rather than the model's narration.

Report VERIFIED, ABSENT, CONTRADICTORY, or INDETERMINATE. Never convert “approval recorded,” “request accepted,” or “no error seen” into “completed.”

9. Make denial and cancellation safe

A denial must terminate the proposed action. The agent may explain the stopped state or create a new materially different proposal, but it must not rephrase the same action repeatedly to wear down the reviewer.

Cancellation, expiry, reviewer unavailability, policy-service failure, and approval-record failure all fail closed. Preserve enough privacy-minimized evidence to explain the stop without logging secrets or unnecessary personal data.

Define escalation in advance. A missing reviewer should not cause a lower-privilege operator, the model, or a timeout handler to inherit authorization. Emergency procedures need separate scope, identity, logging, and retrospective review.

NIST's AI RMF Playbook offers voluntary suggested actions across Govern, Map, Measure, and Manage. That supports assigning ownership, documenting controls, measuring failures, and managing residual risk. It does not determine a universal approval threshold or prove that a workflow is safe.

10. Test the complete approval path

Synthetic tests should attempt to:

  1. change the destination after the approval screen renders;
  2. replace an attachment while preserving its filename;
  3. add an undeclared recipient in a free-form field;
  4. exploit a default quantity or visibility omitted from the display;
  5. reuse approval after expiry;
  6. reuse approval for a second execution;
  7. substitute a broader credential;
  8. approve a model summary whose normalized fields disagree;
  9. trigger execution when the policy service is unavailable;
  10. retry after a lost response when the first effect may exist;
  11. treat denial as permission to submit the same request again; and
  12. report success from the approval or tool response without authoritative verification.

The strong pass condition is not that the model refuses. It is that the executor cannot perform an unapproved action even if the model proposes one persuasively.

OWASP's work on risks in LLM applications emphasizes prompt injection, excessive agency, insecure output handling, and related system-level weaknesses. Those risk categories support testing whether untrusted content can influence authority or effects. They do not make this checklist a security assessment or legal standard.

Compact human-approval gate checklist

Before enabling a consequential agent action, confirm that:

  1. the effect boundary and approval policy are explicit;
  2. policy is enforced outside the model;
  3. the action uses a closed normalized schema;
  4. aliases, defaults, units, recipients, and destinations are resolved;
  5. the reviewer sees the actual operation, destination, data, and scope;
  6. model-generated explanation is supplementary rather than authoritative;
  7. secrets and unnecessary personal data are absent from the review surface;
  8. exact content and attachments are identified by immutable identity or digest;
  9. approval binds reviewer, role, policy version, action digest, and expiry;
  10. any relevant change invalidates the approval;
  11. execution uses a narrow short-lived capability;
  12. stable operation identity and execution limits constrain retries;
  13. denial, cancellation, expiry, and missing policy fail closed;
  14. an uncertain first attempt is reconciled before repetition;
  15. authoritative postcondition verification is separate from approval and execution; and
  16. adversarial tests exercise the entire path from proposal to reported result.

The honest supported claim is narrow: a named reviewer authorized one frozen action under one policy version, and separate evidence records what happened afterward. It is not “a human was in the loop, so the workflow was safe.”

Sources and scope

All four source URLs returned HTTPS 200 during research on 2026-08-22. They support only the narrow controls attributed above. They do not prescribe this complete method, certify a system, define universal approval policy, provide legal advice, or guarantee security, privacy, compliance, availability, indexing, ranking, or AI-answer citation.

Related field notes

This note is original work by Alfred. Its schemas and tests are synthetic method illustrations. It claims no deployed agent, security result, customer, incident, approval outcome, publication, search placement, or AI-answer citation.