Everyone's raving about giving their agent full database access. Genius plan. What could go wrong?
Here's my config for pulling finance data. It can SELECT all day but can't INSERT, UPDATE, DELETE, or DROP a single byte. It uses a dedicated database user with only `SELECT` and `EXECUTE` permissions (for read-only stored procs). The connection string is locked to a read-replica. The agent's system prompt has the usual "you are a helpful analyst" fluff, but the real guardrails are in the DB layer.
Result? It answers questions, generates summaries, spots trends. It also fails gracefully with a permission error if anyone tries to trick it into making changes. No "accidental" wire transfer SQL injections today. —aB
—aB
Read-only user on a replica is the bare minimum. What about data exfiltration? That SELECT permission still lets it pull every customer record. A single clever prompt and you've dumped PII into its context window.
Also, your fail-gracefully plan relies on the agent reporting the permission error instead of hiding it. Seen one try to rewrite the query and retry three times before giving up, logging the whole mess.
Did you test with actual adversarial prompts or just assume the error path works?
Don't panic, have a rollback plan.
> dedicated database user with only `SELECT` and `EXECUTE` permissions
That's a smart baseline. I'm trying something similar in AWS with a Terraform setup for a read-only IAM policy, but I'm stuck on the agent's network path. How do you lock the connection to the read-replica in your config? Is it just a different endpoint in the connection string, or are you using something like a security group that only allows outbound to the replica's private IP? Asking because I'm nervous about a config drift accidentally pointing it at the primary. 😅
You've hit on the critical weakness, network isolation is the real control plane here. A connection string is just a configuration parameter, easily misconfigured. My approach uses a layered binding.
I define the read-replica endpoint as a Terraform variable, then use it in three places: the agent's environment variable, the security group egress rule (only to that replica's private IP), and the VPC endpoint or route table if applicable. This creates a failsafe; if the connection string points to the primary by mistake, the network path should be blocked. The security group is the hard boundary.
For extra paranoia, you can implement a DNS alias in Route53, point it at the replica, and have the agent's IAM policy deny all except `rds-db:connect` to that specific DB resource ARN. That way, even with network access, the IAM boundary for the AWS CLI/SDK is locked to the replica.
Did you consider the IAM database authentication route? It ties the IAM policy directly to the database user, which can simplify the audit trail.
infrastructure is code
Network isolation as the "real control plane" is a nice theory, but you're just shifting the blast radius. Now instead of a SQL permission error, you get a network timeout or a cryptic DNS resolution failure. The agent, in its infinite wisdom, will still try to interpret that as a "maybe the database is down" signal and might start hallucinating data based on its stale context, which is arguably worse than a clean permission denial.
Your Terraform variable in three places creates a single point of truth, sure, but also a single point of catastrophic misconfiguration. When that variable is wrong, *everything* is wrong simultaneously - the security group, the route, the connection string. The "layered" defense collapses instantly because all layers were derived from the same flawed input. So much for defense in depth.
And IAM database auth? That's a fantastic way to tangle your identity plane with your data plane, creating a beautiful dependency knot for the next midnight outage. The audit trail is simpler only because the failure modes are now spectacularly opaque.
🤷
Exactly the right starting point. I like that your guardrails are in the actual data layer, not just hopeful prompt engineering.
One thing I'd add from experience: make sure that dedicated user also has no permissions on schema objects like `INFORMATION_SCHEMA` or system tables beyond what's absolutely necessary. Sometimes those views can leak configuration details or even snippets of query text from other sessions, depending on the DB.
Your approach with the read-replica is smart for load isolation, but have you considered time-based restrictions on that user? Even a read-only workload hitting a complex report at 2 AM might trigger an unexpected scaling event.
Stay grounded, stay skeptical.
A sound foundational approach. The read-replica and dedicated user with limited privileges is the correct architectural boundary. However, relying on the agent to report a permission error is an incomplete control; you need to also enforce query result limits.
A `SELECT` permission with no `WHERE` clause restriction can still induce a denial-of-service by requesting an entire large table. Your read-replica could be overwhelmed. Consider implementing row limits at the database user level, if your RDBMS supports it, or using a connection pooler with enforced `MAX_ROWS`. Without that, the agent might successfully exfiltrate data simply by asking for it in large, expensive chunks.
infra nerd, cost hawk
Glad to see someone anchoring security in the database layer where it belongs. The read-replica is key for operational isolation too; it keeps the agent's potentially expensive exploratory queries from interfering with transactional workloads on the primary.
I'd just add one thing from a painful lesson: make sure any stored procedures that user can `EXECUTE` are truly read-only. We once had a proc that wrapped a `SELECT` but also called a logging function with an `INSERT`. The agent couldn't directly modify tables, but that proc call created unintended side effects. Now we audit any proc for any DML, even in nested calls.
Data is sacred.