AIエージェントが直接バックエンドを叩く時代 — OSS「InsForge」とエージェント運用の死角

InsForge とは — UI を介さず動くバックエンド #

GIGAZINE が報じた OSS の「InsForge」は、Firebase や Supabase に似たフルスタック型バックエンドだが、設計思想が一線を画す。人間が管理画面でぽちぽち設定する作業を、コーディング AI エージェントがそのまま叩けるよう作り直したものだ。PostgreSQL、S3 互換ストレージ、Deno のエッジ関数、pgvector、Stripe 連携を揃え、すべてを MCP (Model Context Protocol) サーバ越しにエージェントへ晒す。複数 LLM を OpenAI 互換に束ねる Model Gateway と、CLI に「Skills」を添えてエージェントへ運用ノウハウを渡す仕組みも持つ。要は「人間オペレータの代わりに Claude や Codex がインフラを運転する」前提のバックエンドだ。

エージェント＝特権を持つ被誘導者 #

ハッカー視点ではこの構図そのものが攻撃面だ。LLM が本番 DB と管理者権限を握る世界では、プロンプトインジェクションで誘導された MCP ツール呼び出しが storage を全件読み出したり、関数を勝手にデプロイしたり、pgvector を書き換える。従来は「管理画面に座っている人間」が暗黙の最終承認層だったが、その層が消える。エージェントが取り込む context (タスク文、外部ドキュメント、ユーザ入力) が広いほど、悪意のテキストが管理者操作に化ける確率は上がる。InsForge 自身もクラウド版に「Backend Advisor」を毎日走らせるが、これは エージェントが事故を起こす前提で防衛側に別エージェントを置く構図でもある。

導入するなら最低ライン #

(1) MCP ツールごとの操作スコープを最小権限に絞る、(2) 本番 DB と検証環境を物理的に分け、書き込み系ツールは検証側にしか出さない、(3) エージェントが触る外部入力 (Issue 本文、メール、URL 取得結果) を「コードと同等の信頼レベル」で監査する — この 3 点が出発点になる。便利さの代償として、プロンプト 1 行が DROP TABLE になりうる世界がもう動き始めている。