Black Hat USA 2026 AI Agentセキュリティ

最終更新日：2026年7月29日。Black Hat USA 2026は2026年8月1日から6日までラスベガスで開催されます。公式スケジュールを公開前に確認したうえで、今週は自社のリモートMacを1台選び、AI Agentの受け入れ試験を実施してください。

結論は明確です。Agent専用のサービスアカウント、最小権限、秘密情報を保存しない設計、制限された通信先、追跡可能なログ、短時間で削除できる環境がそろわない限り、本番利用は不合格です。ウイルス対策ソフトを入れるだけ、ログインユーザーを限定するだけでは、企業向けの安全基準になりません。

この確認表は、次の担当者向けです。

非公開リポジトリへコーディングAgentを接続する開発チーム
リモートMacで署名、ビルド、デプロイを自動化するDevOps担当者
AI Agentの導入条件を決めるセキュリティ責任者、コンプライアンス担当者

まず失敗経路を5分で再現する

典型的な失敗は、Agentに悪意がある場合だけ起きるものではありません。作業ディレクトリに置かれた設定ファイルをAgentが読み、そこからAPIキーや署名関連の情報を取得し、ビルドログや外部ツールの入力へ含めてしまう流れです。

その後、同じMacを別の担当者や別のタスクが使うと、シェル履歴、キャッシュ、ログ、テンポラリーファイルに残った情報が再利用されます。原因がAgentの操作なのか、人間の操作なのか分からなければ、事故後の責任分界もできません。

Black Hat USA 2026の公式Briefingsには、AIブラウザー、認証情報の窃取経路、Agenticシステムの脅威モデル、AIを利用した検知などのセッションが掲載されています。ただし、開催前に未公開研究の結論を断定してはいけません。現時点で確実に使えるのは、公開済みの議題を自社の検証項目へ落とし込むことです。Briefingsの公式一覧を確認し、会期中に新しい攻撃手法が公開された場合だけ基準を更新してください。

1. 専用アカウントから責任分界を確認する

最初に見るのはMacのログイン画面ではなく、Agentがどのサービスアカウントで動くかです。人間のGitアカウント、共有管理者アカウント、個人の長期アクセストークンをそのまま使っている場合は、原則として不合格です。

AI Agentがコードリポジトリへアクセスしても安全か

安全かどうかは、リポジトリ名だけで決まりません。専用サービスアカウント、対象リポジトリの限定、読み取りと書き込みの分離、実行者とタスクIDの記録が必要です。クラウド側の認証では、長期キーより短時間トークンを使う構成が優先されます。

GitHub Actionsでは、OIDCを使ってクラウド側の短期トークンへ交換する方式が案内されています。GitHubのOIDC公式資料を基準に、リポジトリ、ブランチ、ワークフロー単位で信頼条件を設定してください。

確認する証拠は、サービスアカウントの設定画面、トークンの有効期限、リポジトリ別の権限一覧、Agentタスクと人間の承認者を結び付けた監査ログです。

2. 秘密情報が落ちる場所を洗い出す

署名証明書やAPI資格情報は、環境変数だけを見ても不十分です。タスクを実行した直後に、次の保存場所を確認します。

環境変数
.env、設定ファイル、作業ディレクトリ
シェル履歴、標準出力、ビルドログ
Agentの会話履歴、ツール呼び出し履歴
依存関係のインストールログ
キャッシュ、クリップボード、テンポラリーファイル
macOSのキーチェーン項目とアクセス許可

macOSのキーチェーンには、パスワード、暗号鍵、証明書などを保存できます。Keychain Servicesの公式ドキュメントを確認し、Agentがキーチェーン全体を読める状態を標準にしないでください。

確認対象	合格条件	即時ブロック条件
APIトークン	タスク単位で発行し、終了時に失効できる	失効手段がない長期トークン
署名証明書	署名処理だけに限定し、秘密鍵を作業フォルダーへ出さない	秘密鍵を平文ファイルで保管
ログ	値をマスキングし、タスクIDと結果だけ残す	トークン、Cookie、秘密鍵がそのまま記録される
シェル履歴	秘密情報をコマンド引数へ渡さない	`export`やCLI引数に秘密情報が残る
失効操作	担当者が即時に無効化できる	失効が申請制で、完了時刻を確認できない

コーディングAgentが署名証明書を漏らすことはあるか

可能性はあります。Agentが証明書を盗む必要はありません。署名コマンドの引数、エラーメッセージ、検索対象のファイル一覧、ビルド成果物の診断ログから、秘密に近い情報が出る場合があります。

証明書の存在と秘密鍵の利用権限を分け、Agentには署名処理に必要な最小操作だけを許可してください。署名を実行する場合は、成果物のハッシュ、承認者、実行時刻、使用した証明書の識別情報を記録します。

3. Agent権限をコマンド単位で分離する

リモートMacでAgent権限をどう分離するか

「一般ユーザーで実行する」だけでは足りません。Agentが呼べるコマンド、書き込めるディレクトリ、接続できるサービスを個別に定義します。

macOSアプリのApp Sandboxは、ファイル、ネットワーク、ハードウェアへのアクセスを権限として制限できます。ただし、シェルから動く開発ツールや自動化ランナーに同じ保護が自動適用されるとは限りません。Agent実行基盤側でも許可リストを実装してください。

合格基準は次の通りです。

読み取り対象のリポジトリと書き込み対象の出力先が固定されている
sudo、システム設定変更、ユーザー追加、LaunchDaemon登録を標準で拒否する
依存関係の追加、外部スクリプトの実行、署名処理は別の承認ステップに分ける
高リスク操作では、承認者、時刻、理由、実行結果を記録する
失敗時に権限を拡大して再試行する動作がない

操作	通常のAgent	人間の確認が必要な操作
ソースコードの読み取り	許可	非公開領域全体の走査は拒否
単体テスト	許可	ネットワーク接続を伴う場合は宛先確認
ファイル作成	専用作業領域のみ許可	ホーム、キーチェーン、システム領域への書き込み
パッケージ追加	事前承認済みの依存先のみ	任意URLからのスクリプト実行
署名・公開	原則として分離	必ず人間の承認と成果物確認

4. ネットワーク出口とデータ外部送信を固定する

Agentが安全でも、接続先が無制限ならデータ外部送信の経路になります。モデルAPI、Gitリポジトリ、パッケージレジストリ、アーティファクト保管先を一覧化し、DNS、HTTPSプロキシ、ファイアウォールのいずれかで許可先を制限してください。

検査対象はプロンプトだけではありません。ソースコード、差分、ビルド成果物、スクリーンショット、エラーログ、環境変数の一部も外部送信される可能性があります。

会期中に公開されるAI関連の研究を取り込む場合も、まず「どの入力がどの外部サービスへ送られるか」を確認します。公開デモをそのまま自社環境へ持ち込むのではなく、通信先とデータ分類を先に照合してください。

5. 1タスク分の操作を復元できるログにする

ログは量ではなく、再現性で評価します。最低限、次の5項目を同じタスクIDで追える状態にします。

どの人間またはサービスアカウントが開始したか
どのAgent、モデル、ツールを使ったか
どのコマンド、ファイル、URLを対象にしたか
どの承認を経て高リスク操作を実行したか
成功、失敗、拒否、外部送信の結果は何か

一方で、秘密情報や業務データをそのまま集めてはいけません。トークンは末尾数文字だけ、ファイル内容はハッシュや分類ラベルだけにするなど、監査に必要な粒度へ落とします。

NISTの監査・ログ管理の考え方でも、記録対象のイベントを選び、監査証跡を保護することが重視されています。NIST SP 800-53の関連資料を基準に、ログの保管先と閲覧権限も確認してください。

6. 作業終了後に環境を消去する

共有デスクトップを長期間使い回す構成は、高い機密性が必要な署名や秘密リポジトリには向きません。タスク終了後に、次の項目を削除または失効できるか確認します。

作業ディレクトリと圧縮ファイル
Agentの会話履歴とツールキャッシュ
シェル履歴と標準出力
一時的なSSH鍵、APIトークン、署名権限
クリップボード、ダウンロード、ビルドキャッシュ
リモートアクセス用セッション
監査ログ以外のユーザーデータ

削除コマンドを実行しただけで合格にしないでください。新しいタスクを開始し、前のタスクのファイル、認証情報、プロセス、ネットワークセッションが残っていないことを確認します。高い機密性が必要なら、再構築できる専用環境をタスクごとに用意し、共有Mac上の長期セッションを避けます。

7. 受け入れ試験を3段階で判定する

次のチェックリストを、安全担当者とDevOps担当者が同じ証拠を見ながら実施してください。

[ ] Agent専用のサービスアカウントを発行した
[ ] 人間の操作とAgentの操作を監査ログで区別できる
[ ] リポジトリ、ディレクトリ、コマンドの許可範囲を一覧化した
[ ] 共有管理者アカウントと個人の長期トークンを使用していない
[ ] API資格情報と署名鍵を作業ディレクトリへ保存していない
[ ] ログ、シェル履歴、キャッシュに秘密情報が残らない
[ ] すべての外部接続先を許可リスト化した
[ ] プロンプト、ソースコード、成果物、ログの送信先を確認した
[ ] 高リスク操作に人間の承認と記録がある
[ ] 1タスクの開始から終了まで操作を再現できる
[ ] タスク終了後に資格情報を失効できる
[ ] 環境を再構築または安全に削除できる

判定は「合格」「期限付き是正」「導入禁止」の3段階に分けます。合格は限定された本番タスクへ進めます。期限付き是正は、期限、担当者、再試験日を記録します。導入禁止はAgentを停止し、環境を再構築します。

判定	条件	次の処置
合格	12項目を満たし、証拠を保存済み	限定された本番タスクへ段階導入
期限付き是正	低リスクの記録不足や運用上の不備	期限、担当者、再試験日を設定
導入禁止	失効不能な長期資格情報、不可視の高権限操作、無制限の外部通信	Agentを停止し、環境を再構築

注意：マルウェア検知が正常でも、Agentが正規の資格情報を正規のコマンドで読み出せば、セキュリティ製品だけでは止められません。受け入れ試験では、拒否されるべき操作を実際に実行し、拒否ログと承認フローまで確認してください。

既存の運用とMac環境を比べて決める

現在の共有サーバーや一般的なクラウド開発環境を使い続ける選択にも合理性はあります。ただし、リモートMacで署名、Xcodeビルド、Apple向け自動化を行う場合、LinuxやWindows中心の構成では、Mac固有のキーチェーン、署名権限、GUIセッション、廃棄手順が別管理になりやすい点が弱点です。

方式	強み	セキュリティ上の注意
共有の既存開発環境	既存の監視と運用を流用しやすい	セッション、キャッシュ、権限が混在しやすい
一般的なクラウド環境	自動化と短期リソース化がしやすい	Mac固有の署名・GUI検証を別途設計する必要がある
専用のリモートMac	Apple向けビルドと署名環境を分離しやすい	Agent権限、資格情報、削除フローを明文化する必要がある

長期の重い処理を常時実行し、物理デバイスや社内ネットワークへ直接接続するなら、自社管理の専用Macが適する場合があります。一方、短期の検証、リリース前の署名確認、Agentの安全試験では、必要な期間だけ分離したリモートMacを使う方が、共有環境の残留リスクを減らしやすいです。

VPSSparkのサービス構成を検討する場合は、まずVPSSparkのサービス概要で利用形態を確認してください。さらに、許可するコマンド、資格情報の保管方法、環境の回収手順を整理したうえで、VPSSparkへのお問い合わせ窓口へ必要な隔離条件や接続要件を伝えると、導入前の確認を進めやすくなります。今回のチェックリストをそのまま事前確認票として使うのが安全です。

Black Hat USA 2026の会期中は、公式BriefingsやArsenalで公開された内容を毎日確認し、認証情報の外部送信、Agentの権限越境、監査不能な自律実行に関する新しい知見が出た場合だけ、社内の阻断条件を更新してください。現時点での最低ラインは、専用アカウント、最小権限、秘密情報の非永続化、通信先の固定、操作監査、迅速な環境削除です。これを満たせない運用は、Macかどうかに関係なく本番へ進めないでください。