Policies

Policies control what happens when an AI agent tries to call an API operation through airlock.

Looking for your company's written AI use policy and member sign-off? That's AI Use Policy — a different feature with a similar name.

Policy Basics

Every integration has a policy that defines the behavior for each tool.

Actions

Default Policy

When you create an integration, the tools it has at that moment default to ALLOW. You can toggle any of them to require approval from the integration's detail page.

Exception: the built-in airlock memory and airlock code graph integrations pre-set their write tools (memory_create_entities, memory_update_context, memory_link_entities, memory_archive_entity, memory_delete_entity, and code_sync) to REQUIRE_APPROVAL when the integration is created.

Tools that a connected server adds later are governed by an organization-wide setting instead — Settings → Security → Newly discovered tools:

The first sync of a newly connected server is never affected; the setting applies to every integration in the organization.

What happens to tools your policy does not mention

Once an integration has a policy, a tool with no matching rule is denied (Access denied: Operation not permitted by policy). Policies are allow-lists — list every tool you want callable.

Prefix wildcards are supported and match on a word boundary: delete_* matches both delete_user and deleteUser. A bare * rule is not a reliable catch-all — it does not match names that continue with a lowercase letter, so * fails to match list_users. Write an explicit rule per tool, or one wildcard per prefix.

An integration with no policy at all allows every tool; deny-by-default only applies once a policy exists.

Who can use an integration

Policies decide what happens when a tool is called. The Access tab on the integration's detail page (admins only) decides who can call it at all — and which of its tools each user, group, or service account may reach.

With no grants, the integration is available to your whole organization; adding the first grant restricts it to the listed principals. See Access Control for the full model.

Configuring Policies

Editing policies requires an organization admin role — other members can view an integration's tools but not save policy changes.

From the Control Room

1. Navigate to your integration's detail page
2. Open the Tools & Policy tab and find the Policy Configuration card listing all available operations
3. For each tool, toggle between:
   • Allow - Executes without approval
   • Require Approval - Needs human approval before executing
   • Hide (pre-built integrations only) — the eye icon on the left of the row. A hidden tool disappears from the catalog agents can list, and any call to it is refused as "not found". Use this to take a tool out of circulation without editing policy YAML.
4. Click Save Changes to apply your policy edits — changes are not persisted until you save

The pencil control on a tool row overrides the description agents see for that tool. Hiding, description overrides, and Mark reviewed are all persisted by the same Save Changes button.

Assigning Approvers

For tools set to require approval, you should assign who can approve requests:

1. Set the tool to Require Approval — its row expands to reveal an Approver Configuration section
2. Under Approver Configuration, check the approvers who can approve:
   • Individual users from your organization
   • Groups for team-based approval
3. Multiple approvers can be selected — 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 any condition matches, the operation requires approval (multiple conditions are OR'd).
• If every condition was evaluated and none matched, the operation is auto-approved.
• If a condition cannot be evaluated, approval is required.

That last rule is deliberate. A condition can't be evaluated when the parameter it references is missing or null, when the value isn't a number where a number is needed, or when the statement doesn't parse. Because the agent controls the arguments, treating an unevaluable condition as "not met" would let a threshold like amount > 1000 be bypassed by simply omitting amount.

>, >=, <, and <= compare numbers only. == and != compare numbers when both sides are numeric and otherwise compare as text, so environment == production works as a condition.

Note: Conditions are configured via the API only — by supplying the policy YAML when creating or updating an integration. The Control Room UI covers the Allow / Require Approval toggle, approvers, and self-approval, but has no editor for conditions (or for DENY and STRIP_UI actions, which are likewise YAML/API-only). Conditions apply to REQUIRE_APPROVAL rules only: DENY and STRIP_UI act unconditionally, and any conditions on those rules are ignored — STRIP_UI also governs surfaces that have no call arguments to evaluate (tool listings and widget resources), so a conditional strip would be unenforceable there.

Important: the Tools & Policy tab rebuilds the whole policy document from the on-screen toggles each time you click Save Changes. Any rule you authored through the API that the UI cannot represent — STRIP_UI actions, DENY actions, conditions, wildcard rules such as delete_*, and custom deny or approval messages — is replaced by a plain ALLOW/REQUIRE_APPROVAL rule per tool. If you maintain a policy in YAML, manage it through the API only, and re-apply it after anyone saves from the Control Room.

Policy Patterns

Read-Only Access

Allow all read operations, require approval for writes:

Full Access with Delete Protection

Allow most operations, but require approval for destructive actions:

Maximum Security

Every operation needs human approval — write one REQUIRE_APPROVAL rule per tool (a bare * rule is not a working catch-all, see above):

Best Practices

1. Start Permissive, Then Tighten: Begin with tools allowed and add approval requirements as you identify sensitive operations
2. Protect Destructive Actions: Always require approval for delete and bulk-update operations
3. Use Groups: Assign approvers to groups rather than individuals for easier management
4. Enable Self-Approval for Low Risk: Use self-approval for operations that need a confirmation step but don't need a second person
5. 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:

paths:
  /users:
    get:
      operationId: list_users  # Tool name: list_users
    post:
      operationId: create_user  # Tool name: create_user

If an operation has no operationId, airlock derives the name from the method and path — GET /users/{id} becomes get_users_id. Names longer than 64 characters are truncated. Policy rules must use the exact runtime name; copy it from the integration's Tools & Policy tab rather than assuming it, because an unmatched rule means the tool is denied.

For pre-built integrations, tool names come from the upstream MCP server and are shown on the integration's detail page.

Use consistent naming conventions to make policy management easier:

• list_* for collection endpoints
• get_* for single resource retrieval
• create_* for creation
• update_* for modifications
• delete_* for deletion