Nothing in either setup asks you to decide. From the developer's chair the two are indistinguishable: you type a question, SQL comes back [10]. The divergence is in who knows the password [12], and that question never surfaces in the workflow that creates it.
Count the credentials. The direct path starts with one long-lived string containing the database password [2]. Do the responsible thing and add a dedicated read-only role, and you have created a second one, since the role needs its own login password [8]. So the hardened version of the direct path puts two static secrets into circulation, while the brokered client holds a token and no database credential at all [2]. The mitigation increased the secret count.
Rotation is where that bill arrives. The source names four resting places for a leaked string: a config file, an environment variable, a chat log, and a prompt window stored on somebody else's server [c4b]. Once it leaks, an attacker has privileged, unauthenticated access, and rotating means finding every copy [4]. That is four searches against one token revocation when a laptop goes missing or someone leaves [5], and the four are the ones you know about [1].
The hallucinated `DELETE FROM users` example [7] is not really an argument about how often models are wrong. It is an argument about what the wrong answer can reach. A read-only broker rejects writes and DDL because they are not in the allowed set [7]; a read-only role achieves the same thing as long as nobody hands the assistant the read-write credential instead [9]. One of those guarantees is structural, the other is a thing to remember [9].
Worth noticing that the source's own recipe argues against its own warning. The snippet ends with `ALTER DEFAULT PRIVILEGES`, and the comment beside it still says to re-grant for every new table, forever [8]. Both cannot be the operative instruction. A posture whose correctness depends on reading a code comment the right way is precisely the accident the piece is describing.
None of this makes the broker a safe place by default. Aggregating access creates a target that can expose everything behind it, which is why least-privilege roles, short-lived tokens and audit logging are named as load-bearing rather than optional [6]. The trade is a distributed leak surface for a concentrated one you actually operate. That is the same reasoning behind putting an API in front of a database rather than letting every client dial in [11], so most teams have already accepted it once, for clients they trusted less than they trust their own agents.
