トークンを見せていないエージェントが、認証済みの端末で記事を公開できた（未検証の報告）

何が起きたか

筆者は2026年10月2日、Qiitaへの投稿環境を作った日に、手順書へ作業の 分担表を書いた。アカウントの作成、トークンの発行と入力、pushと公開の 最終判断は筆者が手で行い、login・publish・pull・push・Secretsの設定は エージェントにやらせない作業にした。翌10月3日、限定共有で確認を終えた 記事を全体公開に切り替える操作を、筆者の明示のGoのうえでエージェントが 実行した。公開のコマンドは認証済みの端末で動き、トークンの値を渡さなく ても通った。Zennのリポジトリでも、エージェントがcommitとpushを実行し、 公開（published: true のpush）も明示のGoのあとに行った。

現場の混乱

筆者は10月7日、自分の環境のメタデータを点検した（認証情報の中身は読んで いない）。認証情報のファイルは権限が所有者のみ、Gitの認証はOSの キーチェーンで、リモートのURLにトークンは含まれていなかった。一方、 許可ルールの拒否リストは空、サンドボックスは設定なしで、フックには コミット前のレビューの門はあっても認証情報を守る門はなかった。所有者 のみの権限は、エージェントが筆者と同じユーザーで実行するコマンドには 効かない。

同じ日、エージェントは会話の記録にトークンの値が出ていないかを確かめ ようとして、記録から認証情報の文字列を探すコマンドを実行しかけ、auto modeの分類器に直前で止められた。エージェントは回避せず、確認を筆者に 委ねた。会話の記録、認証情報のファイルの読み取り履歴、環境変数と子 プロセスへの継承、シェル履歴は、いずれも未確認のまま残っている。

原因

筆者は、値をエージェントの目に触れさせない「見せない線」と、認証済みの 操作を実行させない「使わせない線」を分けて考える。手順書の方針は前者で、 後者は分担表の文言だけで守っていた。分担表は誰が何をするかを決めた文書で、 実行できるかどうかを決める仕組みではない。

技術で止める手段にもそれぞれ限界があると筆者は整理している。権限の ドキュメントによれば、読み取りの拒否ルールは組み込みのファイルツールと cat・head・tail・sed・teeなどに効くが、ファイル名を書かない grep -r や 任意のサブプロセスには効かず、Bashのルールはセキュリティ境界ではないと されている。auto modeの分類器については、Anthropicの記事が実際の「やり 過ぎ」の行動52件で見逃し率17%と報告しており、auto modeの設定では作業中 のリポジトリへのpushは既定のブランチを含めて既定で許可されている。

対策

筆者の運用は、技術で強制する線ではなく人の確認で守る線である。公開の前に 差分を見せて明示のGoを得て、最終判断は筆者が下す。エージェントが認証 済みの操作を実行できる状態は変わっていない。公式ドキュメントには permissions.ask に Bash(git push *) を入れて必ず確認を出す例があるが、 git -C <dir> push のような別の書き方は止まらないと書かれている。筆者は、 トークンを見せていないとは主張しないとしている。

エージェントに認証情報を見せないことと、使わせないことは別の対策になる。 エージェントが実行できる認証済みのコマンド（push・publish・API呼び出し）を 洗い出し、技術で止めるか人の確認で守るかを1つずつ決めておくと、どちらで 守っているかが点検できる。