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

What each tool may do is set on the Rules page, per category of the connector (Read, Draft, Write, Send), with single tools kept as exceptions. An integration has no policy of its own.

Settings

The standard answer

A category nobody has set yet takes the standard answer: Read and Draft are allowed, Write and Send wait for an admin's approval. That holds from the moment you add an integration, and the Rules page shows it as the category's setting until someone chooses another.

How Intelligent decides a call

A category set to Intelligent checks each call against your house rules, using a summary of the call's arguments (counts, recipients inside or outside the company, record types), never their content.

• A house rule describes the call: the call gets that rule's answer. A rule like "Export more than 50 records" applies when the call's arguments ask for more than 50 records.
• A house rule names a number of records: airlock checks the number itself, not the model.
  • Before the call, it reads how many records the call asks for from its arguments and from the tool's own definition (its page size, default and maximum). Under "Export more than 50 records", a search that asks for 10 passes, a pull of 500 waits, and a Notion search always passes because Notion returns at most 50. History names the rule it was checked against.
  • After the call, when the arguments can't show the number (a Stripe list that sends no limit, for example), airlock counts the records in what came back. A result over the number is held back and nothing of it reaches the agent: under an Approval rule the call waits for approval, under a Block rule it is refused.
  • Approving runs the call again and passes the result on, unless a Block rule refuses what the re-run returns.
• No house rule describes the call: the call gets the standard answer above, so a read of one page runs and an unmatched write waits for an admin.
• The model is not sure which rule applies, or does not answer in time: the call gets your When it is unsure setting.

Tools that a connected integration adds later are governed by an organization-wide setting instead, under Rules → Connector tool updates:

An organization that chose Require approval before these two answers existed keeps it: the tool is visible to agents, but any call the policy allows needs human approval instead (and self-approval is disabled for it) until an admin clicks Mark reviewed on the tool. Picking either answer moves it off that setting.

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

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, space, or service account may reach.

With no grants, the integration is available to everyone in its home space; adding the first grant restricts it to the listed principals. See Access Control for the full model.

Configuring Policies

What a tool may do is set on the Rules page, in the Connectors row: each category of a connector (Read, Draft, Write, Send) is set to Allow, Intelligent (decided call by call from your house rules), Approval (with who approves) or Block, and a single tool can be kept as an exception to its category. Only organization admins can change it.

The Tools tab shows what a call gets

An integration's Tools tab lists its tools and shows, for each one, what a call to it gets. It is a read-out: nothing on it changes a tool's policy. Only admins see it; members and space owners open an integration on its Settings tab, where their own connection is.

• The marker on the left of each row is the result: allowed, intelligent, needs approval, waiting for review, or denied.
• The chip next to the tool name (for example Write: Intelligent) is the Rules page setting that applies to it.
• Expanding a row names the setting and links to the Rules page.

The Rules page is the only place a tool's policy is set. An integration has no policy of its own: a category nobody has set yet takes the standard answer (Read and Draft allowed, Write and Send waiting for an admin's approval), and the page shows that answer as the category's setting until someone chooses another.

What you can still change on the Tools tab

• Description: the pencil control in an expanded row overrides the description agents see for that tool.
• Mark reviewed: saved the moment you click it, because a review is a decision on its own.

Description overrides are saved with Save Changes on the bar that appears at the bottom of the page as soon as something differs from what is stored. Discard puts every field back, and switching tabs or leaving the page with unsaved edits asks first.

Keeping a tool from agents

To stop agents from using a tool, set it to Block on the Rules page: open the connector's row, open the tool's category, and choose Block next to the tool (or for the whole category). Block applies to every connection of that connector, including ones added later. Agents no longer find a blocked tool when they search or list tools, and any call to it is refused and recorded in the audit log.

There is no separate hide control any more: Block replaced it. Tools that were hidden before were moved to Block.

A tool waiting for review is a different thing: a tool a sync held under Hidden until an admin approves it stays out of agents' reach until you release it under Connector tool updates.

Assigning Approvers

Who approves is set with the Approval setting on the Rules page: yourself (self-approval), the space owner, the admins, or named people, any one of whom can approve. Any organization administrator can decide any request as well.

Self-Approval

For lower-risk operations, choose Self as the approver. The person who triggered the request then approves it themselves, which makes the approval step a confirmation rather than a second-person review.

Conditional Approval

An organization policy document can require approval only for some calls, based on their 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 live in the organization's policy document for a connector, which is written through the API (POST /servers/{id}/policies with scope: "organization"). The Control Room has no editor for conditions (or for STRIP_UI actions, which are likewise API-only). The document only ever makes a tool stricter than its Rules page setting. 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 integration's Tools tab never edits a tool's policy. It shows what each tool gets and links to the Rules page, where a tool's setting is changed. Which tools agents see is set on the Rules page too. Its save bar saves tool descriptions, nothing else.

Policy Patterns

Read-Only Access

Allow reading, require approval for anything that changes data:

Full Access with Delete Protection

Allow most operations, but require approval for destructive ones:

Maximum Security

Every operation needs human approval:

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 the space owner: Choose the space owner as approver, so whoever owns the space a connector is homed in approves its calls
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, so GET /users/{id} becomes get_users_id. Names longer than 64 characters are truncated. A rule in an organization policy document must use the exact runtime name; copy it from the integration's Tools tab rather than assuming it.

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