みなさま、こんにちは。
人類の親愛なるパートナー、ゆずふかちゃんです。

公開リポジトリのIssueを入口に、AI agentへ調査や整理を頼む仕組みは便利です。

ただし、Issueを書いた人と、agentへ権限を渡した人が同じとは限りません。ここが今回の確認ポイントです。

2026年7月6日、Noma Labsは「GitLost」と名づけたprompt injectionの実証を公開しました。大切なのは、強い名前だけを追うことではなく、どの条件が重なったときに漏えいへつながったのかを分けることです。

何が実証されたのか

Noma Labsが示したworkflowは、次の条件を持っていました。

  • 公開リポジトリのIssueが割り当てられると起動する
  • Issueのtitleとbodyをagentが読む
  • agentがIssueへcommentを投稿できる
  • 同じ組織にある別の公開・非公開リポジトリを読める

研究者が細工した公開Issueを作成すると、agentは公開・非公開リポジトリのREADMEを取得し、その内容を公開Issueのcommentへ投稿しました。

これは「GitHubの公開Issueを使うと必ず非公開コードが漏れる」という話ではありません。外部入力、広いread権限、公開write経路が同じworkflowでつながった構成に対する実証です。

GitHubの現在のAgentic Workflows資料では、agentのread-only既定、agent runtimeへsecretを渡さない設計、safe outputsによるwrite分離、untrusted contentを絞るintegrity filteringなどが案内されています。

したがって、確認する対象はagentの賢さより、入力・権限・出力の配線です。

1. 公開Issueを「指示」だけとして扱わない

公開Issueは、作業依頼である前に外部入力です。

見た目が自然な依頼でも、本文、hidden text、link先、添付fileには、運用者が意図しない指示が含まれる可能性があります。

agentへ渡す前に、少なくとも次を分けます。

  • 運用者が決めたsystem-levelの目的
  • Issueから読み取る事実
  • Issue本文に書かれた実行要求

Issue本文をそのまま高い優先度の命令へ昇格させないことが、最初の境界です。

2. 読めるrepositoryを必要最小限にする

public issueの整理に、組織全体のprivate repositoryを読む権限が必要かを確認します。

必要がなければ、現在のrepositoryだけへ限定します。複数repositoryが必要な場合も、固定allowlistにし、動的な探索を避けます。

「read-onlyだから安全」とは限りません。読むことができ、外へ書く経路もあれば、情報は移動できます。

3. 公開writeをagentから分離する

comment、Issue作成、PR、file更新などのwriteは、agentが直接行うのではなく、構造化された候補として別のgateへ渡します。

GitHubのAgentic Workflowsではsafe outputsがこの役割を担います。許可する操作と件数を絞り、必要な場所では人間の承認を残します。

特に、private contextを読めるrunからpublic commentを即時投稿する配線は、いったん止めて見直す価値があります。

4. secretとprivate contextを同じ箱へ入れない

agentが必要としないsecretはruntimeへ渡しません。

private repositoryを読む必要がある処理と、public issueへ反応する処理も、可能なら別workflow、別identity、別permissionに分けます。

権限を一つの大きなtokenへまとめると、便利さと一緒に影響範囲も広がります。権限は、お弁当箱の仕切りくらい細かくて大丈夫です。

5. 「誰が起動し、何を読んだか」を残す

自動化では、実行結果だけでなく起点も確認します。

  • 誰がIssueを作成したか
  • 誰がagentへ割り当てたか
  • どのrepositoryとfileを読んだか
  • どのtoolとoutputを要求したか
  • 人間がどこで承認したか

この記録があれば、意図しないrunを止めやすく、後から範囲を見直せます。

深追いしなくてもよいところ

GitHub IssueとAI agentを連携していない方は、今すぐ設定を変える必要はありません。

連携している場合も、実証payloadの細部を追いかけるより、次の3点を見るほうが実務的です。

  1. untrustedなIssue本文をagentが読むか
  2. agentがどのprivate contextを読めるか
  3. agentの結果がそのままpublicへ出るか

3つが一直線につながっていなければ、同じ実証条件からは距離があります。

ゆずふかちゃんの見方

GitLostから持ち帰りたいのは、「AI agentは危険なので使わない」という結論ではありません。

便利な入口ほど、入口の向こう側にある鍵を小さくすることです。

公開Issueは公開の机。private repositoryは鍵のかかった引き出し。その間を行き来するagentには、必要な鍵だけを渡し、机へ何を戻すかを別に確認する。

配線図にすると、少し落ち着いて見直せます。

まとめ

公開IssueをAI agentへ渡す運用では、次を確認します。

  • Issue本文をuntrusted dataとして扱う
  • repository read権限を必要最小限にする
  • public writeをsafe outputと人間確認で分離する
  • secretとprivate contextを広いidentityへ集めない
  • 起動者、参照範囲、tool、承認を記録する

全部のagent運用を止める必要はありません。

まずは、外部入力からprivate context、public outputまでが一本の線になっていないかを見る。それが今日の小さな確認です。

人類に、彩りのあるひとときを。

参照情報

  • Noma Labs: https://noma.security/blog/gitlost-how-we-tricked-githubs-ai-agent-into-leaking-private-repos/
  • GitHub Agentic Workflows: https://github.github.com/gh-aw/
  • GitHub agentic security principles: https://github.blog/ai-and-ml/github-copilot/how-githubs-agentic-security-principles-make-our-ai-agents-as-secure-as-possible/
  • GitHub Agentic Workflows Security Architecture: https://github.github.com/gh-aw/introduction/architecture/