From Atlas experiment to Airlock: extracting agent governance into a product

Airlock is the authorization system we built to govern what AI agents do in company tools. It began inside Atlas, our AI coworker in Slack, and we moved it into a standalone application so other agents could use the same policy checks.

At Agent Night on August 12, Aaron Tainter demonstrated Airlock with a custom agent connected to Gmail and Linear. The agent could send a routine planning update, but Airlock blocked a message containing financial information and requested approval for a send to an unfamiliar distribution list. The agent continued to choose how to do its work while Airlock checked the actions it proposed.

An organization may use several agents, each with its own interface and way of carrying out a task. Airlock gives IT and security teams a place to define the rules those agents must follow when they act through company integrations. Separating those rules from the agent application is what allowed the governance work in Atlas to become a product of its own.

What an email connection leaves undecided

Consider an employee asking an assistant to read planning issues in Linear and email an update to their manager. The assistant needs access to both services, and the provider permissions need to allow the reads and the send. Those permissions establish which operations are available. The company may also have a rule about what information can appear in the email, or which recipients require approval.

Aaron's demo showed why the contents of a request matter. When he asked the agent to summarize a Linear issue about LLM token usage, it found the issue and composed an email. Airlock denied the send because the summary contained token-spend information, which the configured policy treated as financial data. Reading the issue was permitted; emailing its contents violated a separate rule.

The distribution-list example required a different check. Aaron's policy called for IT-admin approval when sending to a list that had not previously been used from the mailbox. Airlock checked the email history and sent an approval request to Slack. Aaron approved it as an IT admin, and the message went out.

Both decisions concerned actions the Gmail connection had enough permission to execute. Airlock evaluated whether those particular sends were allowed under the company's rules. Keeping provider permissions narrow still matters, but a send permission alone does not express a policy about financial information or recipient history.

Giving other agents the same checks

Atlas provided a place to build the governance engine, but the decisions in the demo did not depend on using Atlas's chat interface. An email could contain prohibited information whether an employee requested it in Slack, in a coding tool, or through a custom assistant. Separating the engine into Airlock let Aaron demonstrate those checks with his own agent harness.

In that arrangement, the agent handles the task: it searches for information, decides what to include, and prepares a tool call. Airlock evaluates the proposed call before it reaches the connected service. The task description gives the check context, while the organization's policies determine what the agent may do with its access.

This gives teams a way to manage policy across the agents they connect to Airlock. For example, a rule against emailing financial data can be managed centrally instead of depending on each assistant's instructions. The integration has to route the relevant calls through Airlock for that rule to apply.

The extraction: the policy core moved across largely unchanged, a machine-facing gateway replaced the chat middleware as the execution surface, and the conversational pieces were deliberately left behind.

Making the task part of the request

A separate authorization service needs enough information to understand what the agent is trying to accomplish. In Aaron Tainter's Airlock demo at Agent Night on August 12, the agent requested a token associated with its intent and used it as it worked. Airlock checked proposed calls against that intent and the configured policies. This gave the authorization check a description of the task even though the agent was running in a different application.

Airlock combines deterministic rules with checks that require judgment. Deterministic rules evaluate structured details such as the API endpoint, HTTP method, and request arguments. They can express restrictions such as allowing draft deletion while denying deletion of other mail. Runtime checks can interpret the contents of a request, as the financial-data rule did in Aaron's demo, or gather context for a decision.

People also need to be able to follow what the agent did. Airlock's activity view recorded the calls and their decisions by session, and approval requests arrived in Slack when a rule required human review. The person responsible for the policy could inspect the work and respond to an approval request without using the agent's own interface.

Evaluating Airlock with your team's agents

Airlock is in early access. If you want to evaluate it, request access with a workflow your team already uses and the tools it needs.