DOCUMENT ACCESS · PATH OWNERSHIP
Firestore-style document access: compare path owner to caller
Send six agent requests against users/{uid}/notes paths and compare the path owner with the signed-in caller under each access path and rule.
Your experiment
The user alice asks the agent for her notes, then for bob’s notes, then to write into both folders and list notes across all users. Start with the server SDK and no tool check, then move to the client path and compare the rule sets.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Simplified model of Firestore-style security: rules are evaluated only for client SDK requests, server SDKs with service-account credentials bypass them, and a query is allowed only if the rule permits every document it could return (rules are not filters). Paths, users and notes are fictional; no Firebase project is contacted.
Six requests, one ownership question
Notes live under users/{uid}/notes/{id}, so the path itself names the owner. The agent, acting for a signed-in caller, sends six requests: get alice’s note n1, get bob’s note n7, list alice’s notes, write alice’s note n9, write bob’s note n8, and a collection-group query over everyone’s notes with no owner filter. For caller alice only the three requests on users/alice are legitimate.
Server credentials skip the rules
In the opening run How the agent tool reaches the database is the server SDK with a service account. Security rules are evaluated only for client requests, so all six requests are allowed and three of them reach data alice does not own: bob’s note, the write into bob’s folder and the all-users query. The Security rules selector has no effect on this path. Tick “Tool compares the path owner with the caller” and the same three requests are denied by the tool itself while alice’s three succeed. Choose caller bob and the tool allows only n7 and n8; choose Not signed in and it denies everything.
Rules on the client path
Choose Client SDK with the user’s token. With request.auth.uid == userId the three foreign requests are denied by the rules, including the collection-group query, because a query is rejected unless the rule allows every document it could return. Choose request.auth != null and all three foreign requests are allowed again: being signed in is not ownership. With allow read, write: if true and a signed-out caller, all six requests are over-permitted.
Locking clients out is a different trade
Choose Deny all client access on the client path. No foreign data is reachable, but alice’s own three requests are denied too, so the run reports three wrongly denied requests. Locked rules are a sensible design only when every request then goes through a server path, and that server path must carry the ownership check itself, which is the opening failure again.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time show each request, the decision and which layer decided it over sixty seconds; the table repeats each path’s owner, whether the caller owns it, the decision and the layer that decided it. The model covers path ownership only: it has no custom claims, field-level checks, resource.data conditions, rate limits or emulator, and nothing contacts Firebase. The rule texts are labels for the modeled behaviour, not a complete rules file.