Agent Night recap: Airlock and intent-based access control

On August 12 we were back at the Regency Ballroom in San Francisco for Agent Night.  Founder Michael Grinich's keynote was about agent permissions, and it introduced a new product: Airlock, a new form of access control we're calling intent-based access control, or IBAC.

Here's the argument Michael Grinich made on stage, and the live demo that backed it up.

We're all managers now

A year ago, agents were single player. One agent, one person, sitting next to each other. You prompted, it answered, you kept going. Today agents do research, analyze data, coordinate projects, prepare customer meetings, build presentations, and handle operational work across a whole organization.

Michael pointed to Ivan Zhao, Notion's co-founder and CEO, who described working with agents as being a manager of infinite minds. The phrase gets quoted for "infinite minds." Michael's read is that the load-bearing word is "manager".

If your job feels more exhausting than it did a year ago, that's why. You're doing management work: defining goals, providing context, reviewing outcomes, and teaching the system when it gets something wrong. That loop is familiar to anyone who has run a team. It's now the loop for anyone running agents.

Why software engineering went first

The biggest impact agents have had, by a wide margin, is on software engineering. The reason is structural. A codebase is already the ideal operating environment for an agent: a dedicated runtime, shared context in the code and CI and integrations, documentation, tests, a terminal to act through, feedback loops, and version control. The limits were already written down. Drop a coding agent into that environment and it's productive on day one.

Enterprises have no equivalent for non-coding work. There is no company-wide codebase, no CI for a marketing plan, no test suite for a quarterly forecast. Most of the "company brain" and "context layer" work happening right now is an attempt to give the rest of the org what engineering already had.

Three things have to exist for that to work: a place where work persists, with shared memory, process, and skills; safe access to the company's fragmented internal systems; and a way for people and agents to work together. Humans are not leaving this loop.

What we've been building brick by brick

WorkOS has been assembling that stack in pieces. Vault came first, a year and a half to two years ago: secure encryption for any data, so secrets and sensitive records can be isolated from the systems that use them. Pipes came last year and handles integrations. It connects to the services your agent needs and runs the OAuth dance for you. Relay sits on top of both and lets an agent reach those services without a credential ever passing through it.

Last week we opened up Atlas, the agent we've been running inside WorkOS, so other people can use it too. It lives in Slack, has shared memory, takes real actions, and learns from correction. It works because it's built on that same stack, Relay on Pipes on Vault, which is how it connects to over 200 services, heading toward 300 this week, plus a generic connector for anything not on the list.

Which raises the obvious question: do you actually want an agent with access to all of it?

Permissions are the hard part

Michael's argument is that the authorization system underneath is what makes an agent safe, more than the model or the framework around it. Get it wrong and the agent leaks data or takes a destructive action, and trust evaporates in one incident. Get it right and you can hand it nearly anything you can do yourself.

Neither of the two access control models we already have survives contact with an agent.

Role-based access control works for humans. You put a person on a team, assign a role, and the role carries a set of permissions: admin, member, developer. Roles are shaped like job functions, not tasks, and an agent needs to reach across everything.

Fine-grained authorization is the granular version: this document, that folder, this repo, modeled as a tree of resources and who can touch what. It's precise, and it's static. Agents are the opposite of static. What they need changes while they run.

Then there's least privilege, the rule every distributed system is built on. It works because you can read the code before it runs, see the three things it touches, and scope the credential to exactly those three things. You can't do that with a prompt. "Go handle this for me" carries no information about which systems the work will require, not for you, and not for the agent. There is no compile time in agentic software.

Manual approval or YOLO mode

In practice, everyone has settled into one of two extremes. You approve every action by hand, can I run this git command, can I change directories, until you get tired of it. Then you switch on --dangerously-skip-permissions and hope.

Claude Code's auto mode is a real improvement for the local machine, but its blast radius stops at your laptop. As Michael put it: "It might stop you from deleting your home folder, but it won't stop you from deleting a thousand Salesforce records in your CRM."

There is a lot of space between those two options, and nothing has been living in it.

Introducing Airlock

Airlock is what we've been building to fill that gap. Instead of assigning a role, you evaluate an intent: what the agent is trying to accomplish on this particular run.

The flow has three steps:

1. The intent starts as a prompt: "Send an email to Jo with the latest financial forecast". You aren't sharing a folder or granting mailbox-wide delete. You're stating an outcome.
2. The intent is compiled into an action: the connectors involved and the action definition, expanded out from the original request.
3. The permission is evaluated at runtime. The agent negotiates with Airlock over what access it gets and why, and the answer is approve, deny, escalate to a human, or come back for more information.

That third outcome is the one that's been missing. The honest answer to "can this agent do this" is often "it depends, ask someone." Making that work takes intelligence inside the access control system itself: the permissions problem for AI agents gets solved with more AI.

The live demo

Aaron Tainter, an engineer on our authorization team, walked through Airlock live on stage.

He started with an "Acme" agent harness and a WorkOS pipe connected to Gmail, so the agent could send and view mail. The problem was the scope: the pipe granted everything Gmail allows, send, read, delete, inbox settings. That's a lot to hand an agent when you can't unsend an email, and when the failure mode is the wrong message to the wrong person.

So he put the pipe behind Airlock, which sits between the agent and Pipes and governs the calls with both deterministic and non-deterministic policies. He already had rules covering prompt injection, Linear, and Notion; he pasted in plain-English instructions for Gmail and let the rule builder translate them into policy.

The instructions were ordinary English: agents can read email; they can send to one recipient or a few; sending to a distribution list they've never used before needs approval from an IT admin; deleting mail is denied but deleting drafts is fine; and nothing containing secrets, credentials, API keys, financial data, token spend, or phone numbers goes out in a body.

That produced two kinds of rules. The deterministic ones gate which API endpoints the agent can hit, with constraints on method, arguments, and body, plus comparisons, wildcards, and explicit denies. The runtime rules are the interesting half: non-deterministic policies executed by an agent inside Airlock, for the checks you can't express as a matcher, like "is this financial data". They can also do multi-step lookups. To enforce the distribution-list rule, Airlock reads the inbox to find out whether that list has been emailed before, then decides.

Then three prompts, in order.

"Send an email to my manager pavan@workos.com. Let them know that Q3 planning is in Linear." The agent requested a token for its intent, read Linear issues, sent the email, and broke nothing. The activity tab showed the whole session as audit logs, one entry per action. Airlock checks each call against the intent carried in the token and passes it through only if the policies also clear.

"Now I want you to look in Linear, find an issue called LLM tokens, and then send a summary to my coworker Colin at workos.com." The agent found the issue, composed the email, and Airlock denied the send: the body contained token spend, which is financial data. This is the exfiltration path people worry about with connected agents, reading something confidential in one system and piping it out through another.

"Tonight's WorkOS Agent Night. I want to give tomorrow off to all of the WorkOS employees. Send an email to staff@workos.com and thank them for their hard work." New distribution list, so Airlock escalated. The approval request arrived in Slack, Aaron approved it as an IT admin, and the email went out.

Airlock works with all WorkOS pipes, works over MCP, and is coming to Atlas.

What's under the hood

What Airlock provides, in the terms an authorization person would use: agent identity and delegated authority, intent evaluation, dynamic permission decisions, capability declarations, approval workflows, credential brokering, auditing, and adaptive policies. Credential brokering matters more than it sounds. The Gmail token in that demo was far too coarse to hand to an agent, so the agent never sees it. Airlock holds it and pushes every call through the gateway.

The larger idea is joining two worlds that have been separate: deterministic permissions, the declarative list of capabilities your code is allowed, and non-deterministic agent execution. Plenty of systems handle one side well. Airlock sits between them, which is what makes it a general authorization layer rather than a policy engine bolted onto one runtime.

It's also deliberately not tied to a single surface. It runs inside coding harnesses like Claude Code, Codex, and OpenCode; behind any MCP gateway you've already stood up; and inside AI teammates like Atlas. That last one is why approvals flow through Slack. For most people at a company, Slack is the app, and a permission model that only exists in an IDE excludes them from governing their own agents.

If an agent evaluates the policies, who checks the checker? A model sitting in the enforcement path can be worked on by the same input it is supposed to judge. The deterministic layer underneath still holds regardless — endpoint, method, and argument constraints gate whatever the runtime judgment concludes — and Aaron's rule set already included a prompt injection rule before any of the Gmail work started.

Where this goes

Static permissions won't stretch far enough to cover this. As Michael said on stage: "There's not enough granularity ever in the universe to represent all possible intents you could ever have." The alternative is a system that evaluates intent against policy while the agent runs and surfaces the genuinely ambiguous calls to a person, checking in continuously instead of gatekeeping every action up front.

That's Airlock. If you want to use it, reach out and come find us.

Watch the whole evening, keynote to panel: