<!-- Vericto setup prompt: Proxy TCP, version 1 (2026-10-16). https://vericto.com/setup/proxy-tcp.md -->
Values in angle brackets (<database_id>, <workspace_name>, ...) 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 setting up the Vericto TCP proxy for the database "<database_name>" (<dialect>) in the Vericto workspace "<workspace_name>".
Vericto is a deterministic SQL firewall: the proxy sits between the application and the database, evaluates every statement against the workspace's rules and blocks, flags or forwards it.

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, diagnose_proxy, explain_block, search_docs.
- vericto (runtime): check_sql, list_rules, show_rule.
If vericto-account is not connected, inspect this repository and infrastructure instead and ask me to confirm anything you cannot see.

Values for this setup (not secrets):
- VERICTO_API_URL = https://api.vericto.com
- VERICTO_DATABASE_ID = <database_id>
- VERICTO_WIRE_PROTOCOL = <wire_protocol>   (postgres or mysql)
- Proxy image: ghcr.io/vericto/vericto-proxy:4.12.3

Secrets: the API key is ALWAYS read from the environment variable or secret named VERICTO_API_KEY. Never ask me to paste it, never print it, never write it into a file that is committed.

Step 1 - Check current state.
Call vericto-account.setup_status with database_id=<database_id> (or look for an existing vericto-proxy service in docker-compose files, ECS task definitions, Kubernetes manifests or Helm values in this repo). Report: is a proxy deployed, is it connected (last rules sync in the last 15 minutes), is the workspace in observe mode. If a proxy is connected and healthy, skip to Step 5.

Step 2 - API key (a human does this).
If no secret named VERICTO_API_KEY exists for the proxy, ask me to create one in https://app.vericto.com/dashboard/api-keys with exactly the scopes rules:read and telemetry:write (nothing else) and to store it in our secret manager or CI secrets as VERICTO_API_KEY. Wait for me to confirm. Do not create keys with other scopes.

Step 3 - Deploy the proxy next to the application.
Detect how this stack is deployed (Docker Compose, AWS ECS, Kubernetes) and add a vericto-proxy service in the same network as the app, using these environment variables:
  UPSTREAM_HOST = the current database host the app connects to (required)
  UPSTREAM_PORT = the current database port (default 5432 for postgres, 3306 for mysql)
  PROXY_LISTEN_PORT = 5433 for postgres or 3307 for mysql (defaults)
  VERICTO_WIRE_PROTOCOL, VERICTO_API_URL, VERICTO_DATABASE_ID as above
  VERICTO_API_KEY from the secret (ECS: valueFrom the secret; Kubernetes: secretKeyRef; Compose: ${VERICTO_API_KEY})
  VERICTO_HEALTHZ_PORT = a free port, and point the load balancer or readiness probe at it
If the database connection uses TLS, set UPSTREAM_SSLMODE=require (or verify-full with UPSTREAM_SSLROOTCERT) and PROXY_TLS_MODE=require together. Keep the database credentials exactly as they are: the app authenticates through the proxy with the same user and password.
Show me the diff before applying it.

Step 4 - Point the application at the proxy.
Change only the database host/port the application uses (connection string or env var) to the proxy's address and PROXY_LISTEN_PORT. Keep a one-line rollback note (the previous host/port) in the change description. Show me the diff before applying it.

Step 5 - Verify.
After deploying, call vericto-account.diagnose_proxy with database_id=<database_id> (or check the proxy logs for a successful rules sync). Then run this harmless probe through the proxy; the table does not exist, so nothing can change even if it is forwarded:
  postgres: psql "<app connection string with the proxy host and port>" -c "DELETE FROM vericto_setup_probe"
  mysql:    mysql -h <proxy host> -P 3307 -u <app user> -p <database> -e "DELETE FROM vericto_setup_probe"
Expected: in enforce mode, an error from Vericto naming the rule (SQLSTATE 42501 on postgres, error 1142 on mysql). In observe or monitor mode, the database's own "table does not exist" error, and the event shows as FLAGGED in the dashboard.
Then call vericto-account.explain_block on the probe's event and tell me in two sentences what was blocked or flagged and why.

Step 6 - Observe, then enforce (I decide).
Tell me whether the workspace is in observe mode and until when. Do not change the enforcement mode yourself. Suggest that I review FLAGGED events for a few days in https://app.vericto.com/dashboard and switch to enforce when they look right.

Finish with a short checklist: proxy deployed, connected, app routed through it, probe result, current mode.
