Runtime tool drift detection — gap beyond admission-time security?

[MaazAhmed47]

Working on runtime MCP security and wanted to surface a gap for discussion.

Admission-time checks (trust roots, signed assertions, server attestation) verify a server when you connect. But they don't catch tools that change behavior AFTER admission — a read-only tool that later adds export effects, PII data classes, or escalates externality from internal to external. The server identity is unchanged, so the admission check still passes.

Is post-admission tool drift considered in-scope for the spec / Security IG, or is it expected to live in a runtime monitoring layer outside the protocol?

I've been building an open-source implementation focused on this (continuous baseline + drift detection with severity-based quarantine) and would be happy to share findings or contribute if it's relevant to the group's direction.

[MaazAhmed47]

This is the sharpest framing of the problem I've seen — thank
you. The split you're describing maps cleanly:

• Admission anchors a capability manifest (identity + declared
  scope at connection time)
• Each call carries a receipt that binds the executed tool to
  that admitted manifest
• The drift detector lives between those two points,
  implementation-specific, without blocking interop

I agree post-admission drift belongs in the runtime monitoring
layer, not the spec core — but your point about the spec
defining the hook is the key insight. Without a standardized
capability manifest at admission and a verification step at
call time, every runtime monitor reinvents the binding and
they don't interoperate.

To your open question — "what does the receipt carry that lets
a runtime monitor verify this call matched the admitted
capability?" — in my implementation the baseline captures the
full declared schema (params, types, effects, data classes,
externality) at registration. On each call I diff the live
tool definition against that baseline and score severity by
kind of change: effect escalation (read_only → mutating),
new sensitive data classes, externality crossing internal →
external, new required params. The gap I keep hitting is
exactly what you name: there's no spec-level anchor, so the
"admitted manifest" is something each implementation has to
reconstruct rather than read from a standard field.

A minimal spec hook — a signed capability manifest at admission
that the runtime can re-verify per call — would let drift
detectors, receipt verifiers (like your ATB substrate), and
policy engines all bind to the same source of truth. That feels
like the interop-preserving primitive this thread is circling.

Would be curious whether the Security IG sees appetite for
standardizing that manifest+anchor, even if drift logic itself
stays implementation-specific.