私は19歳で、ブラジルでコンピュータ工学を学んでいます。数週間前、制限のない状態でAIエージェントをテストしていました。単に、それが何をするのか見たかっただけです。
それは破壊的でした。
永続的な被害はありませんでしたが、私はそれを止めました。しかし、あなたが「もし監視していなかったらどうなっていたんだろう」と考え込むような瞬間でした。もしそれが本番環境で動いていたら？ もし他人のエージェントが今まさに同じことをしていて、誰も見ていなかったら？
そのとき、問題の正体が分かりました。誰もが、エージェントにより多くのツール、より高い自律性、より多くのアクセスを与えようと競争しています。しかし、エージェントがそれを使って実際に何をできるのかを制御する層を作っている人は誰もいません。前提は「良いプロンプトがあれば十分」ということですが、そうではありません。
話題にされていないギャップ
AIエージェントの領域は爆発的に広がっています。LangChain、CrewAI、browser-use、OpenAI Agents SDK――エージェントを作るためのツール群はかつてないほど充実しています。午後のうちに、エージェントにウェブを閲覧させ、コードを書かせ、APIを呼ばせ、ファイルを移動させることもできます。
ですが、私が見つけられなかったのは次のような「実行時に、エージェントが実際に何をできるかをどう制御するのか？」への真剣な答えでした。
私が得た一般的な回答は：
- 「良いシステムプロンプトを書けばいい」
- 「入力バリデーションを追加すればいい」
- 「危険なツールを渡さなければいい」
これらは答えではありません。工学として語られているけれど、実態は願いです。
良いシステムプロンプトでは、プロンプトインジェクションによってエージェントが操作されるのを止められません。入力バリデーションでは、エージェントがrm -rf ./old_stuffを「クリーンアップ」の妥当な解釈だと判断してしまうケースを見抜けません。そして「危険なツールを渡さない」ことは、そもそもエージェントを使う理由と正面から矛盾します。
実際に必要なもの
欠けているのは、あまりにも単純なことです。あなたのエージェントと世界の間に挟まるポリシー層です。
プロンプト工学でもありません。雰囲気でもありません。実際の強制（enforcement）層が必要です。つまり：
- このエージェントは
./workspaceから読み取れるが、何も削除できない - このエージェントはOpenAI APIは呼べるが、あなたの本番データベースは呼べない
- このコマンドは、実行前に人間の承認が必要
- すべてが常にログに記録される
目的は、すべてのアクションを手作業で監視することではありません。そんなことをすれば、自動化の目的が失われます。目的は、境界を一度だけ定義し、それを自動的に強制し、本当に曖昧な判断だけを人間に提示することです。
これはファイアウォールがネットワークに対してやることです。WAFがWebアプリに対してやることです。エージェントにも同じものが必要で、しかしほとんど誰も作っていません。
だから私は作った
私は、AIエージェント向けのオープンソース実行時ファイアウォールであるAgentGuardを作りました。
これは、エージェントとツールの間に挟まるGo製のプロキシです。ポリシーはYAMLで定義します。このプロキシはリアルタイムにそれを強制し、ブロックしたり、承認待ちで保持したり、すべてをログに記録します。LangChain、CrewAI、browser-use、そしてMCP向けのアダプタがあります。さらにダッシュボードもあり、エージェントが今何をしているかをライブで表示し、ワンクリックでアクションの承認/却下ができます。
まだ完成していません。SQLiteの監査（audit）バックエンドはまだできていません。一部のアダプタも荒い部分があります。でもコアは動いていて、私はコアの考え方は正しいと思っています。
Caua-ferraz
/
AgentGuard
AgentGuardはAIエージェントのためのファイアウォールであり、エージェントによって望まないサプライズが監視なしで発生するのを防ぎます
AIエージェントのためのファイアウォール。
自律型AIシステムに対するポリシー強制、リアルタイムの監督、そして完全な監査ログ
Quickstart • Why AgentGuard • Architecture • Policy Engine • Dashboard • Adapters • Setup Guide • Contributing
The Problem
トレンドになっているあらゆるAIプロジェクトは、エージェントにより高い自律性を与えています――シェルコマンドの実行、ウェブ閲覧、API呼び出し、お金の移動、さらには侵入テストの実行まで。ですが 誰もガードレールを作っていません。
現状では、AIエージェントを本番に投入している多くのチームは、ただ...「うまく振る舞ってくれることを期待している」だけです。
AgentGuardがそれを解決します。
Why AgentGuard
| AgentGuardなし | AgentGuardあり |
|---|---|
エージェントがrm -rf /を実行 — 後で気づく |
ポリシーが実行前に破壊的なコマンドをブロック |
| 監督なしで本番APIを呼び出す | アクションを一時停止し、Slack/ウェブフックで承認してもらう |
| エージェントが何をしたのか、なぜやったのか記録がない | タイムスタンプ、推論、判断を含む完全な監査ログ |
| 「自分の環境では動いた」系のデバッグ | 監査から任意のエージェントセッションを照会 |
5日で、ほぼ積極的な配布なしにもかかわらず165人のユニークな開発者によりクローンされています。これは、この問題がどれだけ現実的なものかを物語っていると思います。
私がずっと考えていること
完全なセキュリティ承認を得たうえでAIエージェントを本番に送っている組織は、わずか14.4%しかありません。88%が、昨年AIエージェントのセキュリティインシデントが確認された、または疑われたと報告しています。
みんなが急いでいます。誰もガードレールを作っていません。
AgentGuardが正しい答えかどうかは分かりません。でも「希望」ではない、ということにはかなり確信があります。
