Skip to content

PLAN — K2 MCP Authorization-Discovery Evidence (2026 Q2)

  • Current status: Active bounded trust-compiler wave after K1-A; K2-A Phase 1 is now public in v3.5.0 as the first bounded MCP authorization-discovery slice.
  • Date: 2026-03-29
  • Owner: Evidence / Product
  • Inputs: ROADMAP, RFC-005, PLAN — K1, K1-A — Phase 1 formal freeze, Trust Compiler Audit Matrix, MCP Authorization
  • Scope (this document): Record the formal K2 wave choice, its guardrails, and the current K2-A Phase 1 public release status. No pack semantics, no engine bump, and no Trust Basis / Trust Card expansion are implied by this plan.

1. Why this plan exists

K1-A gave Assay its first bounded A2A handoff / delegation-route seam. The next product move for traction should not be "more internal engine" or "another pack by default"; it should be the next enterprise-relevant protocol surface that still needs first-class evidence before any claim productization.

That next surface is:

  • K2 — MCP authorization-discovery evidence

K2 continues the same product discipline as K1:

  • evidence-first
  • CI-native
  • one bounded seam
  • no pack in the same slice
  • no trust-score or correctness theater

2. Goal (one sentence)

Add a first-class, bounded canonical evidence seam for MCP authorization-discovery visibility, grounded in supported MCP authorization flows and kept strictly below correctness, authorization-success, or trust claims.

3. Why K2 now

3.1 Why this is the strongest next enterprise wedge

After K1-A, the sharpest next gap is not broader A2A semantics; it is authorization-discovery visibility on the MCP side:

  • where did the server expose authorization-discovery metadata?
  • was a protected-resource metadata document visible?
  • were authorization_servers visible?
  • did the flow expose an explicit scope challenge?

Those questions matter for CI-native governance and auditability, but they are still evidence questions first.

This is also the stronger next enterprise wedge because MCP's current direction explicitly emphasizes enterprise-managed auth, discovery, and audit/observability surfaces more than general "more MCP features" productization.

3.2 Why this is not a pack-first move

Even though MCP authorization-discovery is strategically important, Assay should not jump straight to a pack or a stronger claim. A pack is only honest after the underlying seam is real and bounded in canonical evidence.

3.3 Why this is not “more G3”

G3 made authorization context visible on supported assay.tool.decision evidence. K2 is a different surface:

  • G3: what auth context was visible on a decision path
  • K2: what authorization-discovery surface the MCP server advertised or exposed

That distinction must stay explicit; K2 must not silently reuse G3 semantics.

4. Product framing

In scope

  • one bounded MCP authorization-discovery seam
  • evidence emitted from supported MCP discovery / authorization flows
  • visibility of protected-resource metadata and authorization-server discovery surfaces
  • CI-native evidence and policy-review outputs
  • exact negatives for blob-like, config-only, or secret-bearing inputs

Out of scope

  • any new pack in the K2 wave
  • any engine bump
  • token validation, auth success, scope correctness, or issuer trust
  • claims that a server is compliant, secure, or enterprise-ready
  • reusing G3 authorization context as if it were discovery evidence
  • static config files, documentation hints, or client-side remembered auth metadata as evidence
  • OIDC discovery, client registration, or broader OAuth AS metadata expansion beyond the frozen v1 sources
  • Trust Basis or Trust Card expansion in the same slice
  • broad OTel/OpenInference schema work in the same slice

5. Hard language contract

K2 may only claim that authorization-discovery information is visible, advertised, or observed in bounded evidence.

K2 must not imply:

  • the server is correctly secured
  • the authorization server is trusted
  • the configured flow is valid
  • the required scopes were sufficient
  • any advertised scope requirement was adequate, correct, or enforced
  • a request was authorized successfully
  • the server is compliant with the full MCP auth model

6. Working v1 seam hypothesis

The likely outcome is one small typed subobject or equivalent bounded field set in canonical MCP evidence. Exact field names are not frozen in this PLAN.

This PLAN only freezes the shape discipline:

  • one seam
  • one meaning
  • typed beats blob
  • observed discovery beats auth-success claims
  • only explicitly frozen, runtime-observed MCP discovery sources may be promoted

Illustrative questions the seam may answer later:

  • was protected-resource metadata visible at all?
  • were authorization_servers visible?
  • did the discovery source come from a WWW-Authenticate challenge, a well-known URI, or another explicitly frozen runtime-observed MCP discovery source?
  • was a bounded scope challenge visible?

These examples are illustrative discovery directions, not provisional field commitments.

7. K2-A freeze-prep requirements

Before any implementation PR, K2 must produce a freeze-ready discovery record that answers:

  1. Which supported MCP code paths can actually observe authorization-discovery surfaces today?
  2. Which sources are typed and stable enough for canonical promotion?
  3. Which signals are only honest as visibility flags and not stronger claims?
  4. What is the smallest honest seam?
  5. Which inputs must not become typed authorization-discovery evidence?

Discovery answers must be grounded in shipped adapter/server/proxy evidence paths and repo reality, not solely in standards text or static configuration examples.

Minimum artifacts required before freeze:

  • per-source mapping table
  • precedence rules when multiple discovery sources exist
  • representative emitted JSON example
  • explicit negative matrix for false positives and secret-bearing inputs
  • hard may / must-not-imply language

That prep path is recorded in K2-A — Phase 1 freeze prep, and the resulting active contract now lives in K2-A — Phase 1 formal freeze.

8. Implementation gates (future, not this PR)

Any future K2 implementation slice should hard-fail review if it:

  • turns discovery visibility into authorization correctness
  • promotes static config, docs, or client-remembered auth metadata as runtime-observed evidence
  • treats visible scope or metadata as evidence of adequacy, correctness, or compliance
  • promotes raw tokens, bearer headers, or other secrets into evidence
  • silently reuses G3 auth-context fields for discovery semantics
  • silently reuses G3 or payload.discovery semantics for a distinct authorization-discovery seam
  • sneaks in a pack, engine bump, or Trust Card expansion in the same wave
  • widens the seam beyond one bounded authorization-discovery surface

9. Acceptance for K2-A

K2-A should only count as shipped if all of the following hold:

  1. Canonical emitted MCP evidence gains one bounded authorization-discovery seam.
  2. The seam is documented with exact source paths and bounded meaning.
  3. Tests show the seam is not promoted from loose, static, or secret-bearing inputs.
  4. Product language stays at visible / advertised / observed, not valid / compliant / trusted.
  5. No pack or broader trust artifact is shipped in the same wave.

K2-A Phase 1 now meets that bar through the bounded MCP import seam merged in #1004, and that slice is now part of the public v3.5.0 release line. That release status does not by itself authorize an automatic second K2 slice.

10. What happens after K2

Only after K2 evidence is real should maintainers revisit whether:

  • an MCP authorization-discovery pack is honest
  • any Trust Basis / Trust Card expansion is justified
  • an OTel/OpenInference export mapping should be widened for this seam

No downstream pack or trust-surface follow-up should be assumed as part of K2 closure.

References