Deterministic rules and AI judgment: how Airlock governs agent actions

WorkOS released Airlock in early access, a system that combines deterministic rules with runtime AI judgment to govern AI agent actions, according to a WorkOS guide built on Aaron Tainter's Gmail demo. Airlock evaluates fixed permissions with default deny, runs runtime checks on message content and context, and returns allow, deny, or request approval, denying calls when a required runtime evaluation fails. The design keeps model judgment inside fixed permissions so a favorable runtime verdict cannot reopen a call the fixed rules denied.

Deterministic rules and AI judgment: how Airlock governs agent actions Design AI agent authorization policies with fixed rules and runtime checks. See how Airlock handles allowed operations, sensitive content, and human approval. Once an agent can read company data and send messages, a list of allowed API endpoints cannot tell you whether its next email will disclose confidential information. Authorization needs to check the content of the action while keeping firm limits on which operations the agent can use. WorkOS Airlock https://workos.com/airlock combines deterministic rules with runtime judgment for this purpose. This guide uses Aaron Tainter's Gmail demo https://workos.com/blog/agent-night-recap-airlock-intent-based-access-control to show how to divide a policy between those layers and test what each one protects. Airlock is available in early access https://workos.com/airlock if you want these controls for your own agents. Use fixed rules for decisions the request can settle Aaron's email policy allowed reading mail and deleting drafts, but prohibited deleting received mail. Those are different API operations. A deterministic rule can match the operation and its request parameters without asking a model to interpret the task. A blanket ban on the HTTP DELETE method could also block draft deletion, which this policy permits. The rule needs to distinguish the resources and operations. Review the generated permissions against every way the connection can delete received mail. Airlock evaluates fixed permissions with default deny: a call needs a matching grant, and a matching denial takes precedence. Review overlapping grants too. A broad allow can take precedence over a fixed approval rule, so it should not also match calls you intend to send for review. Use runtime checks for content and context A routine planning update and a message containing token-spend figures both use the send operation. The financial-data policy needs to inspect what the message says. In the demo, Airlock's runtime check blocked the attempted email containing those figures. The distribution-list rule needed another fact: had this mailbox sent to that list before? Airlock could look up the history before deciding whether IT admin approval was required. A claim in the agent's prompt that the list was familiar would not establish that history. Use exact comparisons where they fully express the rule. Reserve runtime judgment for interpreting the request or evidence, such as recognizing financial information even when the amount is written in words. Evaluation flows one way. A deterministic deny or approval requirement ends the decision before the runtime judge is consulted, and on a call that clears the deterministic layer the judge can only keep the yes, hold it for a human, or turn it into a no. Keep the model inside the fixed permissions When Airlock evaluates a fresh call against policy, the fixed rules run first. A deny result stops the call; an approval result pauses it. Only an allow reaches runtime judgment, when that judgment is enabled and an active rule requires it. That policy stage returns allow, deny, or request approval. In pseudocode: decision = fixed rules call if decision = ALLOW: return decision if runtime off or no runtime rules: return ALLOW try: return runtime verdict call, intent except EvaluationUnavailable: return DENY A favorable runtime verdict preserves the fixed allow. It cannot reopen a call the fixed rules denied. If a required runtime evaluation fails, the call is denied rather than proceeding without the check. This is the policy-evaluation sequence. A retry carrying a previously granted approval has its own path and should not be assumed to rerun it. The approval workflow guide https://workos.com/blog/ai-agent-approval-policies-airlock explains that case. Test the boundary each layer is meant to enforce Use a test account and controlled recipients, with enforcement and the intended runtime rules enabled. Delete a draft, then attempt to delete received mail. The second call should stop at the fixed rules without reaching the runtime judge. Confirm that the provider record remains intact. Next, keep the recipient and send operation unchanged. Send a clean planning update, then a message containing synthetic financial data. Try amounts written as words as well as numbers. The clean update should proceed; the prohibited content should stop. This isolates the semantic rule from the operation permission. Check the configuration as well as the verdict. Disabling runtime judgment removes the semantic check, even though fixed rules still apply. Monitor mode can log a would-be denial while forwarding the call. Neither setting demonstrates that the content policy prevented a send. A passing test does not establish that a model will catch every disclosure or resist every prompt injection. Add new failures and attempts to override policy to your test set. The agent policy-testing guide https://workos.com/blog/test-ai-agent-authorization-policies shows how. When a test fails, the two layers help locate the problem. A prohibited operation getting through calls for a rule or routing fix. An allowed send carrying prohibited content calls for better runtime evaluation. You need both boundaries to hold while ordinary work still succeeds. Request Airlock early access https://workos.com/airlock to apply fixed permissions and runtime policy checks to a workflow your agents need to perform.