Authorisation that survives injection

The security problem with tool-using agents can be stated in one sentence: they translate natural language, which may contain attacker-controlled text, into privileged tool calls. Everything else follows from that, including the conclusion that authorisation has to hold even when the agent itself has been successfully steered.

A paper posted this week examines whether the Model Context Protocol — now the widely adopted interface at exactly that boundary — provides what enterprises need. The authors conducted a systematic gap analysis across six official SDKs: Python, TypeScript, Go, Rust, C# and Swift.

They report three structural shortcomings.

• Credential extraction bound to a single Authorization header, which complicates the dual-persona case — one server serving human users through corporate single sign-on and automated agents through service-account credentials on a different header — without custom middleware.
• No pre-authentication tool discovery, so a client cannot learn what a server offers before holding credentials for it.
• No fine-grained per-tool authorisation in the base SDKs, which pushes the decision of which tools a caller may invoke outside the protocol layer.

The proposed remedies are composable extensions rather than protocol changes: cross-header credential normalisation, cached token verification across different identity providers, an unauthenticated metadata endpoint for credential-free registry discovery, and permission-filtered tool visibility kept consistent with per-tool enforcement through a single declarative annotation.

The last of those is the one that matters in practice. Filtering what a caller can see and enforcing what a caller can invoke are two separate mechanisms in most deployments, and they drift apart. Binding them to one declaration removes a category of bug rather than a specific instance of it — which is the same argument this desk has made about the difference between a filter and a boundary.