# The rule read fine. Any rider, any order.

> A review uses one identity. An attack needs two.

- **Format:** short video, 9 steps, ~51 seconds
- **Topic:** Security, cybersecurity and penetration testing AI agents — a Firestore rule that reads correctly lets any signed-in rider read every customer’s name, phone and address, found only by testing with a second rider, and why credentials should be ranked by blast radius.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** AI · AI
- **Published:** 2026-08-27
- **Tags:** appsecurity, firebase, firestore, pentesting, aiagents, flutter, cybersecurity, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/ai-security-agents-read-then-attack/

---
## What you'll learn

- Why a security finding needs an exploit path
- Why Firestore rules need a second identity per role
- How to rank credentials by blast radius

## Understand it one step at a time

### 1. The rule reads fine

Customers, the restaurant, and riders can read an order.

### 2. The review is clean

One reviewer, one identity. The app only asks for the right orders.

### 3. The exploit path

Sign in as any rider. Read orders/{any id}. Get a stranger’s phone and address.

### 4. A role is not ownership

isRider() checks the caller. It never compares the order to the caller.

### 5. Pen test: two riders

riderA is assigned o-1. riderB reads it. The test expects denied.

### 6. The fix, and the test stays

isAssignedRider() compares rider.id to request.auth.uid. The test runs on every push.

### 7. Cyber: blast radius

Rank credentials by what an attacker can do, not by how visible they are.

### 8. Three agents disagree

The review passed it. The attack failed it. That disagreement is the point.

### 9. Read the rules, then attack them

An exploit path per finding, credentials by blast radius, two accounts per role.

---

## The takeaway

**Read the rules. Then attack them.**

A permissive rule and a correctly behaving app look identical from inside the app.