AI Use Policy

Not to be confused with Policies. Tool policies decide whether an individual API call is allowed. The AI use policy is your company's written rules for how people may use AI — the document your members sign.

Your organization can publish a company AI use policy in airlock — the rules your people agree to follow when they point an AI agent at company systems — and require every member to sign it before their agents can run tools.

The policy is versioned, the signatures are recorded as durable evidence, and enforcement is staged so you can roll it out without locking anyone out on day one.

What it is made of

A policy is an ordered list of rules. Each rule has a short title and a markdown body — one rule per topic ("Don't paste customer data into third-party models", "Log every agent-initiated change", and so on).

Only one policy exists per organization, and only one version of it is live at a time.

Authoring and publishing

Policy editing is admin-only and lives under Settings → AI Policy.

1. Open Settings → AI Policy.
2. Click Add rule, or edit the existing ones. Each rule takes a title and a markdown body.
3. Click Save draft. Your edits are stored but nothing has changed for members yet.
4. Click Publish and confirm. The draft becomes the next numbered version and goes live.

The publish confirmation tells you which of two things is about to happen:

• The rules changed — every member is re-prompted to acknowledge the new version, and airlock emails them.
• Only the order changed — the version is published, but nobody is re-prompted and existing signatures stay valid.

"Changed" is compared exactly: rule titles and bodies are matched character for character, so even a whitespace or formatting edit counts as a change and re-prompts everyone. Reordering rules is the only edit that doesn't.

Publishing is guarded against concurrent edits: if someone else published while you had the page open, the publish is refused and you are asked to re-read the current draft rather than silently overwriting their version.

Version history and diffs

The AI Policy tab shows the full published history. Any two versions can be compared, and the diff is expressed in terms of the rules themselves — which are new, which were kept, which were changed, and which were removed — rather than as a line-by-line text diff.

The signature prompt shows a simplified two-state version of the same comparison: each rule is marked new (added or edited) or unchanged. Rules that were removed are not shown there, since they no longer bind anyone.

Review dates

A policy can carry a next review date. When that date arrives, airlock emails your organization's admins to review and re-publish. The reminder is sent once per review date, not every day — advancing the date re-arms it.

Rolling it out

Publishing a policy does not, by itself, enforce anything. Enforcement is a separate, deliberate setting with three stages:

The intended path is Off → Monitor → Enforce: switch to Monitor, watch the would-block count fall towards zero as people sign, then switch to Enforce once the remaining number is small enough to chase individually.

Any organization that has never touched this setting is in Off, so an existing organization cannot be surprised by a policy someone published months ago.

What Enforce actually blocks

Tool execution — the calls that run a real downstream API operation. That means execute_tool, and also airlock_widget on MCP Apps clients, which runs upstream tools through the same pipeline and so hits the same gate.

• Discovery keeps working. list_services, search_tools, describe_tools, activate_skill, and airlock/check_status are unaffected, so the agent can still explain the situation and poll a previously approved call.
• Nothing is sent upstream. The block happens before the tool policy engine and before any credential is used. The response says so explicitly: "No tool call was made."
• Approvals are held, not rejected. See below.

If the policy store is briefly unavailable

The gate fails open: a member's call is allowed through rather than blocked. This is a deliberate availability trade-off — a transient storage blip must not wall off every agent in your organization — and each occurrence is counted, so the periods where the control was not enforcing are visible rather than silent.

For a compliance audit, the durable acknowledgement records are the evidence of who signed what; the fail-open counter is the evidence of when enforcement was degraded.

Rollout timing

• A mode change or a newly published version reaches the MCP gateway within about a minute.
• A member's signature is honoured on their next tool call within about 15 seconds — so a member who signs and immediately retries may still be refused once.

What members experience

In the Control Room

An active member who owes a signature sees a prompt on every authenticated page — it follows them around rather than sitting on one screen they can navigate away from. In Enforce mode the prompt cannot be dismissed until they sign; in Monitor mode it prompts just as insistently but does not claim their access is suspended, because it isn't.

The prompt links to the full policy at /policy, a read-only viewer that every member can open at any time. It shows the current version, what changed in that version compared with the one published before it, their own signature status, and the version history. That page is deliberately exempt from the prompt, so the "Full policy" link actually leads somewhere readable.

Members who have not yet been admitted to the organization (invited or pending) are never prompted — there is nobody to attribute a signature to yet.

In the agent

In Enforce mode, an unsigned member's tool call is refused before it executes. The refusal names the policy version and carries a link to sign, so the agent can relay it and the member can resolve it without leaving their conversation. Clients that support richer surfaces get more than plain text:

• Clients that implement the MCP Apps UI extension can render an in-conversation card showing the current version, its effective and next-review dates, and the diff.
• Clients that implement SEP-1036 URL elicitation are asked to open the signing page directly.

Signing always happens in the authenticated Control Room session. No tool, card, or agent action can record a signature on a member's behalf — an agent that could sign for its user would void the entire control.

Approval-gated calls are held, not lost. Approval defers execution, so a member can be signed when they raise a request and unsigned when it is approved (for example, because a new version was published in between). In that case approving the request is refused and the request stays pending — approve it again once the requester has signed.

Who is exempt

• Service accounts and service tokens are always exempt. They are not people, they hold no Control Room session, and they cannot sign — their tool calls are never blocked by the gate. To keep the governance record complete, an admin can record an acknowledgement on a service account's behalf: it is stored against the currently published version, permanently, with the admin who recorded it named on the record. You cannot back-date an acknowledgement to a superseded version.
• Admins are not exempt. Being an organization admin does not waive the signature.

Email notifications

Two emails ship with the feature.

"Your policy needs your signature" — to members, on publish. When you publish a version that changes the rules, every active member receives an email titled Action required: <policy title> (vN) needs your signature, carrying your change message if you wrote one and a link straight to /policy. It is sent to first-time signers as well as to people re-signing. A publish that only reorders rules sends nothing, because nobody has to re-sign. The mail goes out after publishing completes, so a large organization never slows the publish down.

"Review due" — to admins, on the review date. Set a next review date and airlock emails your organization's admins once the date passes, asking them to either publish an updated version or set a new review date. Admins are Bcc'd, so no admin's address is disclosed to the others. You get one reminder per review date, not one an hour; moving the date forward arms the next one.

Both emails go to the address on the user's airlock profile. Deactivated members and pending invitees are never emailed.

Evidence and audit

Signatures are permanent. Each acknowledgement is stored as a durable record — who signed, which policy version, when — and is never expired or aged out. This is the record you produce in an audit.

The audit log carries a searchable mirror, retained for 90 days, with a longer-lived tamper-resistant archive export. Two entry types matter:

Both are keyed on the policy version, so "who has signed version 4?" and "what did we refuse while version 4 was in force?" are single queries. Refused calls also appear as failed calls with the reason policy_unacknowledged and a 403 outcome.

Monitor mode writes no audit rows on purpose. Nothing was denied, so nothing is recorded as a denial — the would-block count is an operational metric, not an audit entry. Likewise, an approval held back because the requester has not signed produces no denial entry: the request is untouched and still approvable.

API reference

Everything on this page is also available over the REST API, using the same authentication as the rest of the Control Room API.

Troubleshooting