Every time a new tool asks to connect to your production database, someone asks the same question: "What permissions does it need?"
Most teams answer that question wrong. Not maliciously — just by default. It's faster to hand over a role with broad access than to figure out the minimum the tool actually needs. And most of the time, nothing bad happens. Until it does.
TL;DR
Read-only access isn't a compliance checkbox — it's the single control that determines what a compromised credential, a buggy script, or a careless third-party tool can actually do to your data. 1DataCloud is built around this: every cloud connection and every query Query1AI generates is read-only by design. Try it free →
The Default Nobody Questions
Ask most engineers why a monitoring dashboard, a BI tool, or an internal script has write access to a production database, and the honest answer is usually: "It doesn't need it, but that's the role that already existed" or "it was easier to reuse the app's credentials than to create a new scoped one."
This is how a Grafana data source ends up with INSERT/UPDATE privileges it will never use. It's how a one-off migration script's credentials get copied into a cron job that runs forever. It's how a third-party analytics tool that only ever runs SELECT statements gets provisioned with a role that could also DROP TABLE.
None of this is intentional. It's just friction avoidance — and it quietly expands the blast radius of every tool you connect.
What Actually Goes Wrong
The failure mode isn't usually "the tool itself turns malicious." It's almost always one of these:
A compromised credential. A laptop gets phished, a .env file ends up in a public repo, an API key leaks in a log line. If that credential is read-only, the damage is exposure — bad, but bounded. If it can write, the damage is exposure plus whatever the attacker decides to do with UPDATE and DELETE.
A bug, not an attacker. A script with a typo in a WHERE clause. A migration that runs twice. A retry loop that resubmits the same write a thousand times. These happen to well-intentioned engineers constantly. Read-only access turns "we corrupted a table" into "the query errored out and nothing happened."
Scope creep over time. A tool that was granted broad access for a one-time task keeps that access indefinitely, because nobody remembers to revoke it. Eighteen months later, nobody on the team can explain why an old reporting service can still write to the orders table.
In all three cases, the fix isn't better intentions. It's not having write access to lose in the first place.
Why "Read-Only" Needs a Precise Definition
Here's where it gets more specific than most teams treat it: read-only isn't just "we told the tool not to write." It has to be enforced at the credential level, not the application level.
An IAM role scoped to rds:DescribeDBInstances, rds:DescribeDBClusters, and similar Describe*/List* actions physically cannot modify anything — there's no write API call available to the credential, regardless of what the connected tool tries to do. That's a different guarantee than "the tool's UI doesn't expose a write button," which depends entirely on the tool never having a bug, never getting compromised, and never adding a feature that assumes broader access than it was actually granted.
The same logic applies one layer down, at the database itself. A connection that only ever executes SELECT statements — with no INSERT, UPDATE, DELETE, or DDL capability at the database user level — means a bug in the querying layer can produce a wrong answer, not a corrupted table.
This is the distinction that matters: read-only as a database-and-cloud-level guarantee, not read-only as an application convention.
Where This Shows Up in Practice
This is exactly the model behind how 1DataCloud connects to your infrastructure.
Cloud connections are scoped to read-only API calls. Connecting an AWS account, a GCP project, or a MongoDB Atlas organization only ever requires read/describe-level permissions — the equivalent of rds:DescribeDBInstances, cloudsql.instances.list, and their Atlas/GCP counterparts. 1DataCloud never writes to your cloud resources. There's no code path that could, because the credentials it asks for don't have write scope to begin with.
Query1AI only ever generates and executes read-only SQL. It reads the schema metadata the dashboard already mapped — table names, column names, types, relationships — and turns a plain-English question into a SELECT statement, which then runs against your database. There's no mechanism for it to modify data, because the mechanism is schema-aware SQL generation, not an agent with arbitrary database access.
Neither of these is a feature you have to turn on. It's the only mode either capability operates in.
A Simple Test for Any Tool You Connect
Next time something asks for database or cloud credentials, ask three questions before granting access:
- Does this tool need to write anything, ever? If the answer is no — and for dashboards, BI tools, inventory tools, and most internal scripts, it usually is no — scope the credential to read-only at the IAM/database level, not just the application config.
- If this credential leaked tomorrow, what's the actual damage? If the honest answer includes "someone could modify or delete production data," the credential is scoped wider than it needs to be.
- Who's reviewing this access in six months? Broad credentials that were fine at setup time tend to outlive the reason they were granted. Read-only access doesn't eliminate this problem, but it drastically lowers the cost of forgetting.
None of this requires new tooling. It requires treating "read-only" as a specific, enforceable guarantee rather than a general intention.
Try It
If you're evaluating any tool for connecting to production databases — including 1DataCloud — read-only shouldn't be a claim you take on faith. Ask what API permissions it actually requests, and check whether those permissions could write even if the tool never intended to use them.
1DataCloud is free to start — connect up to 3 instances across AWS, GCP, or MongoDB Atlas, no credit card required.
How does your team scope credentials for internal tools today — least-privilege from day one, or cleanup after the fact? Curious how common the "reused the app's role" pattern actually is.
Top comments (0)