LiteLLM 1.105 RC: MCP, Guardrail and Proxy Migration Changes to Test

LiteLLM published v1.105.0-rc.1 on October 4, 2026, at 01:41 UTC. The prerelease adds a Microsoft 365 MCP catalog entry and changes Straiker guardrail handling and proxy database startup. PyPI also carries 1.105.0rc1. For teams running LiteLLM as an LLM gateway, these are reasons for targeted staging checks—not evidence that the RC is ready for production.

Our recommendation: evaluate the RC if one of those paths matters to your deployment. Keep the current validated build as the baseline, and require both expected refusals and successful service before considering promotion. The checks below are proposed acceptance tests, not results from a deployment we ran.

Where to focus staging

Pin the complete candidate

Use the existing lockfile or image-building workflow in an isolated environment. Version-specific package metadata requires Python 3.10 or newer and below 3.15; its proxy extra pins litellm-proxy-extras==0.4.105. That dependency is available on PyPI. Record the resolved dependencies, not just the top-level LiteLLM version.

For a deployment already using the proxy extra, the requirement pin is:

litellm[proxy]==1.105.0rc1

Preserve any additional extras your deployment needs. For containers, record the chosen image digest and follow the release’s signature-verification procedure. Keep the prior working artifact and configuration available. Container-signature verification was not performed for this guide.

Database startup: check refusal and surviving capacity

When database setup returns failure, RC1 stops proxy startup without the former enforcement opt-in. The release-pinned CLI exits 1 for that result and 2 for a migration RuntimeError. The maintainer comparison identifies the legacy resolver as the changed path; v2 already stopped on its own errors. This is not a claim that every earlier deployment continued after failure.

• Use a disposable database clone representing the deployed schema. Exercise a normal upgrade, an unreachable database and a failed migration with each resolver you actually use. Record logs, exit status and readiness transitions.

• After the successful case, verify an authenticated completion, key/team lookup and persisted usage. After failure, verify that the new instance does not receive traffic. A liveness response alone is insufficient.

• For multiple replicas, verify that existing instances remain ready and have enough capacity during a failed rollout. That depends on rollout policy and database compatibility. A single-instance replacement has no surviving replica to rely on.

For concurrent startup, the P3009 recovery backport retries when a peer has already completed or rolled back the specifically identified failed migration attempt. It is not recovery from every migration error. The PR explicitly says its three-replica end-to-end scenario was not rerun on the RC branch; repeat the relevant scenario in your topology.

Keep migration ownership explicit. LiteLLM documents a beta Helm PreSync pattern with schema updates enabled in the migration job and disabled in serving pods. If using that pattern, verify the job completes before pods become ready; do not disable migrations merely to get past an error.

The practical tradeoff is availability versus serving with unusable database state: stopping a new instance can be correct while the rollout still loses capacity. Treat refusal and continued service as separate acceptance criteria. Also verify Prisma is present in the assembled artifact; the tagged missing-Prisma branch prints a warning rather than establishing the same fatal-exit guarantee. Tagged startup source.

Straiker: a successful HTTP response is not an allow decision

In the RC implementation, the Straiker API-key prefix sk_agt_ selects /api/v3/detect even if a saved configuration says api_version: v1. A missing verdict—or ask without a blocking control—uses the error policy. With the default fail_on_error=true, it blocks; setting that option to false permits error cases. Detect-mode actions remain nonblocking.

Test an HTTP 200 response with no actionable decision separately from an unreachable service. unreachable_fallback=fail_open alone does not permit the missing-decision case: the failure handler distinguishes those categories.

Build deterministic checks from the upstream regression fixtures:

• Allow, explicit block, absent decision, ask and malformed blocked_by, with fail_on_error enabled and disabled. For a pre-call block, verify the model was not invoked.

• A saved v1 configuration using a v3-format key, with route verification that does not log credentials; text-only guardrail calls, including empty messages.

• Repeated blocked requests, a blocked response followed by retry, and two callers sharing a session identifier. Request-block memory is scoped by principal and session and is process-local; do not treat it as a cluster-wide replay guarantee.

Exercise the real streaming client too. Straiker’s documented post-call behavior buffers the response until moderation completes. Check delivery and cancellation against your application’s targets; the documentation provides no measured RC latency result. If Pydantic AI is the client, its separate streaming lifecycle checks remain relevant—the LiteLLM upgrade does not fix client-library issues.

Microsoft 365: complete identity setup beyond the catalog

The new catalog record points to the independently maintained Softeria Graph MCP server, with http://localhost:3000/mcp as its default address. It is a self-hosted integration, not a new Microsoft-operated hosted service. In a container deployment, that address must resolve from the proxy’s runtime, not the administrator’s laptop.

The Microsoft 365 setup guide requires an Entra app, delegated permissions and per-user authorization-code sign-in. Configure auth_type: oauth2, oauth2_flow: authorization_code and per_server_oauth_discovery: true; match the registered callback to the proxy’s public origin. Gateway authentication and Graph authorization are separate.

For staging, pin the Graph server independently, restrict access to the proxy and use synthetic tenant data. The server’s upstream documentation supports --read-only and --enabled-tools to narrow exposed tools. Match delegated permissions to that limited task.

Check two users with different permitted resources, a denied tool or resource, and reconnection in a fresh session. A consent screen or tools listing is not sufficient. The setup guide also requires a LiteLLM user behind the key and appropriate server permission so that the user’s Graph authorization can persist.

Audit provider metadata without assuming savings

The Azure Sonnet metadata correction changes the azure_ai/claude-sonnet-4-5 retirement date from November 15 to November 30, 2026. Microsoft’s current Foundry schedule lists November 30 for version 1, with claude-sonnet-5-5 as replacement. Audit actual provider/model routes and fallbacks if you use that offering; this is not a universal Anthropic deadline or evidence of cheaper inference.

Promotion and rollback criteria

Consider promotion only after the changed paths your application uses pass their acceptance checks and the RC fits your release policy. Otherwise retain the validated baseline. This evidence establishes neither a general-availability date nor a production-readiness guarantee.

Plan application rollback and database recovery separately. Follow the rollback guidance: preserve a database backup and the deployment’s encryption configuration, and confirm the prior code can use any schema already applied. Stopping a rollout does not undo committed migrations. Investigate the exact failed attempt and database state instead of blanket deletion of migration history.

Methodology: AI-assisted analysis of official release records, package metadata, release-pinned source and documentation checked on October 4, 2026. No gateway, database, Microsoft 365 tenant or guardrail runtime tests were performed. The acceptance checks above are recommendations, not measured outcomes.