AI エージェント向け SQL ガードレール — 破壊的なクエリを実行前にブロック
AI エージェント向け SQL ガードレールは、危険なステートメント (DROP、TRUNCATE、WHERE のない大量 DELETE/UPDATE、フルテーブルスキャン、大量データ取得など) を MySQL、PostgreSQL、Cloudflare D1 に到達する前にインターセプトします。FutrixData は静的ルールマッチングと事前 EXPLAIN プローブを組み合わせるため、同じ SELECT がインデックス検索では低リスク、プランが幅広いスキャン (例: 10 万件のデータ取得) を示す場合は中リスクとなる可能性があります。
AI コンテキストでの「SQL ガードレール」の意味
データベース権限は「誰が接続できるか、誰が読み書きできるか」に答えます。エージェントはより細かい問題を導入します: 1 つの接続の下で、異なるステートメントは大きく異なるリスクをもたらします。SELECT * FROM orders WHERE id = 1001 はポイント検索ですが、SELECT * FROM orders は顧客データのダンプです。ガードレールはそれらを区別する中間層です。
4 つのリスクカテゴリ
- 破壊的操作。
DROP TABLE、TRUNCATE、WHEREのないDELETE/UPDATE— デフォルトでブロック。 - 幅広いクエリ。フルテーブルスキャン、欠落インデックス、大規模な推定スキャン行、深い結合 — 事前
EXPLAINプローブによってエスカレート。 - DDL。
ALTER、CREATE、インデックス削除 — テーブルに応じて警告または承認要求。 - 権限変更。
GRANT、REVOKE— 完全にブロック。
2 層評価: 静的ルール + 事前 EXPLAIN
静的ルールは明白なもの (WHERE なし、ターゲットテーブルが audit_logs など) を捕捉します。プローブは、パーサーには分からないことを捕捉します: クエリが実際にインデックスを使用するかどうか。FutrixData は次の場合にリスクをエスカレートします:
- インデックスがヒットしない。
- スキャン行が設定されたしきい値を超える。
- Explain プランが利用不可または検証不可能。
- MySQL: フルテーブルスキャン、一時テーブル、filesort、依存サブクエリ、高コスト結合。
- PostgreSQL: シーケンシャルスキャン、深いサブプラン、大規模な結果セットソート。
- D1:
SCANステージ、ビュー展開後のベーステーブルスキャン。
プローブはエスカレートするだけで、既に高リスクとして分類された操作をダウングレードすることはありません。
組み込みの MySQL / PostgreSQL / D1 ルール
| ステートメント | デフォルトアクション |
|---|---|
SELECT、SHOW、DESCRIBE、EXPLAIN | allow |
INSERT、REPLACE、UPDATE … WHERE、DELETE … WHERE | warn |
WHERE のない UPDATE / DELETE | block |
CREATE、ALTER | warn |
DROP、TRUNCATE、GRANT、REVOKE | block |
ユーザールールは、より精密なスコープと高い優先順位によって組み込みを上書きします。たとえば: デフォルトでは UPDATE に警告するが、本番の orders での DELETE は禁止する、など。
信頼モード
ソースごとの信頼モードは、プログラム的なエントリポイント (Agent、MCP、Skill、CLI) が自動実行できるものを決定します。
| モード | 動作 |
|---|---|
| Approval | すべての実行で人間の確認が必要。 |
| Cautious | デフォルト。低リスクステートメントのみ自動実行。 |
| Trusted | 低・中リスクは自動。高リスクは依然として確認が必要。 |
| Danger | 通常はブロックされる操作も含めてすべて自動実行。使い捨てのテストデータにのみ推奨。 |
承認の仕組み
エージェントが require_approval 結果に当たると、プロキシは一致したルールと解析されたステートメントを記述した構造化されたレスポンスを返します。呼び出し元は approve: true を付けてリクエストを再発行する必要があります。承認はエントリ層で検証されるため、エージェントは任意の呼び出しに approve: true を渡してインターセプトをバイパスすることはできません。
サンプル
// Agent attempts:
DELETE FROM users;
// FutrixData response:
{
"ok": false,
"risk": "block",
"rule": "sql.delete_without_where",
"reason": "DELETE without WHERE clause on table users",
"data_source": "prod-postgres",
"audit_id": "audit_01HQ7M..."
}// Caller reissues:
{
"statement": "DELETE FROM users WHERE last_login < now() - interval '5 years'",
"approve": true,
"approval_reason": "scheduled GDPR purge, ticket OPS-2189"
}よくある質問
FutrixData は SQL データソースでデフォルトで何をブロックしますか?
DROP、TRUNCATE、GRANT、REVOKE、および WHERE のない UPDATE/DELETE。それ以外はすべて allow (読み込み) または warn (書き込み / DDL) に該当し、信頼モードが警告に承認が必要かを決定します。
正当なクエリで誤検出が発生しますか?
静的ルールは意図的に狭く、破壊的操作と WHERE 欠落パターンに限定されます。事前 EXPLAIN プローブはより精密な層です。しきい値 (最大スキャン行、最大結合数) はソースごとに設定可能です (オプティマイザの判断で Seq Scan が選ばれる小さなテーブルなどは、フルテーブルスキャン行数の例外として扱えます)。
ブロックを上書きできますか?
はい — warn / require_approval の場合、呼び出し元は approve: true と監査ログに記録される理由を付けて再送信します。ハード block ルール (例: 本番での DROP) は、呼び出しごとのオーバーライドではなく設定変更が必要です。これは設計上のものです。
生の SQL で動作しますか? それとも ORM のみですか?
生の SQL です。FutrixData は MySQL、PostgreSQL、D1 構文を直接解析して、コマンドタイプ、ターゲットテーブル、WHERE の有無、結合、サブクエリを抽出します。生の SQL を生成する ORM は透過的にカバーされます。
MySQL の処理は PostgreSQL とどう違いますか?
静的ルールセットは同じです。プローブは異なります: MySQL はフルテーブルスキャン、一時テーブル、filesort、依存サブクエリ、結合行推定を検査します。PostgreSQL はシーケンシャルスキャン、結合数、サブプラン、大規模な結果セットソートを検査します。D1 は SCAN 対 SEARCH を検査し、ビュー展開後のベーステーブルスキャンを検証します。
事前 EXPLAIN はレイテンシを追加しますか?
はい — 通常、実際のクエリが実行される前に、データベースへの追加のラウンドトリップが 1 回発生します。ポイント検索ではミリ秒単位です。explain を通過しないクエリでは、それらを実行しないことで節約されるレイテンシがプローブのコストを大きく上回ります。
FutrixData をご自身のデータベースで試す
macOS、Windows、Linux 向けの無料デスクトップアプリ。本番環境にはセルフホスト型 Enterprise Edition もご利用いただけます。