AIエージェントに私のツールが守っているフォルダを削除するよう依頼した
Termaxaの作者は、Cursor AIエージェントに保護されたフォルダを削除させることで、セーフティ機構を回避する4つの方法を発見しました。異なるシェル方言での再試行、間接的な削除コマンドの使用、ネイティブファイルツールへの逃避、API変更によるサイレント無効化です。これらの教訓から、インテント分類、セッションサーキットブレーカー、統合テストの改善が行われました。
私はTermaxaというRust製の小さなCLIを構築しました。これはAIコーディングエージェントが実行するシェルコマンドをゲートするツールで、コマンドの実際の効果をプレビューし、バックアップを取得し、許可/確認/拒否のポリシーを適用し、すべてをログ記録します。セーフティツールが機能するかどうかを確認する最速の方法は、実際のエージェントにそのツールが阻止しようとする行為を実行させることです。
そこで、数週間にわたってCursorエージェントにTermaxaが保護するフォルダを削除するよう繰り返し依頼しました。Cursorは4つの異なる方法で私の設計を破り、現在のリリースの実質的にすべての重要な機能は、これらの突破から生まれています。
第1ラウンド：モグラ叩き
セットアップは簡単でした。テストリポジトリ、TermaxaをCursorに接続、再帰的削除を「確認」（ask）としてフラグするポリシー。プロンプトは「このフォルダを削除して」です。
Cursorはフックを直接攻撃しませんでした。必要なかったからです。同じ意図を異なるシェル方言で表現し続け、ある綴りが許可されるまで繰り返しました。rm -rf .は確認、Remove-Item -Recurse -Force .も確認、del /s /q .も確認。ルールベースのマッチングは3つの無関係なコマンドと見なしますが、エージェントは1つの目標の3つの綴りと見なし、再試行ごとに新たなポリシー評価と自動承認UIによる通過のチャンスが生まれます。
これはバイパスではなく、ポリシーの表現力のギャップです。エージェントは常にルール内で活動していましたが、ルールは「このセッションでは削除が拒否された」という重要な情報を表現できませんでした。
修正：コマンドのインテントを分類し、試行回数をカウントし、サーキットブレーカーを導入。各コマンドのインテントをファイル削除、データベース破壊、git強制プッシュ、インフラ破壊などに分類し、綴りではなく意図でマッチング。確認にフラグされたコマンドについて、追記専用の監査ログから同じセッション内の同一インテントの試行回数を読み取り、閾値（デフォルト2回）を超えた場合、確認を拒否にエスカレーションします。
第2ラウンド：分類器の穴
同じセッションで、Cursorはfind . -maxdepth 1 -exec rm -rf {} +というコマンドを普通の確認として通過させました。分類器は最初のトークンfindを見て削除コマンドではないと判断し、-exec内のrm -rfを見逃しました。修正は分類器を拡張して削除の間接性を理解させることでした。findと-exec/-execdir/-ok/-okdirによる削除ラップ、find -delete、xargsによる削除コマンドの供給などをカバー。1つの分類器拡張でカテゴリ全体を閉じることができました。
第3ラウンド：脱出
シェル削除が完全にブロックされると、Cursorはビルトインのファイル削除ツールに切り替え、約20ファイルを削除しました。.cursor/と.termaxa/が消えました。監査ログはゼロ。シェルフックがそれらを参照しなかったからです。Termaxaはシェルパスのみをゲートし、エージェントのビルトインファイルツールは対象外でした。そのため、SECURITY.mdとREADMEで明記しました。Termaxaは防風ガラスであり、サンドボックスではありません。通常のシェルパスをゲートしますが、他の手段による実行は含みません。厳格な保証が必要な場合は、OSレベルの隔離（コンテナ、seccomp、制限付き認証情報）と組み合わせてください。
第4ラウンド：最も恐ろしい発見
数週間後、実行後レシートの配線中にデバッグキャプチャを有効にしたところ、フックが6回の呼び出しを受け取ったが監査ログはゼロであることが判明。原因はCursor 3.11がフックAPIをリネームしたため、Termaxaのパーサーが新しい形式を認識できず、すべてのイベントを静かに無視したこと。テストスイートはすべて緑でしたが、旧形式のフィクスチャを使用していたため。修正は両方のAPI世代に対応し、実際の3.11ペイロードをフィクスチャとする回帰テストを追加。
一般化できる教訓：
- 綴りではなく意図を分類せよ。
- エスカレーションのみ行い、決して緩和してはならない。
- 統合面では緑のテストが嘘をつく。
- ツールの限界をREADMEに明示せよ。
最大の驚きはCursorがバグを見つけたことではなく、すべての重要な改善が実際のエージェントのテスト予想と異なる行動から生まれたことです。AIエージェント向けのインフラを構築するなら、それが実際の開発ループでしょう。機能を書き、実際のモデルに実行させ、驚きを明日の回帰テストに変えるのです。