Appearance
Policies
Policies control what happens when an AI agent tries to call an API operation through Airlock.
Policy Basics
Every server has a policy that defines the behavior for each tool.
Actions
| Action | Behavior |
|---|---|
| ALLOW | Execute immediately without approval |
| REQUIRE_APPROVAL | Create a pending request and notify approvers |
Default Policy
When you create a server, all tools default to ALLOW. You can toggle any tool to require approval from the server detail page.
Configuring Policies
From the Control Room
- Navigate to your server's detail page
- Find the Tools section listing all available operations
- For each tool, toggle between:
- Allow - Executes without approval
- Require Approval - Needs human approval before executing
- Changes are saved automatically
Assigning Approvers
For tools set to require approval, you should assign who can approve requests:
- Click Add Approver next to the tool
- Select approvers:
- Individual users from your organization
- Groups for team-based approval
- Multiple approvers can be assigned — any one of them can approve
Self-Approval
For lower-risk operations, you can enable self-approval which allows the user who triggered the request to approve it themselves. This is useful when you want the approval step as a confirmation rather than a second-person review.
Conditional Approval
Policies support conditions that determine when approval is required based on parameter values. For example, you can require approval only when an amount exceeds a threshold:
- If the condition is met, the operation requires approval
- If the condition is not met, the operation is auto-approved
Conditions support numeric comparisons: >, >=, <, <=, ==, !=.
Policy Patterns
Read-Only Access
Allow all read operations, require approval for writes:
| Tool Pattern | Action |
|---|---|
list_* | ALLOW |
get_* | ALLOW |
search_* | ALLOW |
create_* | REQUIRE_APPROVAL |
update_* | REQUIRE_APPROVAL |
delete_* | REQUIRE_APPROVAL |
Full Access with Delete Protection
Allow most operations, but require approval for destructive actions:
| Tool Pattern | Action |
|---|---|
| Most tools | ALLOW |
delete_* | REQUIRE_APPROVAL |
Maximum Security
Every operation needs human approval:
| Tool Pattern | Action |
|---|---|
| All tools | REQUIRE_APPROVAL |
Best Practices
- Start Permissive, Then Tighten: Begin with tools allowed and add approval requirements as you identify sensitive operations
- Protect Destructive Actions: Always require approval for delete and bulk-update operations
- Use Groups: Assign approvers to groups rather than individuals for easier management
- Enable Self-Approval for Low Risk: Use self-approval for operations that need a confirmation step but don't need a second person
- Regular Review: Periodically audit your policies to ensure they match your security requirements
Tool Naming
Tools are named based on the operationId in your OpenAPI specification:
yaml
paths:
/users:
get:
operationId: list_users # Tool name: list_users
post:
operationId: create_user # Tool name: create_userFor pre-built integrations, tool names come from the upstream MCP server and are shown on the server detail page.
Use consistent naming conventions to make policy management easier:
list_*for collection endpointsget_*for single resource retrievalcreate_*for creationupdate_*for modificationsdelete_*for deletion