Vericto Proxy mode (local, PostgreSQL)

Vericto Proxy

AI エージェント、スクリプト、人間のいずれが実行する場合でも、コードを変更することなく、破壊的な SQL がデータベースに届く前に阻止します。

AI エージェント、スクリプト、人間は皆、実際の認証情報を使って本番環境に SQL を実行します。実行前に各ステートメントを確認する人はいません。また、データベースロールが決めるのはユーザーがどのデータにアクセスできるかであり、このステートメントを実行すべきかどうかではありません。WHERE のない DELETE ひとつでテーブルが空になります。誤った列を指定した SELECT によって、メールアドレスやカード番号がクエリ結果の送信先にコピーされることがあります。

vericto-proxy は、データベース独自のワイヤープロトコルを使って、クライアントとデータベースの間に配置されます。vericto-engine の AST パーサーですべてのクエリを解析し、ルールに照らしてチェックしたうえで、実際のデータベースに転送するか、通常の SQL エラーとしてブロックします。アプリケーションで変更するのは、接続文字列のホストとポートだけです。

ライセンス。 ソース公開で、ライセンスは FSL-1.1-ALv2 です。セルフホストして無料で利用でき、営利企業の本番環境でも使用できます。ただし、競合利用は許可されていません。競合利用には、SQL ファイアウォールサービスの構築など、本製品の代替となる、または実質的に同等の機能を提供する商用製品やサービスで、他者に利用可能な状態にすることが含まれます。また、各リリースは Vericto が公開してから 2 年後に Apache-2.0 に移行します。よくある質問への回答は LICENSING.md をご覧ください。

プロキシの各インスタンスが中継するデータベースは 1 つで、デプロイ時に VERICTO_WIRE_PROTOCOL で選択した単一のワイヤープロトコルを使用します。

VERICTO_WIRE_PROTOCOL	データベース	ブロック時の応答
postgres (default)	PostgreSQL	ネイティブの ErrorResponse SQLSTATE 42501
mysql	MySQL	ネイティブの ERR_Packet ERROR 1142

それ以外の設定、評価、テレメトリーは、すべてのエンジンで共通です。上記の値と、必要に応じてデフォルトのポートだけが変わります。

AI も確率的なヒューリスティックも使用しません。同じ入力には常に同じ結果が返されます。

その他の方言（Oracle、SQL Server、Snowflake、SQLite）：HTTP API、CLI、または MCP を使って評価できます。これらにはワイヤープロキシはありません。Snowflake には TCP ワイヤープロトコルがないため、起動時に VERICTO_WIRE_PROTOCOL=snowflake を指定するとエラーでプロキシが停止します。SQLite もライブラリとしてアプリケーションにリンクされるため、ワイヤープロトコルはありません。SQL は実行前にアプリケーション内でチェックされます。

---

Docker で試す

必要なのは Docker だけです。アカウントも API キーもビルドも必要ありません。使い捨ての Postgres を起動し、組み込みのルールセットを使ってその前段にプロキシを配置し、 Postgres イメージに含まれる psql でいくつかのクエリを送信します。パスワードの demo は、この使い捨てデータベース専用です。

docker network create vericto-demo
docker run -d --name vericto-demo-db --network vericto-demo \
  -e POSTGRES_PASSWORD=demo postgres:17
docker run -d --name vericto-demo-proxy --network vericto-demo \
  -e UPSTREAM_HOST=vericto-demo-db vericto/vericto-proxy:4.23.0
until docker exec vericto-demo-db pg_isready -q -h localhost -U postgres; do sleep 1; done

docker run --rm --network vericto-demo postgres:17 \
  psql postgresql://postgres:demo@vericto-demo-proxy:5433/postgres \
  -c "CREATE TABLE users (id int PRIMARY KEY, email text)" \
  -c "INSERT INTO users VALUES (1, '[email protected]'), (42, '[email protected]')" \
  -c "DELETE FROM users" \
  -c "DELETE FROM users WHERE id = 42" \
  -c "SELECT id, email FROM users"

イメージは Docker Hub から取得されます。ghcr.io/vericto/vericto-proxy:4.23.0 も 同じダイジェストを提供します（Docker を参照）。

WHERE のない DELETE はデータベースに到達せず、WHERE のあるものは到達します。

CREATE TABLE
INSERT 0 2
ERROR:  Vericto blocked this query [VERICTO-001] — AST node: DeleteStmt > WhereClause = NULL. Suggestion: DELETE FROM users WHERE id = $1
DELETE 1
 id |      email
----+-----------------
  1 | [email protected]
(1 row)

docker logs vericto-demo-proxy で判定を確認できます。独自のデータベースの前段に プロキシを配置する方法については、Docker と 接続文字列 を参照してください。次のコマンドでクリーンアップできます。

docker rm -f vericto-demo-db vericto-demo-proxy && docker network rm vericto-demo

この記事で扱う拡張プロトコル、パイプライン、準備済みポリシーの更新、TLS/SCRAM、 キャンセル、COPY、PostgreSQL 18 の各ケースをアサーションベースで網羅するには、 examples/postgres-wire-article/run.sh を実行してください。

---

アーキテクチャ上の位置づけ

Your app / ORM
     │
     │  SQL wire protocol (proxy listen port, default 5433)
     ▼
 vericto-proxy   ──── vericto-engine (lib) ────►  ALLOWED / BLOCKED
     │
     │  (if ALLOWED) forwards query
     ▼
 Real database upstream

実際のデータベースではなく、vericto-proxy を DATABASE_URL のホストに指定してください。 コードの変更は不要です。ORM／ドライバーはプロキシを認識しません。

---

ブロックするもの

組み込みのルールセットでは、次のクエリはデータベースに到達しません。

• WHERE のない DELETE／UPDATE
• DROP TABLE、DROP SCHEMA、TRUNCATE
• OR を使った恒真式 SQL インジェクション（WHERE id = $1 OR 1=1）
• ALTER TABLE DROP COLUMN／RENAME
• … ルールの全一覧 →

重大度の低い検出項目（WHERE のない SELECT *、LIMIT のない SELECT、 明示的なカラムリストのない INSERT）はブロックされず、転送されて記録されます。 コントロールプレーンとの接続が有効な場合、各重大度に対するアクションは ワークスペースポリシーによって決まります。

読み取り量の制限（4.17.0）。 エージェントの読み取りをフラグ付けするだけでなく 上限を設定するには、action: { rewrite_limit: n } を指定したビジネスポリシー （リライトモードの LIMIT 上限テンプレート）を使います。プロキシは Postgres と MySQL のシンプルステートメントと準備済みステートメントに対して、LIMIT n を追加するか、 より大きな LIMIT の値を引き下げてステートメントを転送します。 VERICTO_POLICY_RULES=enforce が必要です。詳しくは docs/CONFIGURATION.md を参照してください。

ブロックされたクエリは、現在のプロトコルに対応するネイティブエラーとして返されるため、 アプリケーション側で特別な処理を行う必要はありません。

PostgreSQL のパイプラインと準備済みステートメント（4.17.3）。 ローカルでのブロック応答と セッションコンテキスト応答は、上流の応答サイクル内の正確な位置に順序どおりに配置され、 先行するパイプライン結果がすべて返された後に送信されます。バックエンドメッセージはフレーム化されるため、 大きな行や COPY メッセージであっても、合成応答によって分割されることはありません。名前付きと 名前なしの準備済み SQL は、ルール、ポリシー、プリンシパル、またはセッションコンテキストが更新された後、 Bind と Execute の時点で再度チェックされます。時刻を参照する可能性のあるビジネスポリシー （time.*）は Execute のたびにチェックされ、それ以外のポリシーは同じルール、ポリシー、 バンドル、セッションコンテキストのもとで得られた判定を維持します（ docs/CONFIGURATION.md を参照）。マスクまたは rewrite_limit により 異なる SQL が必要になった場合、プロキシは VERICTO-PREPARED-STALE を返します。 その場合、クライアントはステートメントをクローズして再度準備する必要があります。 ポータルは、元のステートメントがクローズまたは置き換えられた後も、バインド時のプランを保持します。 PostgreSQL の COPY BOTH／レプリケーションでは、応答の順序が乱れるリスクを避けるため、 セッションを閉じて処理を拒否します。エージェントアクセス ポリシーによって拒否された FunctionCall も セッションを閉じます。Query ベースの順序マーカーを使うと、名前なしステートメントの状態が変わるためです。 このパッチによる MySQL の動作変更はありません。MySQL の準備済みステートメントは引き続き準備時に チェックされ、後で実行される際には再チェックされません。

---

機密列

Vericto ダッシュボードでデータベースごとに列を機密としてタグ付けできます（Team プランおよび Enterprise プラン）。タグはルールセットとともにプロキシに届き（/sync/rules。そのためコントロールプレーンへの接続と VERICTO_DATABASE_ID が必要です）、データベースがクエリを受け取る前に通信上で適用されます。クエリがタグ付けされた列を複数読み取る場合は、最も厳しいポリシーが優先されます（block > mask > flag）。**プロキシが適用します。**助言のみを行う Validation API や CLI とは異なり、プロキシが決定した内容がデータベースに送られます。

ポリシー	Postgres	MySQL
block	クエリはデータベースに到達しません：ErrorResponse、SQLSTATE 42501	データベースに到達しません：ERR_Packet、ERROR 1142
flag	送信された内容のまま転送され、FLAGGED として記録されます	同じ
mask	プロキシは、独自の列名の下で列をマスクした（full、last4、email、または hash）書き換え済みクエリを転送し、元のクエリは転送しません。クライアントにはマスクされた値が返されます。	同じです。プロキシは同じ COM_QUERY または COM_STMT_PREPARE で書き換え済みクエリを転送し、元のクエリは転送しません。

書き換えが成立しない場合、プロキシは元のクエリを転送せず、VERICTO-085 でブロックします。マスクまたはブロック対象の列があるテーブルに対する SELECT * はブロックされるため、列を指定してください。動作の詳細（両プロトコル、プリペアドステートメント、フェイルセーフの場合、解析エラー、テレメトリ、既知の制限）は docs/SENSITIVE_COLUMNS.md を参照してください。

---

エージェントアクセス

Vericto ダッシュボードでデータベースユーザーごとの許可リストを設定できます（Team プランおよび Enterprise プラン）。そのユーザーが読み取り可能なテーブルと列、および書き込み可能なテーブルと列を指定します。それ以外はすべて拒否されます（VERICTO-087）。ポリシーはルールセットとともにプロキシに届き（/sync/rules。そのためコントロールプレーンへの接続と VERICTO_DATABASE_ID が必要です）、データベースユーザーをキーとして適用されます。リストにないすべてのユーザーに適用する任意の "*" デフォルトも設定できます。

セッションの ID は、認証に使用したデータベースユーザーです。そのため、各エージェントに専用のデータベースユーザーを割り当て、そのユーザーのポリシーを設定してください。ポリシーでは、すべての参照が対象となります（クエリが返す内容だけでなく、WHERE、JOIN、サブクエリ、RETURNING も含みます）。DDL は常に拒否され、セッション内から ID を変更することもできません（SET ROLE、USE、COM_CHANGE_USER などは拒否されます）。observe モードのポリシーでは、拒否するはずの内容を記録しながらクエリを転送します。

動作の詳細（名前解決、書き込みとロック、オープン中のセッションに対するポリシー変更、テレメトリ、既知の制限）は docs/AGENT_ACCESS.md を参照してください。

**キルスイッチ（4.18.0）。**オーナーまたは管理者がダッシュボードの「Incident response」パネルからエージェント（またはワークスペース内のすべてのエージェント）をブロックすると、プロキシは次のルール同期以降、そのデータベースユーザーのすべてのステートメントを VERICTO-105 と Runtime API が返すキルスイッチメッセージで拒否します。評価前に、またすべてのモードで拒否され、SELECT 1、SET、BEGIN、およびブロック前に準備されたステートメントも対象です。ブロックを解除すると、次回の同期後にセッションが復元されます。docs/AGENT_ACCESS.md を参照してください。

---

MCP：エージェントがVericto（プロキシモード）経由でSQLを実行

vericto-proxy mcp（4.21.0）はAIエージェント向けのMCPサーバーです。Claude Code、Cursor、 Codex、または任意のMCPクライアントにexecute_sqlツールを提供し、データベースの認証情報は渡しません。 各ステートメントは最初に評価され、サーバーは評価した内容（またはポリシーによる書き換え）をPostgreSQLで実行します。 読み取り専用で、必ずロールバックされるトランザクション内で実行され、行数、サイズ、時間に上限があります。 describe_schema、ローカルのcheck_sql、whoamiも利用できます。開発者のマシンではstdioで、チームではStreamable HTTPで利用できます。

**アカウントなしでお試しいただけます。**コントロールプレーンが設定されていない場合、組み込みのルールセット（TCPプロキシが単独で実行するルール）を使ってローカルで動作し、情報は報告されません。

claude mcp add vericto-db -- \
  docker run -i --rm --user "$(id -u):$(id -g)" \
    -v ~/.config/vericto/shop.url:/run/secrets/db.url:ro \
    vericto/vericto-proxy:4.23.0 /usr/local/bin/vericto-proxy mcp --database-url-file /run/secrets/db.url

Verictoに接続すると、カスタムルール、ビジネスポリシー、機密列のマスキング、監査、ダッシュボードを利用できます。-e VERICTO_API_KEY=vtro_... -e VERICTO_DATABASE_ID=<id>を追加してください（両方をコンテナに渡してください）。コントロールプレーンが設定されている場合、組み込みルールに切り替わることはありません。最初の署名済みバンドルが適用されるまでは、サーバーはNOT_READYを返します。

エージェントがデータベースのほかの認証情報を持たない限り、チェックされた内容がそのまま実行されます。サーバーは、環境内に認証情報が公開されている場合に警告します。アカウントの有無を問わない各クライアントのセットアップ、HTTPモード、制限、セキュリティに関する注意事項については、docs/MCP.mdをご覧ください。

---

設定

すべての変数は方言に依存しません。同じ名前をすべてのエンジンで使用できます。

必須

変数	説明
UPSTREAM_HOST	プロキシ接続先となる実際のデータベースのホスト名

ポート

変数	デフォルト	説明
UPSTREAM_PORT	プロトコルのデフォルト¹	上流データベースのポート
PROXY_LISTEN_PORT	プロトコルのデフォルト¹	プロキシがリッスンするポート

¹ デフォルト値はVERICTO_WIRE_PROTOCOLに従います。Postgresでは上流が5432、リッスンが5433、MySQLでは上流が3306、リッスンが3307です。

その他すべて

残りの設定は任意で、docs/CONFIGURATION.md に記載されています。

• コントロールプレーンとの接続 （VERICTO_API_URL、VERICTO_API_KEY、VERICTO_DATABASE_ID の3つすべてを設定）：判定結果を Vericto API に報告し、ワークスペースのルールとポリシーを同期します。設定しなくても、プロキシは組み込みルールセットで保護を続けますが、報告は行いません。テレメトリバッファー、 月間クォータを超えた場合、 ディスクスプールサイズ、および 1つのボリューム上で複数のプロキシを実行する場合についても説明しています。
• クライアント→プロキシ間とプロキシ→データベース間の各ホップでの TLS。MySQL では、両方のホップで TLS を有効にするか、どちらも有効にしない必要があります。
• クエリの受付制限： VERICTO_MAX_QUERY_BYTES（TCP ではデフォルトで 1 MiB。MCP は 64 KiB のまま）と、二項演算子が 10,000 個を超える式を対象とする線形な解析前ガード（VERICTO_MAX_BINARY_OPERATORS）。
• ビジネスポリシールール （デフォルトで off の VERICTO_POLICY_RULES）：プレビュー機能で、明示的に有効にしない限り無効です。無効の場合、プロキシはプリンシパルを考慮したポリシー評価をスキップします。PostgreSQL の応答順序制御とプリペアドステートメントの追跡は引き続き有効です。有効にすると、Ed25519 署名が検証された同期バンドルのみをプロキシが適用します（Vericto 以外のコントロールプレーンでは VERICTO_BUNDLE_SIGNING_KEYS を設定します）。
• ロードバランサー向けの ヘルスチェック（VERICTO_HEALTHZ_PORT）。
• オブザーバビリティ：ログ、および Prometheus または CloudWatch EMF 形式のメトリクス。
• CPU のサイジング：vCPU あたりの処理能力、スケールアウトのタイミング（CPU 使用率がタスクの予約容量の 50～60％に達したとき）、および VERICTO_WORKER_THREADS（デフォルトではコンテナの CPU 制限に基づいて設定され、0.5 vCPU のタスクではワーカーは 1 つ）。
• エンジン固有の注意事項。MySQL の詳細（TLS、プロトコル圧縮）などが含まれます。

ソースから実行してテストを実行する方法については、CONTRIBUTING.md を参照してください。

---

Docker

リリースイメージは Docker Hub の vericto/vericto-proxy（4.14.1 以降）と ghcr.io/vericto/vericto-proxy で公開されており、linux/amd64 と linux/arm64 に対応し、認証情報なしでプルできます。リリースワークフローは、 GHCR にプッシュしたマルチアーキテクチャインデックスをコピーするため、どちらの レジストリも同じタグ（<version>、<major>.<minor>、<major>、latest）で 同じダイジェストを提供します。環境で利用できる方からプルしてください。

# Postgres. On Linux, add --add-host=host.docker.internal:host-gateway
docker run --rm -e UPSTREAM_HOST=host.docker.internal -p 5433:5433 \
  vericto/vericto-proxy:4.23.0

# MySQL
docker run --rm \
  -e VERICTO_WIRE_PROTOCOL=mysql \
  -e UPSTREAM_HOST=host.docker.internal \
  -p 3307:3307 \
  vericto/vericto-proxy:4.23.0

# The same image from GHCR
docker pull ghcr.io/vericto/vericto-proxy:4.23.0

今後リリースされるイメージには、ダイジェストをこのリポジトリ、リリースワークフロー、 コミットに結び付けるビルド来歴の証明書（Sigstore、GitHub Actions）が付属します。 デプロイする前に検証し、ダイジェストを指定してデプロイしてください。

gh attestation verify oci://ghcr.io/vericto/vericto-proxy:<version> --repo vericto/vericto-proxy

# Docker Hub (4.14.1 and later): the same digest, attested under its Docker Hub name
gh attestation verify oci://docker.io/vericto/vericto-proxy:<version> --repo vericto/vericto-proxy

各プラットフォームイメージ（4.15.2 以降）には、プラットフォームマニフェストの ダイジェストに対して作成された、署名付き SPDX SBOM 証明書も付属します （docker buildx imagetools inspect に両方が表示されます）。

gh attestation verify oci://ghcr.io/vericto/vericto-proxy@<platform digest> \
  --repo vericto/vericto-proxy --predicate-type https://spdx.dev/Document/v2.3

ランタイムのベースには Chainguard glibc-dynamic （4.15.2 以降。それ以前は debian:bookworm-slim）を使用しています。内容は glibc、libgcc、 CA バンドルで、シェルとパッケージマネージャーは含まれません。プロキシは 65532:65532（nonroot）として実行されます（4.15.1 までは 1001:1001 だったため、 古いイメージが書き込んだボリュームは chown するか、--user 1001:1001 を指定してください）。 ヘルスチェックはシェルではなく、exec 形式でバイナリを呼び出します。 ["CMD", "/usr/local/bin/vericto-proxy", "healthcheck"]（Docker Compose の healthcheck.test、ECS の healthCheck.command）。ヘルスチェックリスナー （VERICTO_HEALTHZ_PORT）に接続し、接続に成功した場合、またはポートが設定されていない 場合は 0、それ以外の場合は 1 で終了します。このイメージでは CMD-SHELL チェック、 bash -c、curl、wget は失敗します。

代わりに、このチェックアウトからイメージをビルドするには、次のようにします。

docker build -t vericto/proxy:local .

Docker Compose を使用する場合：

proxy:
  image: ${VERICTO_PROXY_IMAGE:-vericto/vericto-proxy:4.23.0}
  ports:
    - "5433:5433"
  environment:
    UPSTREAM_HOST: postgres
    UPSTREAM_PORT: "5432"
    PROXY_LISTEN_PORT: "5433"
    # For MySQL: VERICTO_WIRE_PROTOCOL: "mysql" + the matching ports.
    # Optional — uncomment for telemetry + rule sync (all three together):
    # VERICTO_API_URL: "https://api.vericto.com"
    # VERICTO_API_KEY: "${VERICTO_API_KEY}"
    # VERICTO_DATABASE_ID: "${VERICTO_DATABASE_ID}"

---

接続文字列

	接続文字列
プロキシ経由の Postgres	postgres://user:pass@localhost:5433/mydb
プロキシ経由の MySQL	mysql://user:pass@localhost:3307/mydb

直接接続と同じ認証情報を使用します。変更されるのはホスト／ポートだけです。

---

貢献

ワイヤープロトコル、TLS、テレメトリー、デプロイに関する修正はこちらで扱います。ルールや パーサーの変更はvericto-engineで扱います。 CONTRIBUTING.md と SECURITY.md を参照してください。

ライセンス

Copyright 2026 Vericto S.A.S. 4.14.0 以降は、 Functional Source License, Version 1.1, ALv2 Future License （SPDX FSL-1.1-ALv2）の下でソースを公開しています。競合利用以外の目的であれば、 使用、変更、再配布が可能です。また、各バージョンはリリースから 2 年後に Apache-2.0 ライセンスになります。4.13.0 以前のバージョンは引き続き Elastic License 2.0 の下で 提供されます。LICENSING.md では、組み込まれている vericto-engine の ライセンスを含む、よくある質問に回答しています。NOTICE と TRADEMARKS.md も参照してください。 商用ライセンスについては、[email protected] まで お問い合わせください。

Docker イメージには LICENSE、NOTICE、THIRD_PARTY_LICENSES（バイナリに コンパイルされたすべての依存関係のライセンス）が /usr/share/doc/vericto-proxy/ に含まれており、ラベル org.opencontainers.image.licenses=FSL-1.1-ALv2 が付いています。

# The image has no shell or `cat` (4.15.2 and later), so copy the file out:
id=$(docker create ghcr.io/vericto/vericto-proxy:latest)
docker cp "$id":/usr/share/doc/vericto-proxy/THIRD_PARTY_LICENSES - | tar -xO
docker rm "$id" >/dev/null