This is a submission for the Google I/O Writing Challenge

Firebase AI Logic is genuinely exciting. It went GA at Google I/O 2026, meaning you can call Gemini directly from your web or mobile app: no backend server, no API key in your bundle, no infrastructure to manage. The developer experience is real.

But putting an AI endpoint on the internet creates an attack surface. And most of the posts I have read including some in this challenge — cover only one of the security mechanisms Google shipped.

There are four. They compose. This post walks through all of them.

The Threat Model: What You Are Actually Defending Against

Before any code, let's be precise about what can go wrong.

Quota exhaustion anyone who finds your endpoint and scripts against it drains your token budget. Every AI call has a direct billing impact.

Prompt injection if your system instructions live in client code, they can be extracted through binary decompilation or network interception and then exploited.

Token replay even short-lived auth tokens can be intercepted and reused. A 5-minute window is enough for a script to hammer your endpoint.

Unsafe content at inference time user inputs that reach the model are not sanitized by default. Without enforcement at the inference layer, adversarial inputs can get through.

Each of the four layers I'm about to show you closes one of these gaps directly.

Layer 1: The Proxy Architecture

Closes: quota exhaustion via API key theft

The naive approach embed your Gemini API key in the app bundle and call the API directly will eventually fail. App bundles are decompilable. Network traffic is observable.

Firebase AI Logic solves this at the architecture level. Every SDK request routes through Firebase's proxy servers. Your Gemini API key lives on Firebase's infrastructure and is never transmitted to the client.

// firebase.ts
import { initializeApp, FirebaseApp } from 'firebase/app';
import { getAI, GoogleAIBackend, AI } from 'firebase/ai';

const firebaseConfig = {
  apiKey: "your-firebase-api-key",            // ✅ Firebase Web API key — safe in client.
  authDomain: "your-project.firebaseapp.com", // This is a project identifier,
  projectId: "your-project-id",               // NOT a billing credential.
  appId: "your-app-id"
};

const app: FirebaseApp = initializeApp(firebaseConfig);

// All requests route through Firebase's proxy.
// Your Gemini API key never leaves Firebase's servers.
const ai: AI = getAI(app, { backend: new GoogleAIBackend() });

export { app, ai };

The Firebase Web API key is not a secret — it is a project identifier scoped by your security rules. Your Gemini API key, which carries billing authority, never appears in your codebase.

Layer 2: Server Prompt Templates + Template-Only Mode

Closes: prompt injection and prompt extraction

If your system instructions live in client code, two things can go wrong:

1. Anyone who decompiles your app binary can read your exact prompt.
2. If you compose prompts dynamically from user input, a determined user can craft inputs designed to override your system instructions. Server prompt templates move your entire prompt configuration — system instructions, model selection, safety settings, input schemas — to Firebase's servers. The client sends only a template ID and typed variable values.

Template-Only Mode, announced at I/O 2026, enforces this strictly: Firebase AI Logic will only execute prompts stored on the server. Any custom prompt instructions sent directly from client code are ignored entirely.

Templates are defined in the Firebase console using Dotprompt syntax:

---
model: gemini-3.1-flash
config:
  temperature: 0.4
  topP: 0.9
input:
  schema:
    userQuery: string
    userName?: string
---
{{role "system"}}
You are a professional support agent for Acme Corp.
You answer questions about orders, returns, and shipping only.
You do not engage with topics outside these areas.

{{role "user"}}
{{#if userName}}Customer {{userName}} asks:{{/if}}
{{userQuery}}

Everything above — model, config, system instructions, input schema — lives on Firebase's servers. On the client, use getTemplateGenerativeModel() as specified in the official JS SDK reference:

// secure-chat.ts
import { getAI, GoogleAIBackend, getTemplateGenerativeModel } from 'firebase/ai';
import { app } from './firebase';

// Typed interface matching the template's input schema.
// Enforced at compile time — no undeclared fields can reach the template.
interface SupportTemplateVariables {
  userQuery: string;
  userName?: string;
}

const ai = getAI(app, { backend: new GoogleAIBackend() });

// Must use getTemplateGenerativeModel() — not ai.templateGenerativeModel()
const templateModel = getTemplateGenerativeModel(ai);

export async function askSupportAgent(
  userInput: string,
  displayName?: string
): Promise<string> {
  const variables: SupportTemplateVariables = {
    userQuery: userInput,
    userName: displayName ?? undefined,
  };

  // Client sends only: template ID + typed variable values.
  // System instructions, model config, and safety settings
  // are composed server-side and never reach the client.
  const result = await templateModel.generateContent(
    'support-agent-v2',
    variables
  );

  return result.response.text();
}

Note what is absent from the client code: no system prompt, no model name, no safety configuration. None of those are available to read, modify, or override. With Template-Only Mode enabled, this is the only kind of request Firebase AI Logic will accept from your app.

The TypeScript interface matters beyond type safety — it makes the contract between client and server explicit and compiler-enforced. If a developer tries to pass an unintended field that could leak into the prompt, the compiler catches it before it ships.

Layer 3: Firebase App Check + Replay Attack Protection

Closes: unauthorized clients and token replay

Template-Only Mode secures the content of your prompts. App Check addresses who is allowed to send requests in the first place.

App Check uses device attestation providers — Play Integrity on Android, DeviceCheck on Apple, and reCAPTCHA Enterprise on web — to generate cryptographic tokens proving a request came from a genuine, unmodified instance of your app. Firebase validates these tokens before processing any AI request.

// app-check.ts
import { initializeAppCheck, ReCaptchaEnterpriseProvider, AppCheck } from 'firebase/app-check';
import { FirebaseApp } from 'firebase/app';
import { app } from './firebase';

export function initializeSecureAppCheck(app: FirebaseApp): AppCheck {
  return initializeAppCheck(app, {
    provider: new ReCaptchaEnterpriseProvider(
      import.meta.env.VITE_RECAPTCHA_ENTERPRISE_SITE_KEY
    ),
    // The SDK automatically attaches a fresh App Check token
    // to every outgoing Firebase request — no manual token
    // management needed anywhere in your app.
    isTokenAutoRefreshEnabled: true,
  });
}

// main.ts — call this once before any Firebase AI Logic requests
import { initializeSecureAppCheck } from './app-check';
import { app } from './firebase';

initializeSecureAppCheck(app);

Replay attack protection, which shipped in May 2026, closes the remaining gap. Even with short-lived tokens App Check already supported lifespans as short as 5 minutes an intercepted token can be reused within its validity window. For AI endpoints billed per token, that window is exploitable.

With replay protection enabled, each App Check token is strictly single-use. The first request that presents a token consumes it permanently. Any subsequent request with the same token is rejected immediately.

Enable replay protection in the Firebase console under App Check → [your app] → Limited-use tokens. No client code changes beyond the initialization above.

Layer 4: Model Armor — GA with Firebase

Closes: unsafe content at inference time

The previous three layers secure authentication and prompt structure. Model Armor addresses what actually reaches the model at inference time.

Google Model Armor reached general availability with Firebase at Cloud Next 2026. It operates as an enforcement layer between your Firebase AI Logic request and the Gemini API — inspecting both the prompt being sent to the model and the response being returned. Configurable guardrails cover harmful content, prompt injection attempts, sensitive data patterns, and custom policy rules.

The key characteristic of the Firebase integration: it requires zero changes to your application code. Model Armor is configured at the Firebase project level in the Google Cloud console. Your SDK calls pass through it transparently.

// Your application code is identical with or without Model Armor.
// Enforcement happens at the Firebase infrastructure layer.

export async function askSupportAgent(
  userInput: string,
  displayName?: string
): Promise<string | null> {
  const variables: SupportTemplateVariables = {
    userQuery: userInput,
    userName: displayName,
  };

  try {
    const result = await templateModel.generateContent(
      'support-agent-v2',
      variables
    );
    return result.response.text();

  } catch (error: unknown) {
    // If Model Armor intercepted the input or output as a policy violation,
    // Firebase returns an error before the model processes it.
    // You handle the error — not the unsafe content.
    if (error instanceof Error) {
      console.error('Request blocked by content policy:', error.message);
    }
    return null;
  }
}

Guardrails content categories, sensitivity thresholds, custom filters are managed through the Google Cloud console. You can update them without touching client code or releasing an app update.

What the Full Stack Looks Like End to End

User submits input
        │
        ▼ TypeScript interface — typed variables enforced at compile time
        │
        ▼ Firebase SDK — App Check token automatically attached
        │
        ▼ Firebase Proxy — token validated; replay check (single-use)
                         — Gemini API key never leaves server ✓
        │
        ▼ Firebase AI Logic — Template-Only Mode enforced
                            — Server template composed, not client prompt ✓
        │
        ▼ Model Armor — input inspected against guardrails ✓
        │
        ▼ Gemini API — processes sanitized, policy-compliant prompt
        │
        ▼ Model Armor — response inspected before return
        │
        ▼ Your app receives a clean, policy-compliant response ✓

An attacker who extracts your binary finds no API key and no system prompt. An attacker who scripts requests finds their tokens rejected after first use. An attacker who crafts adversarial inputs finds them stopped before the model.

What Is Still Your Responsibility

These four layers are not a complete story on their own.

Firestore Security Rules Firebase AI Logic secures the AI inference path. If you store conversation history or user data in Firestore, your Security Rules govern who can access it. A secured AI feature in front of an open database is still a vulnerability.

Firebase Authentication App Check verifies that a request comes from your app. It does not verify which user is making it. If your AI feature should only be accessible to authenticated users, Firebase Authentication provides that boundary.

Your own output handling Model Armor filters content at the infrastructure layer. Your application still needs to handle model responses safely rendering output correctly, not blindly executing model suggestions, and validating AI-generated content before treating it as trusted data.

The Bigger Picture

The features Google shipped across Cloud Next 2026 and I/O 2026 make something clear: they built the security infrastructure alongside the capability, not as an afterthought.

The proxy architecture, Template-Only Mode, App Check replay protection, and Model Armor are not independent features. They are a layered answer to a single question: how do you ship an AI feature in a client app that a serious engineering team can stand behind?

The developers who answer that question well will be the ones who implement all four layers not just the ones their quickstart tutorial covered.

All four are available to you today.

Note on TemplateGenerativeModel: As of the JS SDK reference dated May 2026, this class is in Public Preview and the API shape may evolve. Always instantiate via getTemplateGenerativeModel(ai) — not ai.templateGenerativeModel(). Check the official reference before shipping.

Sources: Firebase AI Logic docs · What's new from Firebase at Google I/O 2026 · Ship production AI features faster — Cloud Next '26 · Server prompt templates: get started · TemplateGenerativeModel JS API reference