Amend the sensitivity model: source labelling is sound for hierarchies, unsound for opaque containers

[KenTaniguchi-R]

An amendment to the sensitivity/clearance design, from research on 2026-08-06. The model is largely right; three claims in it are not, and one of them was mine.

Verified against main @ 6dbf1c6.

1. Source labelling does not generalize past hierarchies

The design labels sources. FIDES, which it cites, labels content:

Trust and confidentiality become labels on content, propagated by middleware, checked deterministically before each tool call.

For a filesystem these coincide — a path is a usable proxy, and classifyPath's longest-prefix-wins gives real granularity via carve-outs. For an opaque endpoint they come apart completely: one label, heterogeneous contents, no structure to carve on. Either the label is false (internal when a secret is inside) or the source is useless (secret).

This is not our limitation. Authorization-First Retrieval (TrustNLP 2026) names it as unsolved:

mixed-content chunks (public and restricted material colocated in one indexable unit) cannot be tagged correctly under a single-label scheme regardless of process maturity

with retrieve-then-filter exposing unauthorized context in 86.1% of queries, and metadata-tag pre-filtering leaking 9.7% after a single policy-update cycle — "staleness is not an edge case. It is the steady state."

But whole-source labelling is still the right answer, for a reason worth writing into the spec. github/github-mcp-server hit this exact case and rejected per-item labels (pkg/ifc/ifc.go):

a tool result is delivered as one opaque payload… Once the items share a buffer in the agent's context they can be copied anywhere together, so the only sound bound for the whole result is the meet of every item's label. Per-item labels would only become load-bearing if the enforcement engine could partition a result and route individual items to different sinks.

Ours cannot — everything lands in one context window. Even Azure AI Search, the one system doing per-reference sensitivity labels, also returns a response-level "most restrictive across all references" and enforces on that.

So: keep whole-source labelling, and record that it is the converged answer rather than a shortcut. Then state plainly that an opaque container labelled below its most sensitive item is a false guarantee.

2. The three-level total order is a known-insufficient shape

public < internal < secret forces over-classification the moment something is sensitive to one audience and not another. Both prior designs that tried it moved away:

• The MCP extensions draft killed sensitiveHint: low|medium|high because "sensitivity is set-theoretic (a card number and a medical record are both sensitive but to different readers), not a single scale."
• Oracle Label Security is LEVEL : COMPARTMENTS : GROUPS, where dominance needs level ≥ and compartments ⊇ and group intersection — with non-comparable labels as a first-class outcome.

Not urgent, and adding compartments now would be premature. But the spec should stop presenting three levels as sufficient and record the known ceiling.

3. I proposed two fixes that the evidence rejects

Both are recorded here so they are not re-proposed:

Enumerate MCP servers at setup and ask once. This is per-tool allowlisting with a nicer UI, and the research note already rejected it: "Naming safe MCP servers does not converge. mcp: [openmemory] is exactly as dangerous as whatever is in that owner's openmemory." Renaming the entry to a label does not add granularity.

Add a call-time approval path (FIDES approval_on_violation). The evidence is strongly against it:

• Anthropic's own telemetry: 93% approval rate on Claude Code permission prompts. Vista UAC 89–91%. Chrome SSL warnings 70%, half dismissed under 1.7s.
• Microsoft's own FIDES docs recommend approval_on_violation=True for "interactive UX, dev/test" and hard block for "production, low-trust environment."
• The dialog is itself an attack surface — "Lies-in-the-Loop" pads it so the dangerous part scrolls off.
• FIDES's approval path shipped a replay bug (a granted call_id in a set never cleared).
• "Oversight Has a Capacity" models realized safety as an inverted-U in escalation rate: escalating everything is strictly worse than escalating a middle amount.
• As of Aug 2026, no mainstream agent product ships async approval for tool permissions — everyone blocks or removes the human.

What to build instead

From the same research, in order:

1. Push denials out-of-band as information, not a decision. "Ken's agent asked X at 3am; policy said no." No approve button. Gives the owner the feedback loop they currently lack — today denials are logged locally and never surface — without a prompt to rubber-stamp.
2. Time-boxed clearance grants. SpiceDB ships [expiration:...] as a first-class relationship primitive, clock-enforced server-side; they moved off caveat-based expiry because it required clients to supply now and did not garbage collect.
3. Learned narrowing from the denial log. Wijesekera et al. (IEEE S&P 2017): predicting the user's own decision from their history reaches 96.8% accuracy, ~4x error reduction over ask-on-first-use, in a deployed 38-person field study.
4. Answer-partially-then-defer rather than block — the caller gets what clearance permits now. Closer to Constrained-output tasks: declassification by capacity #387 than to approval.

_meta.ifc: real code, no spec — parse opportunistically, do not build on

• Not in the MCP spec. Every revision through 2026-07-28 and current draft has only the four original tool hints. Zero merged SEPs. SEP-1913 was split to an Extensions Track in June 2026; sponsor unresponsive since, bot nagging through 2026-08-03.
• But github/github-mcp-server emits labels today, behind an opt-in ifc_labels flag, and microsoft/agent-framework consumes them (Python, @experimental).
• Three incompatible wire formats already exist: _meta.ifc, _meta["com.github.ifc/labels"], _meta["io.modelcontextprotocol/trust-annotations"].

Treat a present label as an opportunistic upgrade and absence as maximum sensitivity. Do not make the guarantee depend on it.

And do not auto-classify

REDACT (arXiv 2606.19881, Jun 2026) puts rule-based Presidio at 0.07 recall on HIGH-sensitivity categories — 93% false negatives. The structural argument matters more than the number: fail-closed auto-classification is sound exactly to the degree it is not classifying. If unlabelled means secret, a classifier can only ever downgrade, and every downgrade is an unproven declassification. Classic IFC (Denning, Myers/Liskov DLM, Jif) and every modern agent IFC system assign labels by provenance, never by inferring from content.

Gated on

Nothing technical. This is a spec amendment plus three decisions: the opaque-container position, whether to add compartments later, and which of the four "build instead" items is first. #392 (wiring) and #393 (the git-repo default) are the concrete work this frames.

Sourcing caveat

The MCP findings are traceable to primary sources (spec schemas, ifc.go, SEP threads) and were verified directly. One research agent in this batch fabricated a claim about having received sub-agent results and self-corrected; its remaining findings were separately confirmed, but anything from that batch should be re-checked before it becomes normative text.

Related

• The owner's skills and MCP servers are still unreachable — #372 wired only the path half #392 · setup labels the enclosing git repo internal — measurably the wrong default #393 · Constrained-output tasks: declassification by capacity #387 · Clearance has no equivalent of the menu's task-existence hiding #383 · A Codex line enforces none of the sensitivity model — should it be callable? #391 · Nothing scans what the agent sends back — ggshield plugs into the hook seam we already own, but it is fail-open where our guard is fail-closed #173 · decision: replace the capability envelope with sensitivity labels and caller clearance #372

[KenTaniguchi-R]

Re-verified 2026-08-06 — the sourcing caveat was warranted. Two errors, three softenings, one re-attribution. The core argument holds.

Every factual claim in this issue was checked against the source that owns it, adversarially: no claim was repaired by substituting a different source that says something similar. Full table: docs/research/2026-08-06-ifc-claims-reverification.md.

Confirmed as written — claims 1 (all parts), 2 (all parts), 5, 6a, 6b, 6c, 7, 8, 9, 10, 11a, 11b, 12, 13, 14, 15. The DOI resolves, the ifc.go passage is a verbatim source comment, and the 93% figure this issue flagged as most likely unsourced holds at the primary source: "Claude Code users approve 93% of permission prompts."

FALSE — claim 4 is a fabricated quotation

This issue attributes to the MCP extensions draft:

"sensitivity is set-theoretic (a card number and a medical record are both sensitive but to different readers), not a single scale."

That string appears nowhere — not in experimental-ext-tool-annotations, not in SEP-1913's PR body or SEP text, not in that PR's comments, not in issue #711. Searched for "set-theoretic", "card number", "medical record", "single scale", "different readers" across all five.

The account is also wrong three ways:

1. What the draft narrowed was not sensitiveHint: low|medium|high. Verbatim from specification/draft/trust-annotations.mdx: "SEP-1913 carried a four-level data classification (public / personal / confidential / highly_confidential) plus a regulatory scope… This extension deliberately keeps only the coarse sensitive boolean on the wire." The low|medium|high form appears only in SEP-1913's PR description, which is stale relative to the SEP text it points at.
2. It was demoted, not killed — servers SHOULD emit both the coarse boolean and a richer evidenceRef scheme; "The two are layered, not alternatives."
3. The stated rationale is universality, not set-theory — the boolean is the "lowest-common-denominator signal… Richer schemes are strictly more capable but are not universally implemented, so they cannot be the floor."

The underlying point is genuinely sourced, elsewhere. It is a reviewer comment by @JustinCappos on issue #711, arguing against linear scales in general:

One thought I had is to wonder if having levels (low medium high) or really any sort of linear scoring system like this is the best approach. For example, I want an email with medical test results to be able to be read by my mail MCP and my credit card number to be sent to a payment MCP, but I may not want either bit of detail shared with the other.

SEP-1913 answers it directly in §"Why Not Information Flow Control (IFC) Labels?" and chose categorical DataClass over a linear scale partly in response. That is the citable chain. It supports this issue's conclusion — a single scale is the wrong shape — while contradicting its account of who decided what and why.

Suggested replacement: the MCP trust-annotations extension draft narrowed SEP-1913's four-level DataClass to a single sensitive boolean on the wire, recovering richer classification through an out-of-band evidenceRef scheme; separately, review on issue #711 argued that any linear scale is the wrong shape, because a card number and a medical record are each sensitive to different readers.

FALSE — claim 11c: "38-person" should be 131-person

Wijesekera et al., arXiv 1703.02090, abstract verbatim: "We performed a longitudinal 131-person field study…" Off by ~3.5×. The 96.8% and the "four-fold reduction in error rate" both hold verbatim.

Soften

• Claim 3 (Azure). The two-level structure is real, but the doc hedges — "Typically, the most restrictive label wins" — and the aggregate is advisory: "Useful for client-side display banners and policy enforcement." Actual server-side enforcement is per-document exclusion at query time, not enforcement on the aggregate. Say "also computes and returns", not "enforces on that".
• Claim 6d (1.7s). Verbatim: "Users clicked through 49% of untrusted issuer warning impressions within 1.7s, but clicked through 50% of name and date errors within 2.2s and 2.7s." 1.7s is one of three subtypes. Either qualify it or drop the timing and keep the 70.2%.
• Claim 8 (FIDES replay bug). Fixed 2026-07-09 in microsoft/agent-framework#6966; current security.py binds approvals to the exact invocation and consumes on first use. As written it implies a live defect. The argument is better served by noting it took a dedicated hardening PR.
• Claim 10. The paper states its own limit: the inverted-U "is a direct consequence of the assumed monotonically-fatiguing reviewer — a modeling result about a plausible model, not an empirical finding about real people." This issue's phrasing is already careful; keep it careful in the spec.
• Claim 6b (Vista UAC). Microsoft's own E7 engineering blog, not academic literature. Same category as the Anthropic 93% — vendor telemetry.

Re-attribute — claim 16

Wire format	Who actually emits/consumes it
_meta["ifc"]	github/github-mcp-server — pkg/github/ifc_labels.go:11-18, r.Meta["ifc"] = label
_meta["com.github.ifc/labels"]	microsoft/fides-gateway — middleware.py:92, the gateway's canonical namespace despite the com.github. prefix
_meta["io.modelcontextprotocol/trust-annotations"]	the extension draft

This issue reads as though github-mcp-server emits the reverse-DNS form. It does not — it writes the bare ifc key. The fragmentation point gets stronger, not weaker: the FIDES gateway ships a prefix-remapping shim precisely because the ends disagree (middleware.py:364-373), which is a fourth naming in the same file.

One unsourced claim nobody had flagged

As of Aug 2026, no mainstream agent product ships async approval for tool permissions — everyone blocks or removes the human.

Not on the verification list and not sourced in the issue. A universal negative about a fast-moving product space is the weakest claim here by construction. Either source it or soften it to the products actually surveyed.

The core argument is the best-sourced thing in the issue

Whole-source labelling, kept because a tool result is one opaque payload and the only sound bound is the meet of every item's label: ifc.go's comment says it in those words, the TrustNLP paper independently names mixed-content chunks as untaggable, and Azure's two-level design is a real (if advisory) instance of the same reasoning. That section can go into the spec unchanged.

---

§2 and the open decisions — separate research

docs/research/2026-08-06-mcp-source-default-trust.md answers the "which of the four build-instead items is first" question and the opaque-container position.

No surveyed system fails closed on confidentiality for an unlabelled source. FIDES defaults unlabelled tools to PUBLIC; Azure AI Search returns unlabelled documents to everyone; Purview's default policy assigns General \ All Employees (unrestricted); Cloudflare MCP Portals expose every tool of a newly added server; the trust-annotations extension says absence is "no claim made".

That evidence does not transfer, and the reason is structural. In every one of those systems the party who receives the data is the party whose credentials fetched it. AgentCall is the only case where the credential holder (the owner) and the reader (the caller) are different people. Copying FIDES's PUBLIC default here would make every configured MCP server readable by every public-cleared caller on a fresh install. The design spec lists "the emerging MCP _meta.ifc convention" as a mitigation for labelling burden (Risks §2); it is not one, and the extension explicitly hands the default back to us.

So: keep secret, and write the reason down. The one uncomfortable inconsistency — we auto-label the git repo internal but ask for every MCP server — is defensible because setup runs inside the repository it labels, so cwd is evidence of intent, whereas a config entry is evidence only of installation. That distinction belongs in the spec, or the two defaults look arbitrary next to each other.

On which build-instead item is first: item 1, and the survey says why. Azure's "elevated read" — the one shipping system whose shape matches ours, where reader ≠ credential holder — neither denies nor trusts. It allows with a mandatory per-item out-of-band record, the record being a precondition of access. Applied here, the labelling worklist should be demand-driven: surface denials out of band, and the set of servers an owner ever labels is bounded by the questions people actually ask rather than by ~/.claude.json. Each label is then prompted by evidence rather than a wizard — the difference between a security review and a bug report. This converges where the setup wizard does not, needs no protocol dependency, and is the cheapest item on the list.

Do not: build on _meta.ifc (one flag-gated emitter, one experimental consumer, four naming variants, sponsor unresponsive); label per tool within a server (the one system that can partition a result declines to partition confidentiality); use readOnlyHint as a confidentiality signal (it is a sink annotation); or extend capacity-based declassification to secret to route around the default.

Two further corrections for §1 and §2 of this issue, from docs/research/2026-08-06-skill-and-mcp-guard-reachability.md:

• The opaque-container problem is partly ours, not the protocol's. classifyPath gets longest-prefix-wins; classifyMcp/classifySkill get one flat exact-key match each (sensitivity.ts:119). Worth separating in the amendment.
• MCP does have a URI hierarchy — on the Resources surface, which is not the surface we enforce on. Tool results are not URI-addressed, and Claude Code exposes Resources only through user @-mentions. The prefix logic has nothing to bind to.