Values in angle brackets (, , ...) come from the Vericto dashboard: ask the user for them, or copy this prompt from Dashboard → Integrations → Set up with AI, where they are filled in. You are adding Vericto to this data project for the Vericto workspace "": vericto-dbt checks the compiled SQL of a dbt project in CI (it never runs dbt or the SQL), and the Airflow policy checks the rendered SQL of every SQL task before it runs, for the database "" (). Start by checking what is already in place, then only do what is missing or broken. Do not redo steps that already pass. MCP servers you may have: - vericto-account (support, read-only): setup_status, explain_block, search_docs. - vericto (runtime): check_sql, list_rules, show_rule. If vericto-account is not connected, inspect this repository instead and ask me to confirm anything you cannot see. Values (not secrets): VERICTO_API_URL = https://api.vericto.com, VERICTO_DATABASE_ID = , dialect = , Python package version = 0.3.2. Secrets: the API key is ALWAYS read from the environment variable or CI secret named VERICTO_API_KEY. Never ask me to paste it, never print it, never commit it. Step 1 - Check current state. Find which of the two this repository has: a dbt project (dbt_project.yml, target/manifest.json) and/or Airflow DAGs (dags/, airflow_local_settings.py). Check whether vericto is already in the requirements (vericto[dbt] or vericto[airflow]), whether CI runs vericto-dbt check, and whether airflow_local_settings.py calls guard_sql_tasks. If vericto-account is connected, call setup_status and report what already arrives. Only set up the parts this repository has. Step 2 - API keys (a human does this). dbt in CI: ask me to create a key in https://app.vericto.com/dashboard/api-keys with only the scope ci_dryrun:execute and to store it as the CI secret VERICTO_API_KEY. Airflow: a separate key with only the scope proxy:evaluate, stored in the secret backend and exposed to the workers and the DAG processor as VERICTO_API_KEY. Wait for me to confirm. Step 3 - Install. dbt: pip install "vericto[dbt]==0.3.2" in the CI job (no extra dependency; the command is vericto-dbt). Airflow: add "vericto[airflow]==0.3.2" to the image or requirements used by the workers and the DAG processor (Airflow 3.0+, Python 3.10+; Airflow 2 needs vericto[airflow]<0.3, not covered here). Set VERICTO_API_URL=https://api.vericto.com and VERICTO_DATABASE_ID= there too (not secrets). Step 4 - Wire it in. dbt CI job: after "dbt compile" (or "dbt build --empty"), run "vericto-dbt check --format sarif --output vericto.sarif"; exit code 1 means a BLOCKED finding. The dialect comes from the manifest's adapter. Airflow: in airflow_local_settings.py, on the DAG processor and the workers: from vericto.airflow.policy import guard_sql_tasks def task_policy(task): guard_sql_tasks(task) Every common-sql task then has its rendered SQL checked when it runs; a BLOCKED statement fails the task before anything runs. Show me the diff before applying it. Step 5 - Verify (nothing is executed). dbt: add a temporary model models/vericto_setup_probe.sql containing "DELETE FROM vericto_setup_probe", run dbt compile and vericto-dbt check, and expect exit code 1 with the statement BLOCKED. Remove the file; do not commit it. Airflow: on a worker, run python -c "from vericto import Vericto, VerictoBlocked; Vericto().enforce('DELETE FROM vericto_setup_probe', '')" and expect VerictoBlocked (a VerictoConfigError means a wrong key, scope or database id). Then call vericto-account.explain_block on the report or event and summarise it in two sentences. Step 6 - Enforce (I decide). Make the dbt check required for merging only after I agree. Leave the Airflow fail mode closed (if Vericto cannot answer, the task fails and is retried) unless I ask otherwise. Do not change the workspace's enforcement mode yourself. Finish with a checklist: keys, install, CI step, Airflow policy, probe results.