CapShim: Validating Capability Policies for the Model Context Protocol via a Non-Interference Type System

The paper presents a very fun! and self contained little experiment in implementing a capability-based constraint system for MCP commands. This is a very nice project, and I'm curious to see how it develops! That being said, the work builds on a really rich area of information flow type systems for which similar ideas have been tried out and their various warts discovered and accounted for. In particular, following the development of the first information flow type systems, the area has investigated various extensions and refinements to make it easier and more ergonomic to use these types. One particular problem is that these policies end up being very restrictive, and often loose information too quickly. One idea that I would encourage the author to look into is that while historically these heavier more precise type systems have had typing obligations that would put off any human, they may be more than manageable for an agent. Anyway, overall, this paper is very clean, consise, self contained and fun to read, the direction is well scoped and tackles an interesting problem albeit with a small delta ontop of existing work. Looking forward to seeing how this develops!

The framing is principled and timely: treat MCP's ambient authority as a type error and enforce information-flow control at the protocol boundary. The artifact is real (a deployable proxy, four specified typing rules, real-server tests), and the limitations section is a model, naming in-LLM laundering, lying tool authors, and timing channels rather than burying them. The score rests on that engineering; validation is the soft spot. The 100% block and 0% false-positive figures use an external attack taxonomy but a self-built harness on the author's own toy server, plus ten invented benign cases, so they are not yet independent evidence; an outside agent-injection corpus would fix this. The non-interference argument, the paper's titular contribution, is an unproven sketch with its three lemmas deferred, and as stated covers only payload-bearing egress, narrower than the abstract implies. T-Declassify, the one rule that intentionally moves Secret data, is never exercised by any scenario.

This work correctly identifies a security issue underlying much of today's agentic workflows. The proposed solution is relatively simple - and this is excellent and the author resists the temptation to overcomplicate. I would not be surprised if this approach is essentially or similar to what the industry settles on in the near-to-medium term. This work has clearly been conducted by a competent ML engineer with good security mindset and thinking and I look forward to seeing more from them.

The design displayed requires no onerous refactoring of existing workflows and would be relatively simple to drop in place (modulo maintainers needing anyway to create sensible security policies). The separation of policy from tool implementations allows reusability and aids abstraction.

This work is similar conceptually to CaMeL (https://arxiv.org/abs/2503.18813) and it was a notable omission to not place the work in this context and distinguish it appropriately. Similarly the benchmark was hard to evaluate credibility of since it is small and self-authored, but provides _some_ credibility. The diagram had overflowing text which was a little messy. I was also a little concerned that the soundness sketch was not proved; I"ll also note that I don't think it actually reflects the threat model mentioned earlier (given adversaries have some control over emission of tool calls) which might mislead reviewers.

I particularly liked Appendix A and the correct identification of additional covert channels though I would add that (4) significantly underestimates the capacity of an attacker to get information out through the choice, timing and order of different benign calls.