hoop.dev はオープンソースのレイヤー 7 ゲートウェイであり、開発元はこれを AI コーディングエージェントと、 エージェントが操作する対象のシステムとの間に位置づけている。エージェントが Git サーバー、コンテナレジストリ、 CI/CD オーケストレーターと直接やり取りするのではなく、ゲートウェイがリクエストを受け取り、ペイロードを プロトコルレベルで検査し、下流へ何かを転送する前にポリシーを適用する。そしてポリシーが求める場合には、 権限を持つレビュアーが判断を下すまで転送の流れをブロックする。
この配置についてのベンダー自身の主張は、アイデンティティだけでは強制にならないというものである。エージェントが 対象に直接認証する場合、その構成は誰が呼び出しているかを検証はするが、ポリシーが一時停止・検査・人間の判断の 要求を行える地点が存在せず、操作は記録されるとしても対象側のログにしか残らない。ベンダーは、そうした構成の下で バージョン管理に到達しうるものとして、ソースファイルにコミットされたハルシネーションによるシークレット、既知の CVE を含む依存関係の更新、既存のセキュリティ制御を迂回するロジックを挙げている。そして、事後のプルリクエスト レビューでは遅すぎると主張する。成果物はすでに存在しており、レビュアーが介入する前にシークレットが露出したり 下流のジョブが起動したりする可能性があるからである。
機能
Git の push に対してゲートウェイがとるとされる動作は、それをインターセプトし、差分を抽出し、設定されたポリシーを 確認することである。そのポリシーに ヒューマン・イン・ザ・ループ による承認が含まれている場合、差分は レビュアーのコンソールに回され、明示的な同意があった後にのみコミットが転送される。セッションは完全に記録され、 承認の判断もそれと併せて保存される。
リクエストを見るのはゲートウェイだけなので、ベンダーはいくつかの制御をその位置からのみ可能なものとして説明している。 検出されたシークレットがリポジトリに届く前のインラインマスキング、安全でないインポートの書き換え、ブロック、 そして後で再生できるようすべてのやり取りをログに残すことである。また、対象サービスの認証情報はゲートウェイ自身が 保持するため、エージェントがその背後のシークレットを目にすることはない。ベンダーはこれを、アクセス制御の変更と してではなく、認証情報漏洩のリスクの低減として示している。
ポリシーはアイデンティティによって駆動される。説明されている構成は Okta や Azure AD などのアイデンティティ
プロバイダーから始まる。エージェントは OIDC で認証し、ゲートウェイはトークンを検証してグループのメンバーシップと
属性を抽出する。実例では、リクエストを ai-coding グループのエージェントに、同意を code-approval グループの
レビュアーに制限している。
採用とエコシステム
hoop.dev は MIT ライセンスで GitHub 上で公開されているため、組織自身のネットワーク内でセルフホストし、既存の アイデンティティプロバイダーに接続できる。ベンダーによれば、プロトコルレベルで動作するため、Git、HTTP、または 該当する API を話せるエージェントであれば何でもこれを経由させることができ、既存の CI/CD ツールを置き換えるのでは なくその前段に置かれ、下流のツールチェーンを変えずに承認と監査を追加する。
ベンダーがコンプライアンス上の成果として打ち出しているのは監査証跡である。セッションログ、各変更を誰が承認したかの 記録、そして保存されたマスク済みの差分であり、報告要件を満たすためにエクスポートできる。