Authorization for multi-tenant MCP servers and gateways: where should per-resource audience binding and policy live?

[pandaGaume]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

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:

• per-backend audience binding, so a token minted for one server cannot be
  replayed against another (RFC 8707 / RFC 9728);
• who / what / where policy beyond coarse scopes (roles, resource hierarchies,
  explicit denies), evaluated per operation;
• per-caller confidentiality of aggregated catalogs, so a client cannot even
  learn that a backend it is not authorized for exists;
• a clear place for the authorization/safety boundary in device-facing servers.

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:

• Authorization model: https://github.com/pandaGaume/mcp-broker/blob/main/docs/authorization.md
• Hierarchical policy: https://github.com/pandaGaume/mcp-broker/blob/main/docs/hierarchical-authorization.md

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

1. Is per-resource audience binding plus a separate policy layer the right split,
   or should more live in the protocol?
2. Should the spec recommend hiding unauthorized capabilities entirely (no
   existence leak) as a pattern for aggregation?
3. Where should the authorization boundary sit for device-facing servers?

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

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[Portotify]

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.

[pandaGaume]

This is the crux, and I think the key is that the safety context is not the
caller's to decide, nor the LLM's.

Take two calls with the same MCP shape: "capture an image" on a microscope, and
"stop the motor" on a life-support scrubber (a CO2 scrubber that keeps people
breathing). Identical to the authorization layer, a subject invoking a capability
on a resource, yet worlds apart in consequence. Whether the second is safe right
now simply cannot be answered from subject, capability and resource path.

So I keep the two separate, and I think of them as flowing in opposite directions:

• Intent flows top-down. The LLM sets the high-level strategy and expresses it
  through MCP. That is where authorization lives: "may this caller attempt this
  operation on this resource?" It can be central, cached, decided ahead of time.
• Safety is enforced bottom-up, as a cascade, each layer faster, more local and
  more deterministic than the one above: policy, then an embedded reflex layer on
  the device (local control/AI that reacts on live state with no round-trip),
  then a hardware disengage that no software path can override. The higher the
  consequence, the lower the layer that must hold the veto.

They are complementary, not substitutes: authorized does not mean safe, and the
device is the final authority on physical safety. Folding live safety state into
the authorization decision breaks this: the decision is already stale by the time
it reaches the actuator (TOCTOU), and an authz bug becomes an unsafe motion.

Two places where I think the protocol, not just implementations, might need to
say something, and I would value your read:

• whether an authorized call that a device refuses on safety grounds deserves a
  distinct, structured result rather than being flattened into a generic error;
• whether exposing safety state and preconditions as resources (advisory for the
  agent, still enforced device-side) is worth standardizing, or is better left to
  each backend.

In my setup the gateway authorizes stop_motor for an operator on an asset; the
embedded layer still refuses if the live context is unsafe, and a hardware
disengage sits under everything. Authorization said yes; the stack said not now.

[Portotify]

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.

[pandaGaume]

Yes, that reframe is the right altitude: the protocol should not standardize
safety policy, it should preserve the distinction between authorization granted,
execution refused by safety, and execution completed.

On retryability, agreed it must be explicit. A safety refusal is a statement
about a moment, so I would have it carry an explicit, machine-readable condition
(retryable or not, and what clears it: e-stop cleared, temperature in range),
never a bare "try again". Silence should mean not retryable.

On advisory state, agreed it stays non-authoritative: observing "safe" is never
evidence that the next call is safe; the device re-evaluates live at execution
(the time-of-check to time-of-use gap). One addition from actually building it:
the resource is most useful when it exposes not just values but the operations
currently inhibited and under what constraint, and those must be expressed by
effect, not by tool name. I inhibited "stop" during a critical op and immediately
bypassed my own guard with set_speed(0), a stop by another name.

So the minimal, mostly semantic surface: three outcomes (authorization-denied,
safety-refused, completed); safety-refused is structured and explicitly
(non-)retryable; safety-state is advisory, timestamped, non-authoritative, and
carries the inhibited effects, not just readings.

I put all of this into a small in-browser illustration if it helps make it
concrete

Would you be up for shaping this into a short proposal together, or taking it to
the auth / security interest group to see if others share the shape?

[Portotify]

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.