Agent Governance Auditor

他のAIエージェントのコンプライアンスを監査するADKエージェント — GCPプロジェクト内で稼働中のAIワークロードを検出し、誰も登録していないものも含めて、バージョン管理されたポリシーパックに対して11種類の決定的なガバナンスチェックを実行し、EU AI法（第6条、第9条、第11条、第12条、第13条、第15条、第50条）およびSOC 2トラストサービス基準に対応付けた、監査人にそのまま提出できるエビデンスパッケージを生成します。すべての所見には不変のエビデンス引用（GCS + SHA-256）が付与されます。すべての書き込み操作は人間の承認を必要とします。

各ポリシーは、なぜその条項に対応付くのかを明記しています — そしてレビューの結果、2つの対応付けは過剰適用として削除されました。過剰な対応付けはコンプライアンスレポートの信頼性を最も早く損なうからです。このツールは、必要な宣言の欠如を監査するものであり、推測による法的違反を監査するものではありません。「リスク分類が文書化されていない」ことは検証可能であり、監査人が指摘する内容です。「このエージェントは附属書IIIに基づき高リスクである」というのは、このツールが下す権限を持たない法的判断です。

Gemini Enterpriseハッカソン向けに構築 — ストリーム2（ハイコード: ADK + カスタムMCPサーバー + Gemini Enterprise Agent Platform上のAgent Runtime）。

なぜ必要か

EU AI法のスケジュールが変更され、そのことで問題は小さくなるどころか、より緊急性を増しています。規則(EU) 2026/1744（「AIに関するデジタルオムニバス」、2026年7月27日発効）は、附属書IIIの高リスク義務を2027年12月2日に延期しました。延期されたのであって、廃止されたわけではありません — その間にも第50条の透明性義務、第5条の禁止行為、およびGPAIプロバイダー義務は現在すでに有効であり、罰金は最大€35Mまたは世界売上高の7%に達します。

つまり企業には、高リスクシステムのエビデンスの連鎖を構築するための約16か月が残されている一方で、現在稼働中のエージェントに関する義務はすでに負っています。どちらも、監査人が必ず問う1つの質問 — 「どのようなAIシステムを保有しており、それらがガバナンスされていることを証明できますか」 — に答えることに依存しており、正直な答えは通常*「完全には把握していません」*です。

このツールは、エビデンス付きでその問いに答えます。

Related MCP server: EU AI Act Compliance MCP Server

仕組み

上の図は実際に存在するものを示しています。中核となる設計ルール（完全なアーキテクチャ）:

• LLMがコンプライアンスを判断することは決してありません — コードが判断します。 合否はMCPツールのコード内で計算されます。エージェントはオーケストレーション、優先順位付け、説明を行います。ミューテーションガードは、トリアージがステータスを書き換えようとした場合に実行を中止します。

• 構造によるグラウンディング。 evidence_refのない所見はデータモデルに存在できません — スキーマがそれを拒否します。

• デフォルトで読み取り専用。 唯一の書き込み経路（是正指示）には、人間が発行した使い捨ての承認トークンが必要で、サーバー側で強制されるため、サーバーは人間が承認したというエージェントの主張を決して信頼しません。

• 監査人は自分自身を監査します — 独自のAgent Identityでデプロイされ、自身のスイープによって検出され、自身の11チェックのうち6つに合格します。

1回の監査、エンドツーエンド

この中の2つの要素は、装飾ではなく設計です。トリアージはMCPツールを一切呼び出しません — 実際の推論を行う唯一のステップは、プロセス外部への到達手段を一切持たないのです。そして実行は何かを書き込む前に中断します: トークンはまだ存在しないため、エージェントが書き込みを試みたとしても、サーバーは拒否します。

検出は名前照合ではなく行動ベース

この製品の成否を左右する問いは、*「agent-somethingという名前ではないエージェントを見つけられるか」*です。名前照合は「いいえ」と答えます — customer-insights-apiを見逃し、agent-proxyというnginxを誤検出します。そこでワークロードは5つのシグナルで分類され、信頼度と理由がすべての候補について報告されます:

最初のシグナルが要点です: モデルと通信するワークロードは、無難な名前の背後に隠れることはできません。デモ用フリートにはcustomer-insights-api — エージェントらしい名前もラベルもない本物のADKエージェント — が含まれており、この主張が断言ではなく検証可能であることを保証しています。

対象範囲と対象外

検出は監査よりも広く到達し、レポートはどちらがどちらかを明示します:

最後の行が正直な部分です。外部プロバイダーを呼び出すワークロードはGoogleのログに一切触れず、コンプライアンス監査人はそれを捕捉しません — 監査人は、それを阻止したはずの制御が有効になっているかをチェックし、有効でない場合に報告します。GOV-NET-007はまさにそのチェックです。

下限: モデルを使用するには認証が必要であり、認証はログに記録されます。したがって最悪のケースは*「属性を特定できないものが1つあります — 調査してください」*であり、沈黙ではありません。

クイックスタート

すべての開発はコンテナ内で行われます — gcloud、Terraform、Node、および固定されたPython 3.12を備えたUbuntu 26.04 LTS。お使いのマシンには何もインストールされず、環境はmacOS、Windows（Docker DesktopまたはWSL2）、Linuxで同一です。

前提条件: Dockerが実行中（OrbStack、Docker Desktop、またはWSL2）で、このリポジトリがクローン済みであること。それ以外は不要です。

1. イメージをビルドしてシェルを取得

リポジトリのルート — このREADMEとgov_mcp/ auditor/ infra/フォルダを保持するフォルダ — でターミナルを開きます:

cd path/to/agent-governance-auditor      # wherever you cloned it

# Build. First time ~3-5 min; afterwards it's instant (layer cache), so it's
# safe to just always run it.
docker build -t agv-dev docker/

# Start a shell inside the container.
docker run -it --rm \
  -v "$PWD":/workspace \
  -v agv-gcloud:/home/ubuntu/.config/gcloud \
  -v agv-venv:/opt/venv \
  -p 8080:8080 -p 8000:8000 -p 6274:6274 -p 6277:6277 \
  agv-dev bash

docker run -it --rm `
  -v "${PWD}:/workspace" `
  -v agv-gcloud:/home/ubuntu/.config/gcloud `
  -v agv-venv:/opt/venv `
  -p 8080:8080 -p 8000:8000 -p 6274:6274 -p 6277:6277 `
  agv-dev bash

これらのフラグの意味:

プロンプトがubuntu@…:/workspace$になります。これでコンテナ内に入りました。

ここから先はすべてコンテナ内で実行します。

2. 初回セットアップと認証

bash docker/post-create.sh    # creates the python env, installs deps, runs the tests

# BOTH logins are required and they are NOT interchangeable:
#   the first authenticates the gcloud CLI
#   the second writes Application Default Credentials, which Terraform and
#   every google-cloud-* python client read instead
gcloud auth login --no-launch-browser
gcloud auth application-default login --no-launch-browser

gcloud auth application-default print-access-token >/dev/null && echo "ADC OK"

各ログインはブラウザで開くURLを表示し、コードを貼り戻すよう求めます。2つ目の同意画面では、すべての権限ボックスにチェックを入れます（「すべて選択」）— 部分的な同意は紛らわしいScope has changedクラッシュで失敗し、何かを機能させるにはcloud-platformスコープが必要です。ADC OKが表示されるまで先に進まないでください。

→ 同意画面でエラーが発生した場合: 落とし穴 0b

3. サンドボックスGCPプロジェクトを作成

export PROJECT_ID="agent-gov-auditor-$(date +%y%m%d)"   # must be globally unique
gcloud projects create "$PROJECT_ID" --name="agent-governance-auditor"
gcloud config set project "$PROJECT_ID"

gcloud billing accounts list                             # copy your account id
gcloud billing projects link "$PROJECT_ID" --billing-account=XXXXXX-XXXXXX-XXXXXX

# REQUIRED: attribute ADC API calls to your project. User credentials carry no
# project of their own, so without this Terraform gets a 403 SERVICE_DISABLED
# blaming Google's shared ADC client project (764086051850).
gcloud auth application-default set-quota-project "$PROJECT_ID"

gcloud config set run/region us-central1

Terraformを実行する前に請求先をリンクする必要があります — APIの有効化にそれが必須だからです。

→ プロジェクト764086051850の命名で403が発生した場合: 落とし穴 0c

4. インフラストラクチャをプロビジョニング

有効化されたAPI、サービスアカウント（意図的に過剰な権限を持つローグアカウントを含む）、エビデンスバケット、予算、監査ログシンク、Artifact Registryリポジトリを作成します。

cd infra
cp terraform.tfvars.example terraform.tfvars
# edit terraform.tfvars: project_id, billing_account_id, region
terraform init
terraform plan
terraform apply

apply が billing budget で失敗しても、一部のアカウントではそれが想定どおりです。予算にはプロジェクトレベルの権限ではなく、課金アカウントレベルの権限が必要だからです。Console で一度作成して terraform import するか、リソースをコメントアウトしてください。この件で夜を潰さないでください。

→ 最初の apply が SERVICE_DISABLED の羅列で失敗した場合: gotcha 0e — 通常は再実行するだけです

5. すべてをデプロイ

1 つのコマンドで、Terraform のベースライン上に環境全体を依存関係の順にビルド・デプロイし、ステージごとの経過時間を出力します。実測: 6m 57s（4 エージェントのフル構成）。

./scripts/deploy-all.sh

次に、登録された Gemini Enterprise アプリを開き（Agents → 3-dot → Preview）、以下を送信してください:

このプロジェクトのガバナンス監査を実行してください。

実行は承認ゲートで停止します。修復を承認するには APPROVE と返信し、一部のみを承認するには APPROVE <finding id>、拒否するには DECLINE と返信します。(GE と Agent Runtime Playground は、ADK の実験的な確認プリミティブに対して確認ボタンを表示しないため、ゲートはタイプ入力による返信も受け付けます。)

ターミナルを好む場合、またはブラウザなしで操作したい場合:

python scripts/query_agent_runtime.py        # multi-turn chat against the deployed agent

→ デプロイしたエージェントが 401 を返すか、ゲートで止まる場合: gotchas 0q and 0r

6. 破棄、再ビルド、繰り返し

ソフトティアダウンは、デプロイスクリプトが作成したものをすべて削除し、Terraform が管理するものをすべて保持します。これにより、20 分かかるプロジェクトのブートストラップなしで、デプロイ経路全体を数分で試せます。また、デモの最良のリハーサルでもあります。同じシーケンスだからです。

./scripts/teardown-workloads.sh     # prompts first; --yes to skip
terraform -chdir=infra plan         # expect NO changes — proves the split is clean
./scripts/deploy-all.sh             # back up in ~6 minutes

Evidence は意図的に削除されません。バケットには 30 日間の保持ポリシーがあり、削除を拒否するからです。これが設計が主張する不変性であり、削除が拒否されるのを目の当たりにすることが、どんな主張よりもそれを実証します。

デプロイチェーン

何かが失敗し、どのリンクを再実行すればよいかを知る必要があるときに役立ちます:

scripts/deploy-all.sh
├─ 1. auditee fleet
│      auditees/deploy-{compliant,legacy,rogue,insights}.sh
│        └─ each sources auditees/common.sh → build_image()
│             └─ gcloud builds submit  (Dockerfile + main.py + requirements.txt)
│                  └─ Artifact Registry
│           then gcloud run deploy, with posture set by FLAGS only
├─ 2. gov_mcp/deploy.sh                  → Cloud Build → Cloud Run (MCP server)
├─ 3. auditor/deploy.sh                  → Agent Runtime + its two IAM bindings
└─ 4. scripts/setup-gemini-enterprise.sh → GE app + agent registration + sharing

このチェーンについて知っておくべき 3 つのこと:

• common.sh はスクリプトではなく、source されるライブラリです。 PROJECT_ID、REGION、IMAGE、build_image() を定義します。直接実行しても何も起こりません。

• 1 つのイメージ、4 つのデプロイ。 4 つの auditee はすべて同じコンテナを実行します。それらのガバナンス体制は、gcloud run deploy のフラグ — ラベル、サービスアカウント、環境変数 — に完全に宿っており、それがまさに監査者が検査する対象です。したがって、最初のスクリプトがビルドし、残りは再利用します。

• build_image() は、イメージがすでに存在する場合ビルドをスキップします。 auditees/main.py を編集した後に単純に再デプロイすると、古いイメージが配信され、変更は静かに反映されません。一度だけ強制してください: FORCE_BUILD=1 ./auditees/deploy-compliant.sh。

手順 2 と 3 は単体でも動作します（./auditor/deploy.sh はエージェントだけを再デプロイします）。また、すべてのスクリプトは冪等なので、再実行しても安全です。

離脱と復帰: exit はセッションを終了し、コンテナを削除します。同じ docker run … コマンドを再実行すれば戻ってこれます。gcloud のログイン状態とインストール済みパッケージは、コンテナ内ではなく agv-gcloud ボリュームと agv-venv ボリュームに保存されているため、そのまま残っています。すべてを消去してクリーンな状態から始めるには: docker volume rm agv-gcloud agv-venv。

何かが壊れたときは、デバッグする前に gotchas & sharp edges を確認してください。そこには、私たちが実際に遭遇した障害が網羅されています。Scope has changed 認証クラッシュ、mcp.shared.session インポートエラー、gcloud virtualenv/VPN の失敗、そして個人プロジェクトで複数のチェックが正当に SKIPPED を報告する理由も含みます。

上記の手順はハッピーパスです。docs/build-plan.md には、運用ルール、実際に遭遇したすべての gotcha、そして現状がそうなっている理由を説明する意思決定ログという、残りのすべてが含まれています。

リポジトリ

scripts/

テスト

pytest evals/ -q              # 171 offline, no GCP needed, free
pytest evals/agent -m live    # 8 end-to-end agent evals (~100s, ~$0.02, needs ADC)

ライブスイートは実際のパイプラインを実行し、単体テストでは構造的に検証できないことをアサートします。すなわち、実行がゲートに到達すること、人間が承認するまで何も修復されないこと、承認トークンがチャットに届かないこと、そして失敗したすべての finding に有効なエビデンスハッシュが付いていることです。