[Feature] Expose fail_closed through authplane_fastmcp.authplane_auth

[4444J99]

Affected Package

• authplane-sdk
• authplane-mcp
• authplane-fastmcp
• New package

Problem

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:

result = await authplane_auth(
    issuer="https://auth.company.com",
    base_url="https://mcp.company.com",
    revocation_checker=IntrospectionRevocation(),
    fail_closed=True,
)

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.

[RobertoIskandarani]

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.