守りたい条件は内側の機構に強制し、型宣言・フロント・プロンプト遵守を信頼境界にしない
セキュリティ
バリデーション
設計判断
API設計
原則
不変条件・絞り込み・安全条件を「守られているはず」で済ませない。最適化するのは「呼び出し側が間違えても破れない強制」、避けるのは「型宣言・フロントの暗黙ルール・プロンプトや呼び出し規律の遵守を信頼境界に置くこと」。守りたい条件は、最も内側で確実に効く機構(サーバ側の検証・正規化、クエリ条件、出力の区切り、明示的な値の組み立て)に落とす。
判断基準
- 型や契約は宣言であって強制ではない。構造的部分型では宣言にないフィールドが素通りして実送信される、ゆるい入力境界が厳格な内部型へ不正値を流して汎用エラーに潰れる、といった乖離が起きる。送る内容は型に宣言し、必要な値だけを明示的に組み立て、境界で内部型に合わせて正規化・厳格化する。
- フロントの暗黙ルール(空なら全体、等)に状態の意味を委ねない。中間状態は API 直叩きや別クライアント、既存不正値から生じるので、サーバ側で正規化して不正値・中間状態にも耐えさせる。
- クライアント側の検証だけに頼らず、同じ条件をサーバ側にも置く多層防御にする。入力品質ゲートはクライアント差に左右されないようサーバ側へ寄せ、hard error・warning・正規化提案に段階を分ける。
- AI や LLM に渡すツール結果へ外部由来データを区切りなく連結しない。「データであって指示ではない」区切りで囲み、認可スコープでの多層防御も併用する。プロンプト遵守を安全境界にしない。
例外・限界
内側強制はコストを伴う(クエリ条件の追加、正規化処理)。真に公開で誰でも読める対象など、強制が不要な範囲は分けて考える。ただし「公開だから何でも自由」と混同しない。
検証
呼び出し側の遵守を外した状態(フィルタを渡さない、不正値・中間状態を直接送る、宣言にないフィールドを混ぜる、注入文言を含む外部データを通す)で、内側の機構が条件を維持し拒否・正規化するかを確認する。
根拠(synthesize 元)
- 392 MCP サーバーの品質改善は入力品質ゲートを先に固める
- 492 MCP/ツールのレスポンスに外部由来データを埋め込む時はプロンプトインジェクションを区切る
- 532 TS の余剰プロパティ検査は変数渡しでは効かず未宣言フィールドが暗黙送信される
- 547 ゆるい入力境界と厳格な内部型の不一致は unmarshal 失敗を汎用エラーに隠す