Guides

Approval Workflows

Designate approvers, route pending requests, and act on them from email or the Control Room.

When a policy requires approval, airlock creates a pending request and notifies designated approvers.

How Approvals Work

AI Agent calls tool
       │
       ▼
Policy evaluates to REQUIRE_APPROVAL
       │
       ▼
Pending request created
       │
       ▼
Approvers notified by email
       │
       ▼
Approver reviews and decides
       │
       ├── APPROVED → Execute operation
       ├── REJECTED → Return error to agent
       │
       └── EXPIRED → Auto-expire after timeout

Configuring Approvers

Approval Rules

Set up who can approve requests for specific operations:

  1. Go to your integration's detail page
  2. In the Policy Configuration section, find the tool that requires approval
  3. Set the tool to Require Approval — its row expands to show Approver Configuration
  4. Under Approver Configuration, check the users and groups who can approve:
    • Individual users from your organization
    • Groups for team-based approval

Multiple approvers can be assigned — any one of them can approve the request.

Self-Approval

For lower-risk operations, policies can enable self-approval. This allows the user who triggered the request to approve it themselves — useful as a confirmation step rather than a second-person review.

Default Approvers

If no approver is assigned by a matching rule, any organization administrator can approve or reject the request.

User Groups

Create groups to manage approvers at scale:

  1. Navigate to Settings in the main navigation
  2. Open the Users & Groups tab (admin only)
  3. Click Create Group
  4. Add members to the group
  5. The group will be available when assigning approvers to tools

The Approval Process

For Approvers

When a request needs approval:

  1. Email Notification: Receive an email with request details
  2. Click to Review: Link takes you to the request page
  3. Review Details: See the operation, parameters, and requester
  4. Decide: Click Approve or Reject

For AI Agents

When a tool call requires approval, airlock's response depends on what the agent's MCP client supports:

  • SEP-2663 Tasks Extension — if the request used the 2026-07-28 protocol version and declared the tasks extension on that same tools/call (via _meta['io.modelcontextprotocol/clientCapabilities'].extensions['io.modelcontextprotocol/tasks']), airlock returns a CreateTaskResult instead of the payloads below: a flat object with resultType: "task", taskId, status: "working", createdAt, lastUpdatedAt, ttlMs, pollIntervalMs, and statusMessage (which includes the approval URL). The client polls tasks/get with the taskId — repeating the same declaration on each poll — to check for resolution: when approved, status becomes "completed" and the result includes the tool's output; when rejected, status becomes "cancelled". On an older protocol version the declaration is ignored and one of the surfaces below applies. See MCP Tasks for the wire details, including tasks/cancel.
  • In-agent approval card (MCP Apps) — if the client supports the MCP Apps UI extension (but did not declare the tasks extension), airlock returns an interactive approval card that renders directly in the conversation via the airlock_approval_card tool, so the user can review the pending call without leaving their agent. The card includes a link to the request page in the Control Room as a fallback.
  • SEP-1036 Elicitation — if the client implements URL elicitation (but not the tasks extension), airlock sends an elicitation asking the human user to open the approval URL directly.
  • Polling — otherwise, airlock returns a structured PENDING_APPROVAL response containing a requestId, an approvalUrl, a taskId, and a human-readable message, and the agent polls the airlock/check_status tool with the requestId (the response message spells out the call to make), roughly every 15 seconds.

Once the approver decides:

  • Approved: The operation executes and returns results on the next poll/elicitation completion. For tasks extension clients, tasks/get returns status: "completed" with the tool's output.
  • Rejected: the operation is not executed. For tasks extension clients, tasks/get returns status: "cancelled". For other clients, airlock/check_status returns a REJECTED status (no reason is returned).

Approvers are notified on whichever channels your organization has enabled under Settings → Organization → Notifications: email, Slack, and Microsoft Teams. Email is on by default and can be turned off there. Every notification carries a direct link to the approval page in the Control Room.

Request Details

Each pending request shows:

  • Operation: The tool being called
  • Parameters: Input arguments
  • Requester: Which user's credentials triggered the request
  • Timestamp: When the request was created
  • Status: Pending, Approved, Rejected, or Expired
  • Agent Context: Client name, version, and transport type

Notifications

Each channel has its own on/off toggle under Settings → Organization → Notifications.

Email

Approvers receive emails containing:

  • Operation (tool) name
  • Request ID
  • Direct link to review and approve/reject (full parameters are shown on the request page)

Slack

An admin connects Slack under Settings → Organization → Notifications and picks a channel. Every new approval request is posted there with the tool name, requester, a parameter preview, and the reviewers — assigned reviewers are @-mentioned when their Slack account matches their airlock email. The same message is updated in place when the request is approved, rejected, or expires.

The message carries a link to the Control Room. Approving from Slack itself is deliberately not possible, so approval authority never leaves your authenticated Control Room session.

Microsoft Teams

Connect Microsoft Teams in the same place and pick a team and channel. New requests arrive as an Adaptive Card, and the resolution is posted as a reply in the same thread. As with Slack, the card links to the Control Room; the decision is made there.

Agent Observation

Agents observe the decision via the mechanism they received — see "For AI Agents" above. Clients that received a CreateTaskResult poll tasks/get with the taskId. Other clients poll the airlock/check_status tool (with the requestId) or complete the elicitation, roughly every 15 seconds, until the request resolves.

Request Expiration

Pending requests expire automatically. The default is 24 hours; an admin can change it per integration under the integration's Settings tab → Request Timeout (anything from 1 minute to 30 days).

A background job runs every 5 minutes, so a request is marked expired within about five minutes of its deadline. An expired request is never executed — the agent sees status TIMEOUT when it polls, and the expiry is written to the audit trail.

Best Practices

Quick Response

Set up multiple approvers to ensure someone is always available to respond promptly.

Clear Context

When configuring policies, consider what information approvers need to make decisions.

Audit Trail

All approval decisions are logged:

  • Who approved/rejected
  • When the decision was made
  • The request details

Escalation

For time-sensitive operations, consider:

  • Multiple approvers for redundancy
  • Clear documentation of approval criteria
  • Backup approval processes

Common Patterns

Manager Approval

Create a "managers" group and assign it as the approver for sensitive operations like expense-related tools.

Security Team Approval

Create a "security-team" group for operations that modify or delete data. Assign this group as approvers for all delete_* operations.

Multiple Approvers for Redundancy

Assign both individual users and groups to the same tool. Any one of the approvers can approve the request, ensuring coverage when team members are unavailable.