# Firebase AI Logic App Check Enforcement Starts: What Developers Need to Check

The November 2 security deadline makes older installed app versions part of the migration problem.

By Paras Madan | 2026-11-03

Firebase's November 2 deadline for automatic App Check enforcement in AI Logic has arrived. Requests without valid attestation can be blocked, including requests from older app versions. For developers using Gemini through Firebase, the immediate question is whether the apps people actually run are ready.

## What changed on November 2

The [Firebase FAQ](https://firebase.google.com/docs/ai-logic/faq-and-troubleshooting) says automatic enforcement starts November 2 for projects where App Check is not already enforced. Released clients without a production attestation provider are included.

This is a previously announced requirement taking effect, not a new Gemini model or a confirmed platform-wide outage. The documentation establishes the policy; it does not establish the exact activation time or current state of every Firebase project.

A temporary delay is available in the console under Security, App Check, then APIs. Find Firebase AI Logic and edit its enforcement date. January 21, 2027 is the last available date. Firebase warns that delaying protection leaves Gemini access exposed to abuse.

## What App Check actually verifies

[App Check for AI Logic](https://firebase.google.com/docs/ai-logic/app-check) uses attestation to help establish that a request comes from the genuine app or an authentic device. Firebase's proxy applies that protection when mobile and web clients access Gemini.

The distinction matters because a working API request and a verified client are different things. A product can have a functioning AI feature while still accepting traffic that should never have reached its model backend.

Firebase already automatically enabled enforcement during its guided setup from early July. The November deadline therefore matters particularly to older projects and any other projects still operating without enforcement. For local development, Firebase provides a debug provider, but explicitly warns against shipping debug tokens or debug builds to production.

## Test installed versions, not just the latest build

The migration risk is distribution. Adding attestation to the current codebase does not update a copy of the app already sitting on someone's phone.

A useful readiness check separates the versions still in use, the requests they make, and the proportion arriving with valid attestation. That turns a vague question about whether App Check is configured into a concrete question about which users would lose access when enforcement applies.

Teams with browser voice features should also test their Live API path separately. An [open Firebase JavaScript SDK issue](https://github.com/firebase/firebase-js-sdk/issues/10018) contains developer reports that Live WebSocket connections omitted App Check tokens even while ordinary HTTPS calls worked. Those reports are not proof that every current SDK or application has the same defect, but they are a reason not to treat one successful text request as coverage of the whole application.

## A migration window is not the fix

The temporary delay gives teams room to ship and distribute a compatible release. It does not resolve the underlying exposure, and it should not become a substitute for checking real client traffic.

The practical finish line is a protected endpoint that the supported installed versions can still use. For client-side AI products, security changes increasingly depend on release management as much as backend configuration.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn product changes and engineering decisions into clear stories developers can use and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).