AI readiness · Snowflake
Snowflake AI readiness assessment
Score your Snowflake estate against the six factors that decide whether data is ready for an AI workload — read-only, metadata only, never a row of your data. Free to run.
Snowflake is unusual among data platforms in that it ships nearly everything a governed AI workload needs: object tagging, masking policies, row access policies, and account-wide usage views that record what is actually in place. The readiness gap on Snowflake is therefore almost never capability. It is adoption.
The assessment measures that adoption directly. ACCOUNT_USAGE records which columns carry masking policies, which objects carry tags, and which tables have row access policies, so the score reflects what the estate genuinely has rather than what the platform is capable of.
The Snowflake readiness tension: uptake — the governance features exist and are largely unused.
What the assessment reads on Snowflake
- ACCOUNT_USAGE governance views — masking policy references, row access policies, and tag references across the account — the uptake question, answered numerically.
- INFORMATION_SCHEMA — tables, columns, types, comments, and declared constraints per database.
- Comments — documentation coverage at table and column level.
- Freshness metadata — last-altered timestamps, which decide whether a corpus is current enough for the workload.
Those signals roll up into the six factors — Clean, Contextual, Consumable, Current, Correlated, Compliant — scored against roughly 50 requirements for the specific AI workload you pick, whether that is retrieval, agents, model training, or feature serving. The output is a readiness score, the single biggest blocker, and a prioritised fix plan with the score gain each fix earns. See the methodology for how scoring works.
Access it needs
A dedicated MORTARIQ_READER role with USAGE on the warehouse, database, and schemas, plus two Snowflake database roles: OBJECT_VIEWER and GOVERNANCE_VIEWER. Flag the second one to your security reviewer honestly — GOVERNANCE_VIEWER opens read-only visibility into account-wide ACCOUNT_USAGE views, which is precisely what powers the masking and policy checks. Everything granted is read-only and revocable. Key-pair auth is recommended: it needs no network policy and survives Snowflake's retirement of single-factor passwords.
-- Run as ACCOUNTADMIN (the SNOWFLAKE database-role grants require it).
CREATE ROLE IF NOT EXISTS MORTARIQ_READER;
GRANT USAGE ON WAREHOUSE <warehouse> TO ROLE MORTARIQ_READER;
GRANT USAGE ON DATABASE <db> TO ROLE MORTARIQ_READER;
GRANT USAGE ON ALL SCHEMAS IN DATABASE <db> TO ROLE MORTARIQ_READER;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE <db> TO ROLE MORTARIQ_READER;
GRANT DATABASE ROLE SNOWFLAKE.OBJECT_VIEWER TO ROLE MORTARIQ_READER;
GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE MORTARIQ_READER;The exact SQL each connector runs is published and generated from source, so a security review is a verification rather than a trust fall. If your warehouse cannot accept connections from the internet, the CLI agent runs the same metadata-only assessment inside your network. Full setup steps live in the connection guide.
The honest limits on Snowflake
- A scan cannot verify values. A masking policy can be attached and still be permissive; the catalog records that it exists, not what it does.
- ACCOUNT_USAGE views have their own latency, so very recent changes may not appear in the first scan.
A metadata scan cannot verify values anywhere: a comment can be stale, a constraint can be worked around in application code, and a fresh-looking table can be full of duplicates. What it gives you is the structural truth of the estate — what exists, what is documented, what is governed, what is fresh, and what your chosen workload requires that is missing. It prepares evidence. It does not certify compliance, and no tool that reads only metadata honestly can.
Frequently asked questions
What access does a Snowflake AI readiness scan need?
A read-only MORTARIQ_READER role with USAGE on the warehouse, database and schemas, plus the SNOWFLAKE.OBJECT_VIEWER and SNOWFLAKE.GOVERNANCE_VIEWER database roles. The two database-role grants require ACCOUNTADMIN to issue and give read-only visibility into account-wide governance views — that is what powers the masking and policy checks. Everything is read-only and revocable.
Why does the scan need GOVERNANCE_VIEWER?
Because masking policies, row access policies, and tag references are recorded in account-wide ACCOUNT_USAGE views rather than per-database ones. Without it those requirements report not assessable instead of guessing. It is read-only, and worth raising explicitly in a security review rather than burying.
Should I use key-pair auth or a PAT?
Key-pair. It requires no network policy and survives Snowflake's retirement of single-factor passwords. A programmatic access token also works but needs a network policy allowlisting our egress IP, which is more setup for less durability.
Get your readiness score.
Connect read-only credentials and see your score and biggest blocker in minutes. Metadata only. Starts free.
Run the free scanWant to see the output before connecting anything? Read a sample readiness report built entirely from metadata. For the deeper technical walkthrough, read the Snowflake assessment post. Other platforms: see all six.