Airlock and Snowflake: the implementation note

What runs where

Airlock runs as a Snowflake Native App in the customer's Snowflake account. It is not another hosted database placed between an agent and Snowflake.

Snowflake becomes the governed center for accepted submissions, decisions, evidence, workflow state, and history. It does not pretend to replace an external authority such as a payment network, payroll provider, storefront, or government filing system. Those systems still confirm what happened in their world.

Three surfaces, three responsibilities

app_admin / airlock.admin.*

Administer. Create and evolve specs, roles, assignments, references, retention, licensing, and other governed configuration.

app_agent / airlock.agent.*

Act. Discover allowed specs, validate and load data, attach evidence, participate in workflow, use references, and read only what the actor may access.

app_observer / airlock.observe.*

Observe. Inspect procedures, specs, governance maps, access decisions, work, activity, health, and context without changing governed state.

Broad table access is not the integration model. The stored procedures apply identity, assignment, spec, path, workflow, evidence, and delegation rules at the boundary.

A normal submission path

1. 1

   Discover

   The actor lists accessible specs and reads the installed descriptor for the fields, tests, paths, references, attachments, and workflow it must satisfy.

2. 2

   Validate

   Candidate data is checked without becoming an accepted record. Validation errors remain errors; they are not quietly loaded.

3. 3

   Submit

   The actor loads valid data, supplies required evidence, and advances workflow only when its role and the spec permit it.

4. 4

   Observe

   Authorized observers can inspect current work, access decisions, health, and historical activity without receiving mutation authority.

The exact installed app object name can differ. Public examples use airlock; agents should discover and use the customer's installed object and current in-app documentation.

Where MCP fits

Airlock MCP is the local agent workbench and teaching layer. It helps agents design specs and build apps against Airlock contracts.

Today it does not open a Snowflake connection or call installed Airlock procedures. Agents need an approved Snowflake access path to discover and use the installed contract.

It is not the authority. The Snowflake Native App and its stored procedures remain authoritative. An MCP client cannot bypass Airlock's attachment, workflow, access, or delegation checks by choosing a friendlier tool name.