Automating Firebase Security Rules Audits with an AI Agent

At 4:47 on a Friday afternoon, a developer publishes a Firestore rules release to unblock a feature demo. The change loosens a match block from per-document ownership to "any signed-in user can read." The console records the release, replaces the previous ruleset, and pages nobody. On Monday, your orders collection has been readable by every account in the project for sixty hours — including the ones created through anonymous auth.

That failure mode is why a Firebase security rules audit can't be a quarterly event. This is part three of our Firebase security audit series. Part one mapped the misconfigurations that actually expose Firebase apps — test-mode rules that never got replaced, auth-only-but-any-user reads, missing App Check. Part two showed how to audit all of it with the Firebase CLI, the Rules Playground, and the Emulator Suite.

If you worked through part two, you hit its closing problem head-on: the audit is point-in-time and per-project, and a rules release like the one above lands silently between audits. This article covers closing that gap with Olivier, CloudThinker's security agent — continuous auditing, release diffing, and approval-gated fixes.

Why rules releases beat scheduled audits

Firestore, Cloud Storage, and Realtime Database rules are code that deploys like code — except in most teams they skip the review pipeline. A firebase deploy --only firestore:rules from a laptop, a paste into the console editor, a CI job with over-broad credentials: each one publishes a release that completely replaces the active ruleset. There is no partial deploy and no built-in "this release widened access" alarm.

So the security posture of a Firebase project isn't a state you audit; it's a stream of releases you have to watch. A manual audit samples that stream once. Everything between samples is faith.

How Olivier audits Firebase

Connecting: read-only, about five minutes

Olivier connects to Firebase through a Google Cloud service account with viewer-level roles only — roles/firebaserules.viewer to read rulesets and releases, plus project-level viewer access for inventory. No editor or owner roles, no write scopes, no ability to publish a ruleset at connection time. You create the service account from the policy in the Firebase connection guide, upload the key or bind via workload identity federation, and the first scan starts. Your security review can read the exact grants before anything connects.

Project and app inventory

The first thing a scan produces is the thing most teams don't have: a complete inventory. Every Firebase project the credentials can see, every registered app (web, iOS, Android) inside it, and which services are actually live — Firestore, Realtime Database, Cloud Storage, Auth, App Check. For each one: does it have deployed rules, when was the last release, and does anyone appear to own it.

This matters because the riskiest Firebase project is rarely the one your team works in daily. It's the 2021 prototype still bound to a production Google Cloud billing account, with Realtime Database rules nobody has opened since the hackathon.

Continuous rules audit with risky-pattern detection

For every project, Olivier pulls the active ruleset for Firestore, Storage, and Realtime Database and evaluates it against the anti-pattern catalog from part one:

• Open rules — allow read, write: if true; in any match block, or RTDB rules with ".read": true at the root.
• Expired-by-design test mode — the console's default time-boxed rules, especially ones where the deadline was hand-edited years into the future:

// Flagged: "test mode" rules with the timestamp pushed out to 2030
match /{document=**} {
  allow read, write: if request.time < timestamp.date(2030, 1, 1);
}

• Auth-only-but-any-user access — allow read: if request.auth != null; on collections holding per-user data, with no check that request.auth.uid matches the document owner. With email/password or anonymous sign-in enabled, "any signed-in user" means "anyone."
• Missing ownership checks on writes — rules that validate authentication but not that the caller may modify this document, enabling cross-user overwrites.
• Storage rules broader than the Firestore rules guarding the same data — a common drift pattern: the database gets locked down, the bucket holding its file attachments doesn't.

Each finding carries the ruleset excerpt, the match path, which registered apps can reach that service, and a severity — the same evidence you assembled by hand in part two, refreshed continuously instead of quarterly.

Release watch: the Friday-afternoon problem

This is the piece no point-in-time audit can give you. Every rules release — Firestore, Storage, or RTDB — is diffed against the previous ruleset the moment it lands. If the diff widens access (a condition removed, a match path broadened, an ownership check deleted, a wildcard added), Olivier raises an alert with the before/after diff, who published it, and which collections or paths are newly exposed.

The Friday release from the opening paragraph becomes a Slack message at 4:48, not an incident review on Monday.

App Check and Auth configuration watch

Rules are the main gate, but part one covered the rest of the perimeter, and Olivier watches it too:

• App Check status per service — registered but unenforced is the most common finding; enforcement that was turned off "temporarily" during a mobile release and never restored gets flagged as drift.
• Auth provider hygiene — anonymous auth enabled on production projects, email enumeration protection disabled, sign-in providers nobody remembers enabling.
• Authorized domains — entries pointing at long-dead staging hosts or third-party domains.

Graduated autonomy: nothing touches your rules without approval

Every action class in CloudThinker has an autonomy level you set per environment:

• Notify — report the finding. Nothing else. This is the default for everything, and for rules changes it is where most teams stay.
• Suggest — propose a corrected ruleset: the specific match blocks rewritten with ownership checks, with a note on which client behavior could break.
• Approve — stage the fix; it publishes only after a named human approves. For rules this means the exact ruleset text is in front of a reviewer before release — the review step that Friday deploy never had.
• Autonomous — execute and report. Almost no one should use this for production security rules, and the sensible exception is narrow: re-locking a dev project that has sat in open test mode past its own expiry date.

Publishing a ruleset requires write access the read-only connection deliberately does not have — you grant it separately, scoped, only if you want approval-gated remediation at all. Every proposal, approval, and release lands in the audit trail: finding, evidence, proposed diff, approver, timestamp.

What a first scan typically finds

Illustrative numbers — a composite first scan across a mid-market SaaS org with a dozen Firebase projects. Yours will differ.

The shape is typical: the critical items cluster in projects nobody audits, and the release-hygiene finding at the bottom explains how the ones at the top happened.

Prompts to try in your first session

Olivier is conversational — you ask in plain language:

• "Olivier, inventory every Firebase project we have and flag anything still on default or test-mode rules."
• "Diff the last two Firestore rules releases in the production project and tell me exactly what an unauthenticated or anonymous user can now read."
• "Which apps have App Check registered but not enforced for Firestore or Storage, and what would enforcing it break?"

Each answer cites the ruleset text and release history behind it — the same artifacts you pulled from the Rules management REST API in part two — so you verify rather than trust.

What Olivier will not do

• It will not publish, edit, or roll back rules without approval. Rules changes require explicitly granted write access and an autonomy level above Notify for that specific action in that specific environment.
• It will not disable auth providers or flip App Check enforcement on its own. Both can break live clients; both stay approval-gated.
• It will not act outside the audit trail. Every finding, proposal, and executed change is logged with evidence and approver.
• It will not decide your data model's access semantics. It can prove any signed-in user can read orders; whether that is a bug or a business rule is a call that stays with your team.

From audit to standing watch

You know which Firebase misconfigurations matter, and you know how to find them with native tools. The remaining gap is the one the Friday release exploits: rules change continuously, and audits don't. Putting a read-only agent on the release stream turns a silent regression into a same-hour alert, and turns remediation into a reviewed, logged, approval-gated release instead of another untracked deploy.

Try CloudThinker free — 100 premium credits, no card required — connect Firebase read-only via the connection guide, and get your first project inventory and rules findings within the hour.