What is WorkOS Airlock? See how intent-based access control governs AI agent calls, where Pipes fits, and how the email demo turns policy into action.
An agent can read a confidential planning issue in Linear and email it to the wrong audience using two valid API calls. As agents take on work across company systems, authorization needs to account for how they use that access. WorkOS Airlock evaluates agent actions against their intent and your policies before the calls proceed.
This guide uses Aaron Tainter's Agent Night demo to explain where Airlock fits, what it checks, and what your application still controls. Airlock is available in early access if you want to apply this approach to your agents.
Where Airlock sits between an agent and your tools #
In the demo, the agent read Linear issues and sent email through Gmail. WorkOS Pipes supplied those provider connections and managed their OAuth credentials. Airlock sat between the agent and Pipes to decide which calls could proceed.
The agent received an Airlock token associated with its declared intent. It used that token to make governed calls; the Gmail credential stayed behind the gateway. Pipes handled the connection, while Airlock checked the proposed action. Gmail or Linear then executed calls that passed those checks.
That separation matters when a connection has broad permissions. The connected account might be able to delete mail, but an Airlock policy can prohibit the agent from using that ability. The provider's permissions still limit what the account can do. Airlock adds restrictions for the agent's use of it.
Intent gives the task context; policy sets the limits #
Consider the assignment from the demo: read the planning issues in Linear and email an update to the manager. The intent explains why the agent is reading issues and preparing a message. The policy determines which operations and contents are acceptable while it does that work.
Aaron wrote the Gmail policy in natural language. Airlock's Rule Builder translated it into fixed rules for API operations and runtime checks for requirements such as prohibiting financial information in outgoing email. He could inspect the generated policies before creating the rules.
Declaring an intent does not grant an exception to those policies. An agent saying that a message is authorized, or that its recipient has already been approved, does not establish those facts. Airlock's runtime checks can consult relevant context, such as mailbox history, when a policy needs it. The guide to defining agent intent explains this trust boundary.
What changed in the email demo #
A routine planning update went through: the agent read the issues and emailed the manager. When another task asked it to summarize an issue containing LLM token-spend figures, Airlock blocked the send under the financial-data policy. Reading the issue was permitted; disclosing its contents in that email was prohibited.
A third task involved a distribution list the mailbox had not used before. Airlock requested approval from an IT admin. Aaron approved the request in Slack, and the email was sent. Those outcomes followed the policy he configured for the demo; another organization would define its own rules.
Watch Aaron build the rules and run the examples:
The email approval workflow guide follows the and retry in detail, including how approval stays tied to the request.
What to establish before connecting your agent #
Identify the operations the agent needs and route them through Airlock with policy enforcement enabled. Keep direct provider credentials out of the agent's environment; a second route to Gmail would let it bypass the policy checks.
Then test both the permitted work and the actions that should stop. Check the provider result as well as Airlock's decision: permission to send does not prove that Gmail delivered the message, and an allowed summary can still be inaccurate. The Airlock pilot guide walks through that evaluation.
Request Airlock early access with a workflow you want to delegate and the rules it needs to follow.