Build1 distinct publisher3 min readPublished
The finest grain Firestore IAM offers is the whole database, so least privilege inside one is a property of your code rather than of the policy you wrote. One hackathon build shows what the alternative costs.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The collection name lives in your code, not in the policy. That is the whole mechanism. A grant attaches to a database, and there is nothing smaller to attach it to, so a role you wrote down as "write the events collection" is a role to write anywhere in that database [3]. Collection scoping is just a convention your own service happens to follow, not something the credential can see or enforce.
The boundary therefore holds for exactly as long as every write path in the pipeline is correct. Sakuda is blunt about what that is worth: he says the second named database, with the binding conditioned on the resource path, is the only place in the system where the security boundary is enforced by the platform instead of by his code being right [8]. A reviewer caught the original collection grant, and he calls it the single most useful piece of feedback he got [4].
Count what is left over. The post documents four failures: the collection grant, a design that pinned gemini-3.5-pro when the 3.5 family ships only as Flash and Flash-Lite [9], span markers that made the analyst model and the citation validator read different text [14], and fifteen synthetic essays that came out sounding like one writer [16]. Only the first had its remedy moved onto the platform, which leaves three sitting where they started [18].
The model pin is the clearest of the three. Pinning the Pro-tier model that does exist, gemini-3.1-pro-preview, satisfies the capability tier and fails the hackathon's Gemini 3.5-or-newer requirement [10], and that failure would not have surfaced until the first live API call, after the architecture was frozen [11]. He pinned gemini-3.6-flash and wrote a preflight that resolves every pinned model ID against the live catalogue and fails loudly [12]. That preflight is the same move as the second database. Both take a belief out of the author's head and hand it to something capable of contradicting him.
The essays make the point from the other direction. The spec called for fifteen generations in separate passes, none able to see another's output, never reconciled [15]. He got exactly that. All fifteen argued the same side, twelve of them used the phrase "a 2024 municipal broadband study" verbatim, which is 80 percent [16][17], and a twelve-word clause about a service appointment appeared word for word in the two essays meant to be the most stylistically distant [16]. A mechanism named after the property you want does not automatically deliver that property: fifteen passes run separately are not fifteen separate writers, and a collection scoped under one shared credential is not a separate trust domain.
One question the post leaves open decides whether the split transfers to your system: which principal is allowed to write the grades database. Every pipeline service account is denied [6]. Something has to be permitted, and by the rule that started this, that credential's reach is the grades database entire. Note also the provenance before you plan capacity around it. This is one developer's report from a hackathon build [1], not a docs citation, and it is the sort of claim worth reproducing against your own project.
Ranked by verification strength, evidence, and original report placement.
A developer, Jeremiah Sakuda, writing on dev.to, built an agent that reads student essays and prepares everything an instructor needs to grade them but cannot itself grade, as an entry for the All Things Agentic Hackathon.
The first version of the design placed grades in a separate Firestore collection rather than a separate database.
A reviewer caught the collection-scoping problem, and the author calls it the single most useful piece of feedback he received.
The fix was a second named Firestore database with the IAM binding conditioned on the resource path.
Grades live in a separate Firestore database that every pipeline service account is denied write access to.
There is no field on any record in the system that could hold a grade, and the schema rejects fields it does not recognise.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
A hackathon agent refuses to tick a form item until the question is actually answered1 distinct publisher
build
CrisisMesh paged its floor warden about the same missing teacher every 25 seconds1 distinct publisher
build
Giving one deterministic layer the only write privilege demotes the model to a proposer1 distinct publisher
build
Before you spend quota on an agent skill, make it pass an eval harness1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One builder's own account, nothing beside it
Every fact in this story comes from Jeremiah Sakuda's write-up on dev.to. The internal detail is the kind nobody invents — page number 41 anchoring five essays, a pool of ten fabricated surnames, a twelve-word clause about a service appointment surfacing in the two essays meant to be furthest apart. But the two claims another engineer would actually act on rest on assertion alone: no Google reference for the database-level permission floor, no catalogue listing for which Gemini models exist, no rulebook for the 3.5-or-newer bar, and no repository to open.
A submission, not a deployment
The user base is the author and the corpus is fifteen essays the system wrote for itself. It did run end to end — that is how the marker mismatch surfaced — and blind reviewers looked at the essays twice, but no instructor grades real work with this, and dev.to carries a contest entry rather than a shipping announcement.
Sells the failures harder than the wins
The headline is what the agent cannot do, four of five sections are things that broke, and the author volunteers that only one of his four fixes is held by the platform while the rest depend on his code being right. Even the sameness he could not remove is left sitting in the repository. What overreaches is quieter and structural: a general rule about a cloud database's permission model, drawn from one build, vouched for by nobody but the builder.
A contest entry that says so in line one
The first sentence names the motive: judging for the All Things Agentic Hackathon. That shapes the emphasis — the mandatory version bar, the architectural discipline, the reviewer catch — and it means the confessional structure is itself part of the pitch. dev.to prints what authors submit, so no editor stands between claim and reader, and the reviewers whose findings anchor two of the four lessons sit inside the author's own loop.
Trust the debugging, verify the platform
The bug stories hold together the way accounts do when someone actually chased them, and the arithmetic survives checking — twelve of fifteen is 80 percent of the set. What we cannot stand behind is everything that generalises: Firestore's permission floor, which Gemini models exist this month, what the contest required. Each needs a second source and has none.