Repository navigation
Authorization for multi-tenant MCP servers and gateways: where should per-resource audience binding and policy live? #850
Replies: 2 comments 6 replies
|
I like the split between resource-specific audience binding and a separate per-operation policy layer. One boundary I’m unsure about is device-facing calls, where an operation may depend on more than subject, capability and resource path before it should proceed. For example, if a caller is authorized to invoke start_motor on a particular asset, should current operational state or safety preconditions be inputs to that same policy decision? Or do you see those checks as intentionally belonging behind the MCP authorization boundary, in a separate device/backend safety layer? That seems directly relevant to your third question. In a device-facing deployment, an operation can be authorized for a caller and resource without necessarily being safe to carry out at that moment. |
|
I think the distinction you draw between top-down authorization and bottom-up safety enforcement is the right one, especially because it avoids making a potentially stale authorization decision carry live physical-state authority. On the first question, I would lean toward a distinct structured result for a safety refusal rather than a generic error. “Not authorized to attempt this operation” and “authorized to attempt it, but the device refused it under current conditions” describe different events and may need different audit and retry behavior. I would be cautious about making safety refusal implicitly retryable, though; that seems like something the enforcing layer should state explicitly. On exposing safety state or preconditions as resources, I can see value if they are clearly advisory. They could help an agent avoid obviously futile or unsafe requests, but I would not want observing a “safe” state to become evidence that the subsequent operation is safe to execute. The enforcement point still needs to evaluate live state locally. So perhaps the protocol-level distinction is less about standardizing safety policy itself, and more about preserving the difference between authorization granted, execution refused by safety, and execution completed. |
|
Yes, that reframe is the right altitude: the protocol should not standardize On retryability, agreed it must be explicit. A safety refusal is a statement On advisory state, agreed it stays non-authoritative: observing "safe" is never So the minimal, mostly semantic surface: three outcomes (authorization-denied, I put all of this into a small in-browser illustration if it helps make it Would you be up for shaping this into a short proposal together, or taking it to |
|
I went through the motor demo as well. It makes the effect-level point much clearer. The critical-operation example is particularly useful: blocking stop would not be enough if set_speed(0) can produce the same physical effect. That makes a strong case for expressing inhibition in terms of the effect being prevented rather than the tool name used to request it. I also like that the safety resource is explicitly advisory and non-authoritative. An agent can use it to avoid obviously futile requests, while the device still re-evaluates live state at execution. That preserves the separation between information exposed to the caller and the authority to decide whether the physical action may actually occur. I agree that MCP itself should not have to infer that stop and set_speed(0) are equivalent effects. That meaning belongs with the backend or device layer that understands the domain; the protocol can preserve the resulting semantics. The three-outcome shape therefore feels clean to me: authorization-denied, safety-refused, and completed. Making safety-refused explicitly retryable or non-retryable also avoids callers inventing retry behaviour from an ambiguous error. I’d be happy to give focused feedback on a short draft and help pressure-test this boundary. I’m heads-down on my own work, so I probably can’t co-own the proposal or commit to an ongoing working-group role, but I’d be glad to contribute asynchronously where it’s useful. Taking the resulting shape to the auth/security group sounds worthwhile. |
|
This is really helpful, thanks for going through the demo and pressure-testing Completely understood on bandwidth. Async review is exactly what helps most, no
Once it is in shape I'll take it to the auth/security interest group, and I'll Thanks again for sharpening it. |
|
Sounds good. Happy to review the short draft when you tag me. Keeping the boundary narrow and effect-level sounds like the right shape. |
|
On question 1, I think your split is right. Audience binding (RFC 8707 resource indicators, checked against the On 2, I'd make hiding a SHOULD for aggregators and say plainly that it isn't the enforcement point. A client can still call a tool it never saw in tools/list, so the per-call check is what actually protects the backend. On 3 and the start_motor example above: I'd keep safety preconditions (current device state, interlocks) behind the boundary in the device layer and let the policy decide only whether this caller may ask. Device state can change between the policy decision and the actuation, so that check has to sit next to the actuation anyway. Policy can still take state as an input for rules like "only during a maintenance window", as long as it isn't the last check before the motor moves. I work at Permit, and we wrote about the same split (OAuth and audience for the token, a separate policy check per tool call): https://www.permit.io/blog/authorization-strategies-for-model-context-protocol-mcp |
Uh oh!
There was an error while loading. Please reload this page.
Pre-submission Checklist
Your Idea
What problem does it solve?
Multi-tenant MCP deployments have no agreed pattern for authorization. When a
gateway or broker fronts many MCP servers behind one endpoint, exposed beyond a
trusted network (and increasingly device-facing), every deployment reinvents:
replayed against another (RFC 8707 / RFC 9728);
explicit denies), evaluated per operation;
learn that a backend it is not authorized for exists;
Who would benefit?
Anyone running MCP for many clients and many backends behind one address:
gateway/broker operators, enterprises exposing internal MCP servers, and
hardware/device-facing deployments where the authz boundary is safety-relevant.
How might it be implemented?
The building blocks already exist in OAuth 2.1 + RFC 9728/8707; the open question
is which parts the protocol should recommend or standardize versus leave to
implementations. This is not theoretical: I built and shipped a working reference
that implements all of the above end to end (Apache-2.0), so the "how" is proven,
not hypothetical:
Per the SEP guidance (validate the problem, build a prototype, then write the
SEP), the prototype exists; this post is me validating shared interest before
drafting a SEP.
Open questions
or should more live in the protocol?
existence leak) as a pattern for aggregation?
Disclosure: I am the dev/maintainer of the implementation linked above, and this
post was drafted with AI assistance, as English is not my native language.
Scope
All reactions