# Effective Instruction Contract Envelope CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-520-effective-instruction-contract-envelope CLAIM_IDS: none EVIDENCE_IDS: EA-520-CURRENT-APPROVAL, EA-520-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-520-UNKNOWN-01 OPS_IDS: none ## Summary 「system instructionを設定した」ことと「そのinstructionが実行時に常に強制された」ことを同一視しない。監査可能なのは、組織が管理するinstruction revision、観測可能なprovider/model/runtime/configuration、明示したcomposition、指定した評価条件で得たbehavioral evidenceである。hidden provider instructionや未観測の内部policyは、公開された証拠がない限りUNKNOWNとする。instruction hierarchyは重要な制御層だが、consequential actionの外部authorizationやreadbackを代替しない。 ## Current judgment 「system instructionを設定した」ことと「そのinstructionが実行時に常に強制された」ことを同一視しない。監査可能なのは、組織が管理するinstruction revision、観測可能なprovider/model/runtime/configuration、明示したcomposition、指定した評価条件で得たbehavioral evidenceである。hidden provider instructionや未観測の内部policyは、公開された証拠がない限りUNKNOWNとする。instruction hierarchyは重要な制御層だが、consequential actionの外部authorizationやreadbackを代替しない。 ## Scope Effective Instruction Contract Envelope ## Confirmed ## UNKNOWN - EA-520-UNKNOWN-01: - provider/runtimeがhidden policy変更をどの粒度で外部へ通知・readback可能にするか。 - provider横断で移植可能なeffective-instruction manifestの最小共通schema。 - multilingual・長文・複数tool/RAG/memory同時競合に対する用途別の十分なtrial設計。 - evaluator independenceをどの程度要求すれば監査上十分か。 - 実運用でinstruction-contract driftが直接事故へ結び付いた独立incidentの一般化可能な証拠。 ## Evidence - EA-520-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-520-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits system instructionが存在するため安全だと誤認し、retrieval/tool/memory経路からの競合instructionを評価しない。 ## Failure / limits provider/model更新後も旧回帰結果を有効とみなす。 ## Failure / limits hidden provider policyの内容を推測し、監査証拠として扱う。 ## Failure / limits system promptの秘匿をアクセス制御やsecret managementの代替にする。 ## Failure / limits 単発テストまたは一つのbenchmarkで「instruction遵守」を保証済みとする。 ## Failure / limits evaluator自体が同一モデル・同一failure modeに依存し、失敗を見逃す。 ## Failure / limits multilingual、長文、tool/RAG併用時の競合を評価対象から外す。 ## Failure / limits provider documentationは文書化された入力・設定境界を示すが、全てのjailbreak/injectionに対する完全なenforcementを保証しない。 ## Failure / limits JustAsk等の研究は特定のモデル・手法・時点に依存し、全provider・全versionで同一の抽出可能性を証明しない。 ## Failure / limits PCFI/PhishNChips等の研究結果は評価設定依存であり、本番環境の普遍的防御率ではない。 ## Failure / limits provider内部policyの変更が常に外部へ明示的revision signalとして公開されるとは限らない。 ## 要点と前提 CANDIDATE_ID: ORPHAN-RESCUE-EA520-20261019-C1 ## 要旨 Enterprise AIで「system instructionを設定した」という事実は、その指示が実行時にどのような優先順位で合成され、どの経路から干渉され、どの程度の確率で守られたかを証明しない。運用上必要なのは、宣言したinstruction bytesだけでなく、provider/model/API/runtime、role/priority、tool・RAG・memory等の注入経路、公開されている安全設定、評価条件を一つの有効命令契約として版管理し、変更時に回帰評価することである。 ## 主要claim ### 1. 宣言されたinstructionと実効的なenforcementは別物である system/developer/user/retrieved instructionは、モデルに与えられる入力契約の一部である。しかし、その存在だけから「必ず従う」「下位instructionから上書きされない」「秘密として保持される」を導いてはならない。Google Gemini Enterprise Agent Platformのsystem-instruction guidanceはsystem instructionsがrequest全体へ適用される一方、jailbreakやleakを完全には防げない旨を明示している。したがって、instruction presenceはsecurity enforcementの証明ではない。 運用上は、少なくとも次を分離して記録する。 - declared instruction artifact: 組織が管理できるsystem/developer等の本文、hash、revision。 - composition contract: role/priority、連結順、retrieval/tool/memory等がどこへ挿入されるか。 - provider/runtime state: model/API/runtime、安全設定など外部に観測可能な実行条件。 - observed enforcement: conflict、prompt injection、tool/RAG/memory注入を含む評価結果。 ### 2. hidden provider instructionを「既知の正本」として扱わない providerが内部で追加するhidden policy/system textの完全なbytesは、providerが明示的に公開・readbackしない限りUNKNOWNである。モデル挙動から内容を逆算して正本化してはならない。また、hidden system promptは機密境界そのものでもない。JustAsk（arXiv:2601.21233）は商用モデルを含むblack-box system-prompt extractionを研究対象としており、少なくとも「system roleに置けば秘密になる」という一般化を否定する反証となる。 従って、監査記録では「組織が設定したinstruction」「providerが文書化したpriority/policy」「観測された挙動」「非公開でUNKNOWNな内部instruction」を別欄にする。 ### 3. instruction contractはprovider/model/runtimeまで含めてversion bindingする 同じprompt本文でも、model revision、API/runtime、tool schema、retrieval構成、安全設定、memory injection、provider policyの変更により実効挙動は変化し得る。PCFI（arXiv:2603.18433）やPhishNChips（arXiv:2603.25056）は、role/priority-aware enforcementやprompt-model configurationがsecurity evaluationへ影響することを示す研究 evidence である。これらは普遍的な防御率を証明しないが、「prompt本文だけを固定しても実効契約は固定されない」という境界を支持する。 最低限、評価対象には provider / model ID / API or runtime revision / declared instruction hash / role composition / tool・RAG・memory経路 / exposed safety settings / evaluator / corpus / trial policy / timestamp を結び付ける。material change後は以前のPASSを自動継承しない。 ### 4. regression testはinstruction hierarchyの衝突を含める 通常ケースだけのgolden testでは不足する。少なくとも、下位roleからの上書き要求、retrieved content内の命令、tool result内の命令、memory由来instruction、長文での競合、拒否・許可境界、instructionの欠落・重複・順序変化をnegative fixtureとして持つ必要がある。 ただし、LLM出力は確率的であり、単発PASSは契約保証ではない。評価はtrial数、sampling条件、判定器、failure定義を固定し、許容閾値は用途のriskに応じて組織側が定める。研究benchmarkの成功率をそのまま本番SLAへ移植してはならない。 ## failure modes - system instructionが存在するため安全だと誤認し、retrieval/tool/memory経路からの競合instructionを評価しない。 - provider/model更新後も旧回帰結果を有効とみなす。 - hidden provider policyの内容を推測し、監査証拠として扱う。 - system promptの秘匿をアクセス制御やsecret managementの代替にする。 - 単発テストまたは一つのbenchmarkで「instruction遵守」を保証済みとする。 - evaluator自体が同一モデル・同一failure modeに依存し、失敗を見逃す。 - multilingual、長文、tool/RAG併用時の競合を評価対象から外す。 ## control / implementation implication 1. 組織管理instructionをimmutable revisionとして保存し、hashを付与する。 2. role/priorityとtool・RAG・memoryの挿入点を構成manifestに記録する。 3. provider/model/API/runtimeと公開安全設定を評価receiptへ固定する。 4. 正常系に加え、role conflict、retrieved prompt injection、tool-result injection、memory conflict、長文・多言語をriskに応じたnegative suiteへ含める。 5. material changeを検出したら旧PASSを失効候補とし、再評価する。 6. consequential actionではinstruction遵守だけに依存せず、tool側authorization、schema validation、approval、idempotency、readback等の外部controlを併用する。 7. hidden provider stateがreadback不能ならUNKNOWNとして残し、観測可能なconfigurationとbehavioral evidenceで境界を明示する。 ## 適用境界 このcontrol modelは、system/developer instruction、RAG、tool、memory等を組み合わせるagent/LLM runtimeの変更管理と回帰評価に適用する。特定providerの内部priority実装やhidden policy bytesを共通仕様として一般化しない。provider文書はそのprovider/runtimeの契約証拠であり、研究論文は評価条件内の反証・failure evidenceである。 高リスク操作ではinstruction hierarchyは一つの防御層に過ぎず、IAM、policy enforcement point、tool authorization、approval、transaction/readback等を置き換えない。 ## counterevidence / limitations - provider documentationは文書化された入力・設定境界を示すが、全てのjailbreak/injectionに対する完全なenforcementを保証しない。 - JustAsk等の研究は特定のモデル・手法・時点に依存し、全provider・全versionで同一の抽出可能性を証明しない。 - PCFI/PhishNChips等の研究結果は評価設定依存であり、本番環境の普遍的防御率ではない。 - provider内部policyの変更が常に外部へ明示的revision signalとして公開されるとは限らない。 ## OPEN_UNKNOWN - provider/runtimeがhidden policy変更をどの粒度で外部へ通知・readback可能にするか。 - provider横断で移植可能なeffective-instruction manifestの最小共通schema。 - multilingual・長文・複数tool/RAG/memory同時競合に対する用途別の十分なtrial設計。 - evaluator independenceをどの程度要求すれば監査上十分か。 - 実運用でinstruction-contract driftが直接事故へ結び付いた独立incidentの一般化可能な証拠。 ## SAFE_WORDING 「system instructionを設定した」ことと「そのinstructionが実行時に常に強制された」ことを同一視しない。監査可能なのは、組織が管理するinstruction revision、観測可能なprovider/model/runtime/configuration、明示したcomposition、指定した評価条件で得たbehavioral evidenceである。hidden provider instructionや未観測の内部policyは、公開された証拠がない限りUNKNOWNとする。instruction hierarchyは重要な制御層だが、consequential actionの外部authorizationやreadbackを代替しない。 ## source / provenance locator - Google Gemini Enterprise Agent Platform — system instructions guidance（登録済みprovenance、2026-10-17再確認記録）。system instructionsのrequest-wide適用と、jailbreak/leakを完全には防げない境界。 - JustAsk, arXiv:2601.21233 — black-box system-prompt extraction study across commercial models。hidden promptを機密境界とみなす一般化へのcounterevidence。 - PCFI, arXiv:2603.18433 — role/priority-aware runtime enforcementの研究 evidence。評価条件外へ防御率を一般化しない。 - PhishNChips, arXiv:2603.25056 — prompt/model configurationとsecurity behaviorの研究 evidence。configuration-bound resultとして扱う。 - EA_REVISION_LEDGER EA-520-R1-20261013 の既存provenance/refresh記録（2026-10-17 03:45 JST）。 ## 監査観点 監査では、canonical topicがEffective Instruction Contract Envelopeから弱体化されていないこと、instruction presenceとenforcement/confidentialityを分離していること、provider固有事実と研究 evidenceを一般化していないこと、hidden policyをUNKNOWNとしていること、外部authorization等をinstructionで代替していないことを確認する。 NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.