MCP実践辞典 — Model Context Protocolを「共通コネクタ」ではなく、server/client/host、transport、authorization、tool capability、server trust、supply chain、auditを分離した企業運用契約として整理する

台帳EA-005はMCPサーバー、クライアント、認証、権限、監査、ツール公開、安全境界を独立テーマ化する構想である。2026-07-28仕様でMCPはstateless coreへ大きく変更され、旧HTTP+SSE/session前提の解説はそのまま現行運用へ使えない。またprotocol-level OAuthが存在しても、tool descriptionの信頼、server/package provenance、downstream API authorization、human approval、runtime sandbox、audit completenessまでは自動的に解決しない。公開後版ではprotocol mechanicsとenterprise control planeを分離した実践辞典が必要である。

Enterprise AI Core: tool/action boundary、least privilege、identity/authorization、audit、supply-chain trust、failure isolation。 Interoperability: MCP 2026-07-28 core、stdio / Streamable HTTP、OAuth/OIDC、EMA extension。 Implementation: official SDKs、Inspector、registry、host/client/server implementation。 Governance: approved-server catalog、tool allowlist、change control、human approval、telemetry。 Security: prompt/tool poisoning、token misuse、confused deputy、command injection、shadow servers、context oversharing。

Q1. MCP準拠は安全なtool利用を意味するか、それともtransport/interoperabilityとtrust/authorization/action policyを分離すべきか。 Q2. 2026-07-28仕様で旧MCP運用知の何が陳腐化したか。 Q3. OAuth対応だけでleast privilegeとdownstream API権限分離は成立するか。 Q4. tool metadata/schema/annotationを、実行権限や安全保証として信用してよいか。 Q5. enterprise deploymentではserver discovery/registry、package provenance、tool inventory、change detection、human approval、auditをどこまで別controlとして持つべきか。

• source class: official specification release exact title: The 2026-07-28 Specification org: Model Context Protocol project; authors David Soria Parra / Den Delimarsky canonical URL: https://blog.modelcontextprotocol.io/posts/2026-07-28/ publication/access: 2026-07-28 / accessed 2026-09-11 version: MCP 2026-07-28 locator: stateless core; MRTR; header routing; cacheable lists; authorization; extensions; deprecations label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support / temporal boundary established: 2026-07-28はprotocol coreをstateless request/responseへ変更し、各requestをself-describing化、Mcp-Method/Mcp-Name header、MRTR、authorization hardening、extension framework、12か月以上のdeprecation windowを導入した。旧session/bidirectional-stream前提をcurrent baselineにしない。

• source class: official architecture/transport specification exact titles: Architecture; Streamable HTTP org: Model Context Protocol project canonical URLs: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/architecture/index.mdx ; https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/basic/transports/streamable-http.mdx publication/access: MCP 2026-07-28 / accessed 2026-09-11 version: 2026-07-28 locator: host/client/server architecture; standard transports; backwards compatibility label: VERIFIED_SPEC relation: support / migration limit established: hostは複数clientを持ちserverへ接続する。標準transportはstdioとStreamable HTTP。2026-07-28 Streamable HTTPはGET streamとprotocol-level sessionsを除去し、request-scoped POST/SSEへ変更した。HTTP+SSEは2025-03-26以降legacyである。

• source class: official authorization specification exact title: Authorization org: Model Context Protocol project canonical URL: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/basic/authorization/index.mdx publication/access: MCP 2026-07-28 / accessed 2026-09-11 version: 2026-07-28; OAuth 2.1 draft-13, RFC6750/8414/8707/9728/9207等を参照 locator: Purpose and Scope; Roles; discovery; scope minimization; resource parameter; token handling; step-up authorization label: VERIFIED_SPEC relation: support / boundary established: authorizationはHTTP transportでOPTIONAL。HTTPで採用する場合、MCP serverはOAuth protected resourceとして振る舞い、Protected Resource Metadata、authorization-server discovery、resource indicator、audience-bound token validationを使う。stdioではこのauthorization specを使わずenvironment credentialを用いる。scopeはoperationに応じstep-up可能。

• source class: official authorization security specification/best practices exact titles: Security Considerations; Security Best Practices org: Model Context Protocol project canonical URLs: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/basic/authorization/security-considerations.mdx ; https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/docs/2026-07-28/tutorials/security/security_best_practices.mdx publication/access: 2026-07-28 / accessed 2026-09-11 version: 2026-07-28 locator: token audience binding; PKCE; token theft; mix-up; token passthrough; confused deputy label: VERIFIED_SPEC relation: support / security limit established: MCP clientはresource parameterを用い、serverは自分向けtokenだけを受け入れなければならない。clientから受けたtokenをdownstream APIへそのまま渡すtoken passthroughは禁止され、upstream API用tokenは別authorization contextで取得する必要がある。PKCE、issuer validation、secure token storage等も要求される。

• source class: official tool specification exact title: Tools org: Model Context Protocol project canonical URL: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx publication/access: MCP 2026-07-28 / accessed 2026-09-11 version: 2026-07-28 locator: User Interaction Model; Capabilities; Tool Names; annotations; schemas label: VERIFIED_SPEC relation: support / counter / trust boundary established: toolsはmodel-controlledで自動発見・呼出し可能だがprotocolはUI/approval方式を強制しない。仕様はhuman-in-the-loopでdeny可能にすること、tool exposure/invocationを明示するUIを推奨する。tool annotationsはtrusted server由来でない限りMUST be considered untrusted。tools/listはauthorizationに応じ異なるtool集合を返し得る。異なるserverをaggregateするとtool name collisionも起こり得る。

• source class: official security policy/trust model exact title: modelcontextprotocol/modelcontextprotocol Security — Intended Behaviors and Trust Model org: Model Context Protocol project canonical URL: https://github.com/modelcontextprotocol/modelcontextprotocol/security publication/access: current page; accessed 2026-09-11 version: current trust model; security advisories current 2026 locator: Trust Model; client developer responsibilities; operator/user responsibilities; vulnerability scope label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support / critical boundary established: MCP clientは接続serverを信頼する設計であり、local MCP serverは「インストールする他のsoftwareと同程度」に信用する必要がある。client developerはcapability表示・consent・tool/resource visibility・sandboxingを担い、operator/adminはserver選定・設定・access restrictionを担う。protocol準拠それ自体がserver/packageをtrustworthyにするわけではない。

• source class: official author-maintained SDK implementation exact title: modelcontextprotocol/go-sdk README / protocol docs org: Model Context Protocol project + Google collaboration canonical URL: https://github.com/modelcontextprotocol/go-sdk publication/access: current repository / accessed 2026-09-11 version: Go SDK v1.7.0+ supports MCP 2026-07-28 locator: Version Compatibility; authorization/security implementation notes label: OSS_PRACTICE + PRODUCT_VOLATILE relation: implementation / compatibility established: SDK versionとprotocol revisionは同義ではなく、v1.7.0+が2026-07-28をsupportする一方、older linesは2025-11-25等をtargetする。roots/sampling/loggingは2026-07-28でdeprecatedだがcompatibility windowでは残る。deployment inventoryにはSDK versionとnegotiated protocol versionの両方が必要。

• source class: official reference testing tool exact title: MCP Inspector org: Model Context Protocol project canonical URL: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/docs/2026-07-28/tools/inspector.mdx publication/access: 2026-07-28 docs / accessed 2026-09-11 version: Inspector current; Node 22.19+ surface locator: Web/CLI/TUI; shared transport/auth/protocol-era behavior label: OSS_PRACTICE + VERIFIED_SPEC + PRODUCT_VOLATILE relation: implementation / test profile established: InspectorはWeb/CLI/TUIでserver接続・tool/resource等を検証するreference developer toolであり、legacy/current protocol negotiationとOAuth状態を共有する。安全なpre-production conformance/probeに使えるが、business authorization policyやmalicious-server safetyを自動保証するものではない。

• source class: official extension specification exact title: Enterprise-Managed Authorization org: Model Context Protocol project canonical URL: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/extensions/auth/enterprise-managed-authorization.mdx publication/access: stable extension surface 2026 / accessed 2026-09-11 version: io.modelcontextprotocol/enterprise-managed-authorization locator: centralized IdP access control; enterprise policy label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support / enterprise availability established: EMAは各userが各serverで個別authorizationするだけのモデルを拡張し、organization IdPを用いた中央access policyを提供する。core authorizationとは独立versionのoptional additive extensionであり、client/server実装supportを別確認する必要がある。

• source class: independent security research exact title: Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning org/authors: Charoes Huang et al. canonical URL: https://arxiv.org/abs/2603.22489 ; peer-reviewed version DOI 10.3390/jcp6030084 publication/access: 2026-03-23 arXiv; 2026-05-05 journal / accessed 2026-09-11 version: study of seven major MCP clients locator: abstract; STRIDE/DREAD threat modeling; tool poisoning empirical comparison label: RESEARCH relation: counter / failure envelope established: client-side tool poisoningを主要riskとして分析し、複数clientでstatic validationやparameter visibilityが不十分なケースを報告する。protocol/tool schemaが存在することと、hostがmalicious metadataを安全に扱えることは同義でない。

• source class: security community framework exact title: OWASP MCP Top 10 v0.1 / 2025 categories org: OWASP Foundation canonical URL: https://owasp.org/www-project-mcp-top-10/ publication/access: beta status current 2026-09 / accessed 2026-09-11 version: v0.1 beta; next release planned Oct 2026 locator: MCP01–MCP10; roadmap label: SOURCE_REPORT + PRODUCT_VOLATILE relation: context / risk taxonomy / limit established: current beta taxonomyはtoken/secret exposure、scope creep、tool poisoning、supply-chain tampering、command injection、intent/prompt subversion、weak auth、audit gaps、shadow MCP servers、context oversharingを別riskとして扱う。 limit: OWASP MCP Top 10は現在beta/community frameworkであり、normative MCP specificationや正式standardとして扱わない。

• source class: OWASP implementation guidance exact titles: A Practical Guide for Secure MCP Server Development; Practical Guide for Securely Using Third-Party MCP Servers 1.0 org: OWASP GenAI Security Project canonical URLs: https://genai.owasp.org/resource/a-practical-guide-for-secure-mcp-server-development/ ; https://genai.owasp.org/resource/cheatsheet-a-practical-guide-for-securely-using-third-party-mcp-servers-1-0/ publication/access: 2026-02-16 / 2025-11-04; accessed 2026-09-11 label: SOURCE_REPORT relation: implementation guidance / defense-in-depth established: server側はstrong auth、strict validation、session isolation/hardened deployment、third-party server利用側はserver discovery、sandboxing、least privilege、human oversight等を多層controlとして推奨する。

• source class: official registry implementation + issue evidence exact titles: modelcontextprotocol/registry README; Registry accepts server.json with empty repository despite schema org: Model Context Protocol project canonical URLs: https://github.com/modelcontextprotocol/registry ; https://github.com/modelcontextprotocol/registry/issues/1546 publication/access: registry preview/API freeze history; issue reproduced 2026-08-19 / accessed 2026-09-11 version: registry v0.1 preview lineage locator: development status; issue #1546 live reproduction label: OSS_PRACTICE + SOURCE_REPORT + PRODUCT_VOLATILE relation: support / counter / supply-chain limit established: official Registryはserver discovery/publishingのmetadata layerとして実在するが、preview lineageであり、2026-08にはschema-required repository metadataを欠くentryがlive APIで受理されたissueが報告されている。registry掲載をsecurity approval/provenance guaranteeとみなさず、組織内allowlist・artifact verificationを別controlにする必要がある。

EA-005は高い採用価値があり、実践辞典は「MCPを使うか否か」ではなく次の七層に分けると安全である。 A. Protocol/version plane: negotiated MCP revision、SDK version、deprecated features、transport。2026-07-28を現行baselineとし旧session/HTTP+SSE知識をversion付けする。 B. Server trust/supply-chain plane: server owner、source repository、package/image provenance、release/hash/signature、registry source、approved catalog。protocol conformanceとtrustを分離する。 C. Identity/authorization plane: user/workload identity、MCP resource token、scope、resource/audience、step-up auth、downstream API token。token passthroughは禁止。 D. Capability/tool plane: tools/resources/prompts、input/output schema、read/write/destructive/open-world性、dynamic tool list、tool-name collision。annotationはsecurity enforcementではなくuntrusted metadataとして扱う。 E. Decision/approval plane: modelがtoolを選ぶことと、policyが許可することと、人間が承認することを三分離する。high-impact actionはmodel decisionだけで実行しない。 F. Runtime/isolation plane: stdio subprocess/local filesystem/env credential、remote HTTP endpoint、network egress、sandbox、resource limit、secret store。local serverは単なるdata connectorではなくlocal software execution boundaryである。 G. Audit/change-control plane: server/version、tool catalog hash/diff、auth subject/scope、tool call、argumentsの機密mask、result/error、approval actor、side effect、downstream target、policy decision、latencyを相関可能にする。

最重要境界は「MCPはinteroperability protocolであって、server・toolの安全性証明ではない」である。OAuthが正しくてもmalicious trusted server、poisoned tool description、過大scope、unsafe command construction、untrusted package、missing auditは別問題として残る。また2026-07-28ではstateless化によりgateway/routing/scale設計は改善されるが、per-request identity/capability/policy enforcementを省略してよい意味ではない。

• MCP準拠やofficial Registry掲載をsecurity certificationとして扱わない。
• OAuth/OIDC導入をleast privilege完了とみなさない。scope設計、resource/audience validation、downstream token分離、operation-level authorizationが必要。
• tool annotationのreadOnly/destructive等はtrusted server由来でない限り信用しない。side-effect controlはserver実装・policy・approvalで検証する。
• modelが「安全そう」と判断したtool callをauthorization decisionにしない。prompt/tool poisoningでsemantic decisionが操作され得る。
• local stdio serverはnetwork authがないから安全なのではない。起動package/commandにlocal process相当の権限を与えるため、provenance・sandbox・env secret・filesystem/network scopeが重要。
• remote serverはHTTPS/OAuthだけで安全とは限らない。server自身とdownstream APIが別trust boundary。
• dynamic tools/list変更、server update、registry metadata driftによりapproval後のcapabilityが変わり得る。tool catalog/versionを継続観測する。
• 2026-07-28移行中はclient/SDKごとのprotocol supportが揃わない。deprecated featureが互換目的で残る期間を「current recommended design」と混同しない。
• OWASP MCP Top 10はbetaでありrisk taxonomyとして有用だがnormative standardではない。
• tool-poisoning研究は特定client/version/configの結果であり全MCP clientへ一般化しない。

Protocol: client/server双方の2026-07-28 support、SDK version、transport、extension negotiation。 Remote auth: HTTPS、Protected Resource Metadata、authorization server metadata、client registration method、PKCE、resource/audience support、requested scope、IdP policy。 EMA: organization IdP、EMA-capable client/server/authorization server、enterprise policy/configuration。 Tool access: user/workload scope、tools/list filtering、server-side authorization、downstream API permission、organization allowlist。 Local server: executable/package availability、OS/runtime、filesystem/network/env permission、secret injection、sandbox/container policy。 Registry/discovery: registry/version/source、package registry availability、organization approval; public listing alone is not approval。

MCP core 2026-07-28: released current protocol revision as of this RUN。 Official Tier-1 SDKs: current release lines differ; Go SDK v1.7.0+ evidence supports 2026-07-28。SDK/protocol compatibility must be recorded per implementation。 Inspector: maintained reference test/debug tooling with modern/legacy negotiation。 EMA: stable extension specification exists; actual client/server support is product/implementation-specific and PRODUCT_VOLATILE。 Registry: operational public discovery infrastructure, but preview/v0.1 lineage and current data-quality issues mean it is not a security trust anchor by itself。 Enterprise policy gateway/central audit: not guaranteed by core MCP; host/provider/product or organization must implement it。

MCP評価を「接続できた」で終えない。最低profileは (1) protocol conformance/version negotiation, (2) auth audience/scope negative tests, (3) unauthorized tool absence/denial, (4) read-only vs side-effect behavior, (5) tool catalog drift, (6) malformed/poisoned description handling, (7) downstream token separation, (8) timeout/retry/idempotency, (9) audit completeness/correlation, (10) sandbox/egress boundary とする。 Inspector/conformance testはprotocol behavior確認用。semantic security、business authorization、supply-chain trustは別testを要求する。

Security: server/package provenance、token audience、least scope、downstream credential separation、tool schema validation、policy enforcement、human approval、sandbox/egress controlを多層化。 Privacy: tool arguments/results/resource dataはmodel context・host logs・server logs・downstream APIへ別々に移動し得る。MCP接続という一語でretention/training/data residencyを表現しない。 Audit: protocol loggingだけでなくidentity→authorization→model/tool selection→approval→side effect→downstream resourceまでcorrelation IDで追跡する。secret/PIIはmasking policyを持つ。 Cost: MCP自体のprotocol costではなく、host model tokens、tool API billing、server compute、gateway/observability、human approval、failure/retry costをend-to-endで計測する。 Operability: protocol/SDK/server/tool catalogをversion inventory化し、upgrade時にcontract testとpermission regressionを行う。public Registryはdiscovery、organization catalogはapprovalという役割分離が安全。

「MCPは、AIアプリケーションと外部のデータやツールを共通形式で接続するためのprotocolであり、接続先やツールの安全性を自動的に保証する仕組みではない。2026-07-28仕様ではstateless化とOAuthのhardeningが進み、HTTP接続ではresource-bound tokenや段階的scope取得を扱える。しかし、どのMCP serverを信用するか、どのtoolをmodelへ見せるか、実行をpolicyや人間が許可するか、downstream APIへどの権限で接続するか、local processをどこまでsandboxするか、何を監査するかは別の運用判断である。MCP導入ではprotocol version、server provenance、identity、scope、tool capability、approval、runtime isolation、auditを分けて設計する。」

• EA-005は七層（protocol/version, server trust/supply chain, identity/auth, capability/tool, decision/approval, runtime/isolation, audit/change control）を章骨格候補にする。
• 公開直前にlatest MCP spec revision、Tier-1 SDK compatibility、deprecated feature status、EMA/other auth extensions、Registry GA/versionを再採集する。
• EA-157 MCP protocol項とは編集境界を分ける。EA-157はnormative protocol仕様、EA-005はenterprise deployment/runbook・安全境界・監査を主とする。
• EA-162 OAuth/OIDC × Agentへauthorization detailsをcross-referenceし、EA-005ではresource/audience/PKCE/step-up/token passthrough禁止の運用要点を残す。
• EA-317 Tool Capability Contractへtool schema/side-effect/read-only/idempotency/approval contractを接続する。annotationをsecurity truth sourceにはしない。
• EA-054/055へworkload identity/multi-agent delegation、EA-021/036へpermission-aware data access、EA-063/159へMCP gateway、EA-007/160へconnector/OpenAPI comparisonを接続する。
• public Registryとorganization-approved catalogを別物として設計する。server entryにowner/repository/package/image/version/hash/signature/license/last review/tool catalog hash/risk classを持つ案を検討する。
• TEST_PROFILE（未実施）: official Inspector/conformance harnessで2026-07-28 negotiation・tools/list/call・auth failureを安全なsample serverで確認。さらにsynthetic read/write toolsを用い、scope不足、tool list filtering、description poisoning、tool-name collision、catalog change、timeout/retry、audit correlationを検証する。外部tenant・課金・秘密情報は使用しない。
• security evidenceはOWASP beta taxonomyだけで閉じず、MCP official security requirements、SDK advisories、peer-reviewed/primary attack research、実装incidentをclaim-levelで並べる。
• 2026-07-28 migration guideを追加採集し、2025-11-25/2025-06-18 clientとの互換条件を具体的に表へ落とす。

/ STOP_CONDITION

• TypeScript/Python/C#/Java/Rust等各official SDKの2026-07-28完全support versionと未実装差分のcurrent matrix。
• EMAの主要enterprise hosts/servers/IdPでの実運用採用率とconfiguration evidence。
• public MCP Registryの2026-09-11時点の正式GA判定、artifact verification/signature/provenance semanticsの完全仕様。
• 主要MCP hostsがtool descriptions/annotations変更をどのように表示・再承認するかのcross-product matrix。
• tool poisoningに対する各current hostのstatic/runtime defenseとversion別独立再現。
• audit event schemaのprovider横断標準化状況。core MCP自体がenterprise audit completenessを保証する範囲。
• local stdio serverのsandbox/default egress/filesystem isolationが主要clientごとにどう異なるか。
• x-mcp-header等2026-07-28 tool-routing機能のproduction gateway採用とsecret leakage対策実測。

EA-005の更新章に必要な現行protocol revision、旧仕様との差、authorization/token境界、tool metadataの非信頼性、server/supply-chain trust、local/remote runtime差、registry限界、独立tool-poisoning evidence、enterprise運用七層まで確立した。各SDK/host全製品matrixをここで固定するとPRODUCT_VOLATILEかつEA-157/162/317と重複するためbounded closeする。次の未調査最小番号はEA-006「Agent-to-Agent／マルチエージェント編」。 。

This candidate advances the existing refresh revision EA-005-R1-20261004. It does not create a second independent base candidate. The rescued base lineage EA-005-V21-LEGACY-MIGRATION-20261011-R1 remains historical provenance and converges into this active refresh.

• The MCP 2026-07-28 specification remains the current FINAL revision in the official conformance matrix as of 2026-10-11; the next listed revision is not ready.
• The TypeScript SDK v2 is now the stable line implementing the 2026-07-28 spec. Its documentation explicitly separates the modern 2026-07-28 era from legacy 2025-era protocol behavior.
• TypeScript v1 remains a maintenance line and does not implement the 2026-07-28 revision; therefore SDK package major version and negotiated protocol revision must be recorded separately.
• The Python SDK v2 is likewise the stable line for the 2026-07-28 revision.
• The 2026-07-28 TypeScript migration documentation makes support an explicit opt-in/compatibility concern rather than something inferred from package presence.
• The official conformance matrix still shows implementation differences by SDK and SEP. “Official SDK” therefore does not imply complete parity across every feature.
• None of this changes the canonical enterprise boundary: protocol interoperability, server/package trust, authorization, downstream API permission, human/policy approval, runtime isolation, supply-chain provenance, and audit completeness remain distinct controls.

• https://plan.modelcontextprotocol.io/conformance — official conformance matrix; 2026-07-28 FINAL.
• https://ts.sdk.modelcontextprotocol.io/v2/ — TypeScript SDK v2 stable line for 2026-07-28.
• https://ts.sdk.modelcontextprotocol.io/v2/protocol-versions — modern/legacy protocol-era separation.
• https://ts.sdk.modelcontextprotocol.io/v2/migration/support-2026-07-28 — explicit 2026-07-28 support/migration behavior.
• https://py.sdk.modelcontextprotocol.io/whats-new/ — Python SDK v2 and 2026-07-28 protocol move.
• https://github.com/modelcontextprotocol/typescript-sdk/releases — TypeScript SDK current release history.

• MCP compliance, official SDK use, or public Registry listing is not a security certification.
• OAuth support does not by itself establish least privilege or safe downstream authorization.
• Tool annotations and descriptions are not security truth when server trust is not established.
• SDK support is version- and feature-specific; cross-SDK parity must not be assumed.
• Host behavior, tool-change reapproval, local sandbox defaults, and organization-specific controls remain product/runtime specific.
• No live tenant, paid API, secret-bearing environment, destructive tool, or production host was exercised in this rescue.

MCP is an interoperability protocol and an implementation ecosystem, not a complete enterprise trust boundary. Record the protocol revision and SDK version separately, and design server provenance, identity and scope, tool capability, approval, downstream authorization, runtime isolation, and audit as separate controls.

• current product-by-product support for EMA and other optional extensions;
• cross-host behavior for changed tool descriptions/annotations and reapproval;
• public Registry provenance/signature semantics and enterprise approval mapping;
• host-specific sandbox/default egress/filesystem behavior for local servers;
• cross-product audit schema completeness.

PASS_FOR_EXISTING_REFRESH_REVISION. The 2026-10-04 refresh already recorded RESEARCH_GATE_PASS; 2026-10-11 currentness confirms the core protocol/SDK boundary and adds no contradiction requiring full re-research.

• target: content/staging/EA-005.md
• base repository commit: 97d3d104ae0b16a95e7dffddc3a8cb327795a796
• path precondition: ABSENT
• revision: EA-005-R1-20261004
• candidate: V21-CANDIDATE-EA005-REFRESH-20261011-C1
• READY: NOT_CREATED
• AUDIT_PASS: NOT_CLAIMED
• GIT_WRITE: NOT_PERFORMED