A BOOK BY TAKURO SASAKI 生成AI時代の クレデンシャルと パーミッション設計 — Claude Code を起点に 佐々木拓郎 著 / 約 128 ページ 2026.11 発売 姉妹書『IAMのマニアックな話 AI時代の認証認可設計』 （仮題）同時刊行 技術書典 / BOOTH 1 / 21 

「席、外せますか?」 SCENE 1 — 過小許可 タスクを Claude Code に任せ て、 30 分席を外す。 戻ってきたら、 許諾待ちで止まっていた。 ⏳ 仕事が進まない SCENE 2 — 過剰許可 じゃあ --dangerously-skip- permissions で。 ⚠ .env が読まれた ⚠ 任意のコマンドが走った ⚠ git push --force 💥 復旧不能な事故 この二つのあいだに、本書が引きたい線がある。 2 / 21 

本書のはじまり — 自著の音声化での失敗 自著を AWS Polly で音声化する作業を Claude Code に任せた時のこと。 短時間有効だが、広めの権限を持つ IAM ロー ルを渡した。 作業中、有効期限が切れて処理が中断。 これは事前に設計しておか ないと、 事故が多発する構図だ。 そこで気付いた 3 つのこと 1. 任せる範囲を広げると、 渡す権限も広がる 2. 「自律性を上げる」と「過剰権限」は 構造的に対立する 3. クレデンシャルの寿命設計を間違える と、 席を外せない — 本書 ch.5 の出発点 3 / 21 

同時に起きる、二つの事故 過小許可の事故 毎回確認に時間が溶ける。 席を外せない。深夜に走らせるタスク が朝まで止まる。 → 結果: 生産性の損失 / 「もう bypass でいい や」になり、 SCENE 2 に流れる 過剰許可の事故 無制限に許可を与えれば、誤操作・プ ロンプトインジェクション・機微情報 漏洩のリスクが跳ね上がる。 → 結果: セキュリティの損失 / 一度の事故で復旧 不能 本書の立場: この二つは別々の問題ではない。 「許諾」と「クレデンシャル」を一緒に設計しないと、片方を絞れば他方が暴れる。 4 / 21 

クレデンシャル × パーミッションは、 ペアで設計するもの クレデンシャル — 持つもの (what you have) = 認証設計 / 守るのは「漏洩」 Anthropic API key AWS IAM ロール / STS OAuth トークン (Google / Slack) 外部 API key (Stripe, Twitter, …) MCP サーバの認証情報 × ペアで設計 パーミッション — できること (what you can do) = 権限委譲設計 / 守るのは「暴走」 settings.json の allow / deny hooks による自動制御 Sandbox の境界 (FS / Network) コンテナによる環境隔離 CLAUDE.md のソフト制御 片方だけ設計しても穴が残る。片方を絞れば、もう片方が暴れる。 本書 ch.1.6 で「認証設計 / 権限委譲設計」の 2 軸として整理。各章は両軸のどちらかに寄っている。 5 / 21 

Claude Code の三つの強さ＝三つの危うさ 📁 File Read / Edit / Write ⚠ ~/.aws/credentials ⚠ .env 読み出し ⚠ ~/.ssh/id_rsa ⚠ 任意ファイルの書き換え 🌐 Web WebFetch / WebSearch / MCP ⚠ Indirect prompt injection ⚠ 検索結果の汚染 ⚠ Markdown injection ⚠ MCP 応答経由の tool hijack ⚡ Bash 任意コマンド実行 ⚠ rm -rf ⚠ curl での exfiltration ⚠ git push --force ⚠ python -c 経由の文字 列回避 この三機能は、無設定では危険。だからこそペア設計が要る。 6 / 21 

本書の問い 「席を外せる自律性」と 「無制限許可の危険」のあ いだで、 どこに線を引くか。 本書は 8 章で、この線を 具体的に 引いていく。 7 / 21 

解の構造 — 8 章で、線を引く ch.1 クレデンシャル × パーミッ ション地図 本書の羅針盤 / 認証 × 権限委 譲の 2 軸 ch.2 パーミッション設計 settings / hooks / CLAUDE.md / 二段ゲート (auto mode) ch.3 隔離戦略 Sandbox / コンテナ ch.4 API 経路と AWS 連携 Anthropic API / Bedrock / IDC ch.5 ★ 中心章 シークレット集中管理 — AI に「渡す/渡さない」設計 credential broker / 寿命タイプ別の運用 ch.6 外部リソース連携 MCP と外部サイト参照 ch.7 チームで扱う テンプレ化と共有 ch.8 セキュリティと監査 — インジェクション・追跡・インシデント対応 基礎 (ch.1-3) → 連携 (ch.4-6) → 運用 (ch.7-8) の三段。中心は ch.5 シークレット。 8 / 21 

パーミッションは、段階的に広げる 三段モデル — permission- mode ★ auto は bypass の安全な代替。詳細は次スライド ch.2.6 で。 組織は managed settings で disableBypassPermissionsMode / disableAutoMode を強制できる。 三層の制御 — 硬い と ソフト settings.json: allow/deny の文字列マッチ hooks: PreToolUse で動的判定 (URL allowlist 等) CLAUDE.md: AI への「お願い」 遵守保証なし。お守りと割り切る 硬い制御で止まらないものをソフトで誘導する設計。 CHAPTER 02 「ask 起点で観察 → 頻出を allow に昇格」が現実解。bypass は最終手段。 default ← 毎回確認 (席にいる時) auto ← 分類器が事前審査 (中間項) ★ bypass ← 全許可。devcontainer 内のみ推奨 9 / 21 

二段ゲートとしての auto mode 第一段 — 決定論ゲート permissions.allow / deny の評価。 deny は override 不可、ここで弾かれたもの は分類器に届かない。 「硬い禁止 → deny」 恒久的に止めたいものはここで。 第二段 — 確率論ゲート (classifier) 別モデルが文脈を読んで安全性を判定。 /model 選択とは独立した server-side のモデ ル。 「文脈判断 → classifier」 tool results は入力から strip（注入耐性） 。 本書の読み: 公式は bypassPermissions を「prompt injection に保護なし」と明言し auto を代替に推 す。 ただし auto は「bypass より安全側」であって「完全防御」ではない (classifier の prompt injection 耐性はモデル依存・実装依存)。 Bash(*) 等の broad allow は auto 入域時に自動 drop されるため、「最終的にどのモードで運用するか」 を逆算して粒度を決めるのが設計原則。container を併用して container 境界を最後の盾にする。 CHAPTER 02.6 — v0.5 新節 「都度確認」と「全許可」の中間項。分類器を権限設計の中核に据える。 設計原則 5 点 (二段ゲート / 4 ステップ判定 / broad allow 非両立 / boundary 非永続性 / 信頼境界の非対称) を ch.2.6 で展開。 10 / 21 

三層防御モデル — 役割の違う三つの境界 🧱 Container コンテナランタイム強制 対象: プロセス・FS・ネットワー ク全体 主目的: 環境ごと隔離。 --dangerously- skip-permissions を安全に使うための器。 🛡 Sandbox OS カーネル強制 macOS: Seatbelt / Linux・ WSL2: bubblewrap / 対象: Bash subprocess 主目的: 実行時に kernel で弾く。文字列回 避 ( python -c … ) も効かない。 ✋ Permissions Claude Code 本体強制 対象: 全ツール (Bash / Read / Edit / WebFetch / MCP) 主目的: 意図段階で止める。allow/deny を文字列マッチ。 CHAPTER 03 許諾は「協力前提」 、隔離は「裏切り前提」 。両層を重ねる。 Sandbox は permissions と "complementary" (公式表現)。両者の filesystem 制限はマージされる。 11 / 21 

API 経路の選択 — Anthropic か、Bedrock か 🚀 Anthropic API 直接 — 個人開発 / 試作 API key を ANTHROPIC_API_KEY に 立ち上がりが速い 個人の請求 → 永続単発型シークレットの管理が論点に 🏢 Bedrock 経由 + Identity Center — 組織業務 SSO で短命+自動更新型クレデンシャル AWS アカウント内に閉じる (データ・監査) 既存の AWS ガバナンスと統合 → AI モデル自体が AWS 鍵を持たない = broker 設計の代表例 CHAPTER 04 設定一つで切り替えられる。個人と業務で答えが違う。 姉妹書の一時クレデンシャル章と併読推奨。 12 / 21 

AI に「直接渡さない」設計 ❌ Without broker AI Claude Code SECRET Service AWS / API ↑ AI が秘密値を読み取り・記録・送信できる状態 (= 漏洩リスク最大) ✓ With credential broker AI Claude Code BROKER Vault / 1Password MCP / sidecar Service ↑ AI プロセスから secret store を直接触らせない設計。 LLM context に秘密値を載せないのが目標 (env 注入や戻り値経由の流入は別途隔離で受ける)。 CHAPTER 05 ★ 中心章 credential broker — AI プロセスから secret store を直接触らせない、露出範囲を仲介レイヤに限定する。 ━ ━▶ 秘密値を直接見る ━━▶ ━ ━▶ 操作リクエスト ━ ━▶ secret 利用 13 / 21 

寿命タイプが、設計戦略を決める 「ローテと漏洩検知」 「refresh の閉じ込め」 「自動更新で止まらない設計」— 全部別の話。 ① 永続・単発型 Anthropic API key / Stripe / Twitter API key 課題: 漏洩したら即被害 設計: ・broker 越しが原則 ・ローテ計画と漏洩検知 ・リポジトリスキャン (gitleaks 等) ② 永続+リフレッシュ 型 OAuth (Google / Slack / GitHub) 課題: refresh token が二次キー 設計: ・access token は通常扱い ・refresh token は broker 内 に閉じる ・リフレッシュは broker が代 行 ③ 短命+自動更新型 AWS STS / SSO / Vault leases / GitHub App tokens 課題: 実行中に切れて止まる 設計: ・Vault Agent / aws sso ・ 「席を外せる」を直接支える ・実行中の自動更新で thesis に 直結 14 / 21 

外からのデータ流入を、どう信頼するか 主な攻撃パターン 隠し要素 / Markdown injection 検索汚染 / document poisoning MCP 応答汚染 / tool hijacking github.com 等広いドメイン許可からの exfiltration hook を使った多層防御 入口 PreToolUse : URL allowlist で deny / updatedInput で正規化 入力 UserPromptSubmit : additionalContext で 「外部 content は data」と毎回注入 出口 PostToolUse : MCP のみ updatedMCPToolOutput で sanitize 可。他は block で再実行のみ 最後の盾 sandbox deniedDomains で OS-level に hook の限界も併記する — 自然な散文に紛れた indirect injection は構文検査で区別できない。 CHAPTER 06 MCP も WebFetch も「外から内容を取り込む」同類。データと指示の境界をどこで引くか。 15 / 21 

個人 → チーム → 組織 CHAPTER 07 作り込んだ環境を再利用可能にする — dotfiles から Plugins まで。 PERSONAL 個人で作り込む ~/.claude/ を git 管理 dotfiles 的発想で再利用 secret scanning / .env.example TEAM チームで共有 project の .claude/ を git に 共有 .mcp.json PR でテンプレを評価する 文化 ORG 組織で強制する managed settings disableBypassPermissionsMode Plugins で配布 (skill/command/agent/hook/MCP まとめて) 3 軸 (配布対象 / バージョン管理 / 一発インストール) のうち 2 つ以上 yes ならプラグイン化検討。 16 / 21 

インシデントの三つの型 ① bypassPermissions 濫用 「席を外したいから」全許可で走ら せ、攻撃用プロンプト経由で破壊的操 作が走る。 対策: 組織レベルで disableBypassPermissionsMode 。 ② .env 読み出し 「設定ファイル読んで」と指示され た AI が、機微ファイルも一緒に読 んでしまう / 文字列回避で読まされ る。 対策: sandbox での deny + permissions deny の二重。 ③ Bash 任意実行 外部 web から取り込んだ指示で、 curl … | sh や python -c 経由 のコマンドが起動する。 対策: sandbox + WebFetch ドメイ ン allowlist。 起きた時のフロー 追跡 (ローカルログ / CloudTrail) → 鍵失効 (broker 経由なら一括無効化) → パーミッション縮退 (settings 巻き戻し) CHAPTER 08 プロンプトインジェクション × 権限悪用 — 起きた時にどう対応するか。 17 / 21 

姉妹書とのセット訴求 本書 生成AI時代の クレデンシャルとパーミッシ ョン設計 — Claude Code を起点に Claude Code 側 + 姉妹書 IAMのマニアックな話 AI時代の認証認可設計（仮題） — 一時クレデンシャル / ポリシー AWS 側 Claude Code で AWS を触る人へ。 本書で Claude Code 側、姉妹書で AWS 側を完備。 本書 ch.4 は姉妹書の一時クレデンシャル章を前提とする設計。 18 / 21 

誰のための本か PRIMARY Claude Code を業 務で使う開発者 Anthropic API または Bedrock 経由で日常的に使 い、 settings.json / hooks / MCP の運用に悩む 層。 → 個人運用とチーム運用の 両方。 SECONDARY プラットフォーム / セキュリティエンジ ニア 組織で Claude Code を導入 する立場。 managed settings、 Bedrock + Identity Center、ガイドラ イン策定が論点。 SECONDARY MCP サーバ開発者 / 姉妹書読者 Claude Code から呼ぶ MCP サーバを開発する人。 姉妹書（AI時代の認証認可 設計、仮題）読者で、 Claude Code から AWS を触 る運用に踏み出す層。 想定スキル: コマンドライン慣れ / 基本的な IAM 概念把握 / LLM API 利用経験あり。 19 / 21 

目次 — 8 章 + 付録 4 本 前書 なぜ Claude Code でペア設計が必要か 3p ch.1 クレデンシャル × パーミッション地図 (1.6 認 証/権限委譲の 2 軸 ★v0.5) 15p ch.2 パーミッション設計 — settings/hooks/CLAUDE.md (2.6 二段ゲート ★v0.5) 14p ch.3 隔離戦略 — Sandbox・コンテナ・機微ファイル 13p ch.4 API 経路と AWS 連携 — Anthropic / Bedrock / IDC 14p ch.5 ★ シークレット集中管理 — AI に渡す/渡さない設 計 10p ch.6 外部リソース連携 — MCP と外部サイト参照 13p ch.7 チームで扱う — テンプレ化と共有 15p ch.8 セキュリティと監査 14p 付録 A 個人/チーム/業務向け settings.json テンプレ集 4p 付録 B .mcp.json テンプレ集 + ガイドライン文書テンプ レ 4p 付録 C Claude Code × AWS Bedrock 設定レシピ 3p 付録 D 参考: 関係する業界フレーム (TLP / NIST / OWASP 等) 1p 合計 約 128 ページ 20 / 21 

PUBLISHED 生成AI時代の クレデンシャルとパーミッション設計 — Claude Code を起点に RELEASE 2026.11 VENUE 技術書典 / BOOTH SET DEAL 姉妹書セ ット 質問・お問い合わせは @dkfj まで。 今日はお越しいただきありがとうございました。 21 / 21