You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature] Expose fail_closed through authplane_fastmcp.authplane_auth #20
The core SDK exposes fail_closed on AuthplaneClient.resource(...), but the FastMCP convenience factory currently does not. A FastMCP integration that opts into IntrospectionRevocation() therefore cannot require rejection when the introspection/revocation check fails without bypassing authplane_auth() and constructing the resource manually.
Proposed Solution
Add a backward-compatible keyword argument to the public adapter and forward it at the resource boundary:
The implementation would add fail_closed: bool = False to authplane_auth() and include it in the kwargs passed to client.resource(...).
Acceptance criteria:
authplane_auth(..., fail_closed=True) forwards the setting to the core resource verifier.
The default remains False, preserving today's fail-open behavior.
A FastMCP adapter test proves True rejects an introspection/revocation-check outage while the default behavior is unchanged.
The FastMCP user guide documents the availability/security tradeoff and the credential requirement for authenticated introspection.
Alternatives Considered
Callers can use result.client.resource(..., fail_closed=True) themselves, but that duplicates the adapter wiring and defeats the one-call factory. A separate adapter-specific policy object would add unnecessary API surface for a core boolean that already exists.
Use Case
FastMCP servers handling mutation-capable or otherwise high-impact tools may prefer denial during authorization-server or introspection failures. This lets those integrations keep the supported authplane_auth() path while explicitly choosing fail-closed revocation behavior.
Additional Context
The core SDK already documents fail_closed and implements it on AuthplaneClient.resource(...); this request is limited to propagating that existing control through the FastMCP adapter.
Thanks for the detailed writeup. Confirmed on our side: the core already supports fail_closed on AuthplaneClient.resource(...), the FastMCP factory just never forwards it. Accepted as proposed, backward compatible with a False default.
We'll take this one ourselves and link the PR here once it's up.
Activity
RobertoIskandarani commentedon Jul 28, 2026
Thanks for the detailed writeup. Confirmed on our side: the core already supports
fail_closedonAuthplaneClient.resource(...), the FastMCP factory just never forwards it. Accepted as proposed, backward compatible with aFalsedefault.We'll take this one ourselves and link the PR here once it's up.
feat(fastmcp,mcp): expose fail_closed through the adapter auth factories
feat(fastmcp,mcp): expose fail_closed through the adapter auth factor…