airlock
airlock
Getting Started
Guides
API Reference
Control Room
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, and any one of them can approve the request.

Self-Approval

Whoever may decide a request may decide their own: an organization administrator, or an approver a rule assigned. What self-approval controls is the person who is not otherwise an approver, which is the usual case for the member an agent is working for. For lower-risk operations, enable self-approval on the approval rule and the requester can approve their own request: a confirmation step rather than a second-person review. A request raised because of a soft security block works the same way.

When someone tries to approve or reject a request they are not allowed to decide, the attempt is refused and recorded in the audit history as Approval Refused, with where it came from. A requester whose tool does not allow self-approval is told exactly that, rather than simply that they are not an approver.

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. Microsoft 365 Copilot is excepted even when it declares the extension, because it polls a task without telling the user anything; it receives the polling payload below instead. 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 tells the user about the pending request with its approval link, then checks the airlock/check_status tool with the requestId when the user asks (the response message spells out the call to make). An agent running unattended polls it instead, 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

Opening the record in the target system

When a request acts on one specific existing record, the request page, the Slack message and the Teams card also carry a link that opens that record in the target system itself, for example Open in Odoo for a sale order waiting to be confirmed. That way you can check the record where it lives before you decide.

The link is built by Airlock from two things only: the instance address and database your admin configured on the server, and the record id in the call's arguments. Airlock never contacts the target system to build it, and never turns anything the agent wrote into a link. A link always points at the configured instance and nowhere else.

Today this covers the Odoo integration: confirming, cancelling, posting and validating records, and reading, updating, deleting or messaging a single record. A call that names several records, or creates a new one, gets no link, because there is no single existing record to open.

Anything you do in the target system itself happens outside Airlock. If you confirm the order in Odoo directly, Odoo records that change, and the Airlock request is still waiting for a decision.

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. Deciding 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, as described in "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.