Auth boundary check

Purpose

「権限の穴」や「過剰な権限付与」を本番前に発見する。 認証（誰か）と認可（何ができるか）の境界を明示し、最小権限の原則からの逸脱を点検する。

Use When

• 認証・認可の仕組みを設計／変更するとき
• 新しいロール・権限を追加するとき
• 「この API、誰でも叩けてしまわないか」と不安なとき
• risk-scan で認証・認可リスクを深掘りしたいとき

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 対象: 確認する機能・API・画面・データ
• 主体（ロール）: アクセスしうる利用者の種別
• 期待する境界: 誰に許可し、誰を拒否したいか
• 認証方式: 現在の認証・セッション・トークンの仕組み

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: 最も危険な権限境界はどこか
2. 根拠: その論点をそう判断した理由
3. 権限境界マップ: 主体 × リソース × 操作（許可/拒否）
4. 含意: 境界の穴が悪用された場合の影響
5. 改善案: 最小権限化・境界の明確化の打ち手
6. 代替案: 別の認可方式（RBAC / ABAC / 行レベル）
7. 判断材料: 認可設計の確定に必要な人間の確認事項

Review Lens

• 目的妥当性: 境界が業務上の必要性と一致しているか
• 範囲の過不足: 過剰権限／権限不足がないか（最小権限）
• 中長期リスク: ロール増殖で管理不能にならないか
• LAB全体との整合性: LMS / 自動化 / B2B 展開の権限要件と整合するか
• 非エンジニア理解可能性: 「誰が何をできるか」を関係者に説明できるか
• 他LLM移植耐性: 判断が特定認証製品の前提に依存していないか

Instructions

1. 主体（ロール）とリソース・操作の組み合わせを表に展開する
2. 各セルを「許可 / 拒否 / 条件付き」で埋める
3. 「拒否すべきなのに許可」になっている穴を特定する
4. 最小権限から逸脱した過剰権限を指摘する
5. 認証の前提（セッション失効・トークン漏洩時の影響）を確認する
6. 不明な要件は推測せず、確認事項として明示する

Guardrails

• 「とりあえず管理者権限」を許容しない（最小権限を促す）
• 認可を UI 制御だけに頼らない（サーバ側境界を確認）
• 権限変更をロールバック方針なしに勧めない
• 認可設計の最終確定は人間に委ねる

LAB Cross-Check

観点	状態	備考
自動化フロー	—	自動化処理の実行権限が過剰でないか
データ / 認証 / ログ	—	行レベル権限・認証失敗ログを確認したか
実装 / 運用フロー	—	権限変更の運用手順が存在するか
非エンジニア理解可能性	—	権限境界を関係者に説明できるか
会員共有 / 再利用耐性	—	認可設計が他機能にも転用できるか
他LLM移植耐性	—	判断が特定認証製品に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。

• 要件: 確定した権限境界（主体 × リソース × 操作）
• 成功条件: 境界が想定通りに機能すると判断する基準
• 失敗条件: 権限の穴を検知する基準
• 実行範囲: 変更してよい認証・認可・ポリシー設定
• 影響範囲: 権限変更が波及する機能・利用者
• ロールバック方針: 権限変更が問題を起こした場合の戻し方
• コスト比較: 認可方式ごとの実装・運用コスト

Further Reading

• auth-system-design skill — 点検する認証の仕組みそのものを上流で設計する
• risk-scan skill — 認証・認可を含む広範なリスクスキャン
• data-model-review skill — 行レベル権限を支えるデータ設計
• access-control-matrix skill — 権限マトリクスの体系的な設計
• audit-log-design skill — 認証・権限イベントの監査ログ
• data-auth-principles.md — データ・認証設計の正本（SoT）