# Auth Boundary Check

> Auth Boundary Check

- Skill: `thinkyou0714/auth-boundary-check` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/auth-boundary-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/auth-boundary-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/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](../../../src/lab-data-auth/rules/data-auth-principles.md) — データ・認証設計の正本（SoT）