Airlock documentation

Airlock is the secure, convenient governance layer between your Snowflake environment and the boundless possibilities of AI agents. This Snowflake Native App lets you collaborate safely with agents: you define specs (data contracts and access rules); agents submit validated files and attachments only through a controlled procedure surface—nothing chaotic gets in.

Workflows move submissions to states where agents can no longer alter or delete them. Airlock is also a governance layer between agents—for example, one agent submits reimbursements to a spec while another inspects them against financial and project data you expose in Snowflake. That is one of many patterns you can build with agents (e.g. OpenClaw), Snowflake, and Airlock.

What is Airlock?

Airlock is the governance layer between Snowflake and AI agents—and between agents when you need it. Agents interact through narrow airlock.user.* (and admins through airlock.admin.*) instead of wide-open tables, so validation, access rules, and audit trails apply by default.

A spec combines a data contract with access rules: what fields and attachments count as valid, who may submit or read what. You can even enforce referential integrity against reference datasets you register (shared views, other specs). Integrators and agents use procedures to discover paths, validate payloads, load data, and (where permitted) advance workflow—without blanket grants to underlying tables.

Workflows, agent boundaries, and agent-to-agent flows

Workflows let you move files into states where agents and users can no longer alter or delete prior submissions—open collaboration when you want it, hard stops when the business requires them.

Example (one of many): an agent assisting an employee submits project reimbursements through a spec—dates, project codes, receipt images, or whatever you define. A separate agent, working for the organization, picks up that submission and reconciles it against financial, employee, and project data you choose to keep in Snowflake. Airlock keeps both sides on a controlled, auditable surface. Similar patterns work with agent stacks such as OpenClaw alongside Snowflake.

Administratively, roles, assignments, spec templates, references, retention, licensing, and rebuild helpers run through airlock.admin.* with app_admin. Day-to-day submission and reads use airlock.user.* (app_user and app_admin), with in-procedure checks against in-app roles and assignments. Data lands in structures such as FILE_MANIFEST and history views.

CALL airlock.user.documentation();

Trust model (summary)

• Snowflake application roles — app_admin may call all procedures; app_user only airlock.user.*. Object GRANTs remain the coarse gate.
• Named-license gate — User APIs and Streamlit typically require a named license seat (with optional auto-assign). Admin licensing procedures are the break-glass path.
• In-app roles — core.in_app_roles and core.in_app_assignments drive who sees which specs, files, and history on user APIs.
• Policy decision point (PDP) — Shared authorization behavior for mutations and validation, with consistent reason codes (see product runbooks in the upstream repo where applicable).

Where to read next

The Stored Procedure API v1 page mirrors the contract document: compatibility rules, the admin vs user coverage matrix, per-procedure parameters and returns, and copy-paste workflow examples.