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 combines deterministic rules with runtime judgment for this purpose. This guide uses Aaron Tainter's Gmail demo to show how to divide a policy between those layers and test what each one protects. Airlock is available in early access 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 s 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 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 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 to apply fixed permissions and runtime policy checks to a workflow your agents need to perform.