Human-in-the-Loop Approvals for AI Agents

Approvals are how the platform keeps humans in control. An agent can continue routine work, but it should pause when it needs a decision, sensitive access, or permission to change something important.

Common request types

Request	What it means
Human input	The agent needs a decision, answer, selection, or clarification.
Secret request	The agent needs credentials or an environment-style value to use a service.
Contact request	the platform wants permission to communicate with a person or endpoint.
Outbox review	the platform prepared external email that must be reviewed before delivery.
Spawn request	the platform or Meta Agent proposes creating another agent.
Change approval	Meta Agent proposes changing names, charters, links, files, contacts, schedules, or limits.
API tool approval	An API-spec integration holds an exact operation and arguments for a configured approver.
Security rule approval	An Organization security rule held a tool call or HTTP request; an authorized approver decides whether the agent may repeat that exact call once.

How to respond

1. Read the request and the reason.
2. Check the scope: who, what, where, and for how long.
3. Approve only if the request matches your intent.
4. Reject or reply with a narrower instruction when the scope is too broad.
5. Use secrets flows for credentials. Do not paste credentials into chat.

Example response:

Approve contacting Taylor only about the renewal spreadsheet. Do not add Taylor as a long-term contact yet.

Human input requests

Human input requests are ordinary decisions the agent cannot or should not make alone. They may include options or a free-text answer.

Use them to clarify business judgment:

• Which account list should it use?
• Is the draft ready to send?
• Should a finding be escalated?
• Which vendor is the priority?

Credential and secret requests

When an agent needs access, it may request a secret. Secrets are stored outside the chat transcript and can be scoped to an agent or promoted for broader reuse when appropriate.

Use Secrets And Credentials for the full model.

Contact requests

Contact approvals control who can talk to an agent and who an agent can contact. They help prevent accidental outreach.

Before approving a contact request, check:

• The person or endpoint.
• Whether inbound, outbound, or both directions are needed.
• Whether the contact should help configure the agent or only communicate with it.
• Whether the approval should be temporary or long-lived.

See Contact Access And Allowlists.

Outbox email reviews

When an agent's external email policy requires review, the email waits in Outbox until an authorized person approves or discards the exact version. Review the complete recipient list, subject, body, attachments, and warnings before approving. Email approval does not grant contact access.

See Review Before Send for policy options, editing, notifications, expiry, and failed-delivery retries.

Meta Agent approvals

Meta Agent can propose changes across agents, but important mutations should appear in an approval plan before execution.

It should ask before:

• Creating an agent.
• Updating a name, charter, status, schedule, or intelligence setting.
• Connecting or disconnecting agents.
• Sending a brief to another agent.
• Adding or removing contacts.
• Uploading files.
• Archiving an agent.

See Meta Agent.

API tool approvals

An API-spec integration can require approval before a write. Inspect the operation, destination, arguments, and credential context. An authorized approver decides that specific request; it does not authorize later calls. Connection changes or expiry can invalidate the request.

If a request is unavailable or already decided, refresh and inspect its current status. After a timeout, check the provider before repeating a write because the original operation may have completed.

Security rule approvals

If an Organization security rule requires approval, a matching tool call or HTTP request is held and the agent is told it awaits approval. Owners, Admins, and Security Admins review the exact call under Actions awaiting approval in Security rules and either approve one identical retry or decline. Approving does not run the call; the agent repeats it, and any change needs a new approval. The agent's owner cannot approve its own held actions unless the rule allows it, but can still decline a pending request if they are an Organization Owner, Admin, or Security Admin. Requests expire, and a policy change or security halt cancels them. See Security Rules.

Instructions versus enforced controls

A charter saying "ask before sending" guides agent behavior. Contact permissions, Outbox policy, and approval-required API tools enforce their own specific controls. Use the appropriate product control when a workflow requires a mandatory checkpoint, and do not assume a conversational instruction configures all of them.

Good approval language

Add approval boundaries to charters and messages:

• "Ask before contacting anyone outside our company."
• "Ask before using credentials on a new domain."
• "Ask before creating or archiving another agent."
• "Do not start recurring work unless I explicitly approve the cadence."
• "If the daily target is nearly used, summarize remaining work and ask before expanding the scope."

These instructions guide behavior. Configure the relevant product controls for mandatory approvals, and review usage limits and runtime limits separately; a request to ask first does not establish an exact spending cap.

Qualified publication approvals

An optional, default-off Organization profile can restrict external publication to qualified Organization OpenAPI operations. Your administrator must qualify the exact deployment and provider operations before enabling it. Other external routes are refused under this profile, including direct HTTP, external email/messaging, browser, code execution and arbitrary MCP servers. It is not universal business-effect detection.

The initial profile uses fixed OpenAPI credential bindings. Managed machine-identity injection and private identity routes require a later qualified adapter.

Every permitted API call requires independent review of its exact acting identity, destination, operation, arguments and complete bounded content, including calls described as reads. The agent owner and known initiating humans cannot approve. If no eligible reviewer exists, work stays blocked; expiry never approves it.

The Approvals navigation collects source-authorized pending decisions. Labels distinguish an exact retry, a prepared email, a stored API call and ongoing contact access. Approving a stored API call queues one request; it does not confirm publication. Changed material details need fresh review. Unknown API outcomes must be reconciled before new work; they are never replayed automatically. Public API/service credentials cannot substitute for the interactive human review required by this profile.

Capability access, destination approval, content/security rules and human approval remain separate requirements. An ordinary approval cannot override a prohibition, revoked credential or security hold. Contact permissions, generic security retries and Review Before Send retain their existing contracts.