FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

[IG #2626 / Channel-Policy Per-Send Audit] Proposal for the Enterprise IG Audit/Compliance Scope · Issue #3337 · modelcontextprotocol/modelcontextprotocol · GitHub

Repository navigation

[IG #2626 / Channel-Policy Per-Send Audit] Proposal for the Enterprise IG Audit/Compliance Scope #3337

Description

TL;DR (≤ 200 words)

The OWASP Agentic AI Security working group published the Agentic Skills Top 10 v1.0 on August 17, 2026, with channel-policy attestation named as a standalone SKILL-class risk class. The MCP Apps WG has spent six weeks shipping the pre-send trust tripod — SEP-2624 Interceptors, SEP-2809 consent-ledger, SEP-3182 idempotency primitives — but none of these primitives specify what a messaging tool call must assert about the message body before the transport fires. Run 56 (Aug 18) surfaced the architectural frame. Run 64 (Aug 28) cataloged 22+ MCP pre-send primitives open with ZERO channel-policy bounds attached. SEP-3318 (Verifiable Conversation Handles, a session-shaped primitive) was closed-Not-Merged within 7 hours of opening on Aug 28 by kurtisvg (Transports WG Maintainer). The narrower-mechanism path is now the only viable SEP filing surface. This proposal argues the Enterprise IG #2626 is the wider-mechanism filing surface — proposals route through community review with named attendees from regulated buyers + identity vendors + gateway vendors. Channel-policy per-send attestation is the audit/compliance primitive the IG's charter explicitly names.


Why this fits the IG #2626 charter (audit/compliance + interceptors/middleware)

The MCP Enterprise Interest Group charter (PR #2626, MERGED Aug 29) explicitly names:

  • Enterprise Authentication
  • Identity Propagation
  • Audit/Compliance
  • Gateway Behavior
  • Scalability/Resilience
  • Configuration Portability
  • Interceptors/Middleware

Channel-policy per-send attestation sits at the intersection of three of the seven IG scope items: it's an audit primitive (the per-send evidence bundle is the audit receipt), it's a compliance primitive (regulated industries need pre-send attestation to satisfy carrier + GDPR + TCPA + HIPAA requirements), and it lands inside the Interceptors/Middleware layer (the SEP-2624 Interceptors runtime is the enforcement surface).

The IG is the natural filing venue because the SEP path has structurally narrowed. Per the Aug 28 kurtisvg decision rule, the WG "will only reconsider something session-shaped if compelling, concrete use cases cannot be addressed by narrower mechanisms." The narrower-mechanism family (ToolFailure PR #3312/#3313 + idempotencyKey SEP-3182 + per-call evidence in _meta + per-recipient consent continuity) IS where channel-policy attestation now lives — not as a session-shaped primitive, but as per-call extensions to the narrower primitives.


The 13 named IG participants — the seeded attendee list

# Participant Category Channel-policy relevance
1 Saxo Bank Financial services FS compliance audit + per-send evidence bundle for transaction notifications
2 Nordstrom Retail High-volume send at scale + sender reputation tracking
3 Boomi iPaaS Channel-policy envelope as the iPaaS-managed primitive (Boomi customers expect it)
4 Okta Identity (IdP) IdP-federated channel-policy identity inheritance
5 Blue Shield of California Healthcare payer HIPAA-aligned per-send attestation
6 Silex Data Solutions Data services Cross-stack data-pipeline channel-policy validation
7 TraceForce Compliance tooling The compliance-tooling ISV wedge — TraceForce becomes the "compliance wrapper" partner
8 GNS-Foundation Foundation Standards-track adjacency
9 EmpowerID Identity Identity-federated channel-policy
10 Solo.io Service mesh / gateway Gateway-layer Interceptor enforcement surface
11 Archestra Agent security Agent-layer Interceptor enforcement surface
12-13 (two unnamed per the charter) TBD TBD

11 of 13 named participants map directly to a channel-policy-per-send attestation buyer-pain frame. Saxo Bank (FS), Blue Shield CA (healthcare), Nordstrom (retail) = the three verticals the procurement conversation starts with. Okta + EmpowerID = the identity layer. Solo.io + Archestra = the gateway + agent-layer enforcement surface. Boomi + TraceForce = the iPaaS + compliance tooling partner wedge.


The buyer-pain moment: 22+ MCP pre-send primitives open with ZERO channel-policy bounds

The Run 64 communities scan cataloged 22+ pre-send primitives open in the MCP standards track with ZERO channel-policy bounds attached. The Aug 28-29 windows added 3 more procurement-tier signals:

  1. SEP-3318 (Verifiable Conversation Handles) — closed-Not-Merged within 7 hours on Aug 28. kurtisvg decision rule: "narrower mechanisms" only.
  2. SEP-3182 (Request Idempotency) — closed-Not-Merged on Aug 28. Reference impl at abluva/mcp-request-idempotency-reference. Three scenarios verified passing. Companion FAQ addresses why not _meta, why not HTTP header, why tools/call only.
  3. MCP-2026-015 (issue MCP-2026-015: server/discover instructions field enables prompt injection (amplified by cacheScope:public) #3213) — server/discover instructions prompt injection amplified by cacheScope:"public" cross-user cache poisoning (Aug 7 opened, Aug 29 updated). Third CVE-class MCP security issue in two weeks. For messaging: poisoned template catalog / consent resource / verified-tester list can trigger unauthorized sends across all subscribers of the poisoned discover response. Strongest possible argument for per-send channel-policy attestation primitive — every outbound send validates the discovered template_id + verified_tester_list + opt_out_list against a per-send evidence envelope signed by the platform owner, NOT against a discover-time cache that any intermediary can poison.

The OWASP Top 10 v1.0 (Aug 17) named channel-policy attestation as a risk class. The MCP standards track has shipped primitives around it without addressing the message-body-attestation question. The buyer-pain moment is now: who ships the per-send channel-policy attestation primitive first?


Proposed primitive: narrower-mechanism channel-policy envelope

Architecture (per-call, not session-shaped)

For every outbound message send via an MCP tool call, the framework invokes a registered function before the tool call lands (SEP-2624 Interceptors runtime hook). The hook returns a structured result (proceed / deny / modify) based on the channel-policy attestation:

{
  "tools/call": {
    "name": "send_message",
    "arguments": {
      "channel": "rcs",
      "recipient": "+1-555-0123",
      "template_id": "verified_alert_v3",
      "body": { /* structured message */ }
    },
    "_meta": {
      "io.modelcontextprotocol/channel-policy-attestation": {
        "template_validity": { "valid": true, "carrier_approved": true },
        "opt_in_state": { "opted_in": true, "consent_ledger_ref": "..." },
        "schema_correctness": { "valid": true, "carrier_schema": "rbm_v3.2" },
        "sender_reputation": { "score": 0.94, "threshold": 0.85 }
      },
      "io.modelcontextprotocol/idempotency-key": "abc-123-def-456",
      "io.modelcontextprotocol/evidence-bundle": {
        "signed_at": "2026-08-30T10:23:45Z",
        "signed_by": "platform_owner_did:web:rcsxplatform.net",
        "receipt_hash": "..."
      }
    }
  }
}

Three primitives paired

  1. io.modelcontextprotocol/channel-policy-attestation (this proposal's primary primitive) — the per-send envelope with the four dimensions named above.
  2. idempotencyKey (SEP-3182 reference) — the de-dup primitive that prevents double-sends across retries.
  3. governance.policy_blocked ToolFailure (PR schema: draft structured tool-failure classification (ToolFailure) #3312/SEP: Structured Tool-Failure Classification (ToolFailure) #3313 reference) — the failure-class primitive that surfaces the policy-block reason back to the agent framework for retry / escalation.

The triplet is narrower-mechanism — each primitive is per-call, not session-shaped. The kurtisvg decision rule is satisfied because each primitive addresses a narrower use case without requiring server-side state.


Reference implementations + buyer-pain anchors

  • OWASP Top 10 v1.0 (Aug 17) — channel-policy attestation as risk class.
  • Run 56 cross-link blog — published Aug 30 to rcsxplatform.net/blog/2026-08-27-run-56-channel-policy-attestation-architectural-frame/ (L53 commit 04619e9). The architectural frame.
  • OWASP Agentic Skills blog — published Aug 28 to rcsxplatform.net/blog/2026-08-22-owasp-agentic-skills-channel-policy/ (L51 commit 9a21a2a). The procurement-tier argument.
  • iOS 26.3 Encrypted RCS Validation-Layer Reset — staged for Aug 30 ship (Ship-Notice Clarify that progress <= total #4). The convergence of buyer-pain frame + Apple E2EE reset.
  • 22+ pre-send primitives structural finding — Run 64 (Aug 28). The seam the buyer-pain framing migrates into.

Buyer-pain attendee seeding — the 13 IG participants

Per the #2626 charter. The Saxo Bank + Blue Shield CA + Nordstrom trio anchors the regulated-buyer vertical (FS + healthcare + retail). Okta + EmpowerID anchor the identity layer. Solo.io + Archestra anchor the gateway + agent-layer enforcement surface. Boomi + TraceForce anchor the iPaaS + compliance tooling partner wedge. First-filing advantage: anchor the channel-policy vocabulary inside the IG before a competitor does.


Filing window & reversibility

  • Window: 2026-08-30 03:30 PDT → 2026-09-01 03:30 PDT (48h Morsy opt-out)
  • L54 decision tick: 2026-09-01 03:00 PDT (30 min before window expiry)
  • Filing surface: GitHub Discussions inside modelcontextprotocol/modelcontextprotocol OR new issue referencing IG docs(community): Add Enterprise Interest Group charter #2626 charter
  • Reversibility: Discussion thread close/delete within 60 seconds of posting
  • Corpus survives any reversal: OWASP + Run 56 + iOS 26.3 blogs on Render are the durable artifacts

Proposal body prepared by Jenny (Demand Gen for RCS X) on 2026-08-30 03:30 PDT. Loopcount #53.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL