WorkOS Airlock sits between an agent and provider connections (Pipes): the agent receives an intent-bound token, and provider OAuth credentials stay behind the gateway. Unstealable credentials are not enough if action and content stay unconstrained.
What WorkOS Published
On September 23, 2026, Zack Proser described WorkOS Airlock. WorkOS lists Airlock as early access, with no public pricing yet.
Airlock checks the proposed action and content against policy before the call proceeds. The outcomes are allow, deny, or human-approval. Declared intent does not grant a policy exception.
The Demo Outcomes
WorkOS shows three shapes:
- A routine planning email is allowed.
- An email containing LLM token-spend figures is blocked under a financial-data policy.
- A new distribution list is paused for IT admin Slack approval.
Provider Permissions Still Bound The Account
Provider account permissions still bound the account. Airlock adds restrictions on the agent's use of that connection. Direct provider credentials should stay out of the agent environment — that is the bypass risk.
This extends the thesis in the WorkOS credential-architecture comparison: hiding a credential prevents exfiltration, not misuse. Airlock is the runtime policy gate on top of that gap, not a second comparison of the four architectures.
Companion Context: MCP Authorization Failures
The same day, WorkOS also published four MCP authorization failure shapes against the 2026-07-28 MCP authorization spec. That post mentions LiteLLM CVE-2026-59822 / CISA KEV.
What The Post Does Not Prove
- WorkOS lists Airlock as early access, with no public pricing yet.
- Demo outcomes are WorkOS's illustrations. They are not Institute scores or production incident counts.
- See also the Agent Identity & Know-Your-Agent and agent payments spend-policy playbooks.
- Keeping provider OAuth behind the gateway only helps if the agent cannot reach those credentials another way.
Related: See our notes on WorkOS comparing four agent-credential architectures and WorkOS Airlock.