Read-Only Isn't Enough: Guardrails for AI Agents
Senior engineers often say one thing to keep AI agents safe: give them read-only access.
It sounds safe. The agent can investigate slow queries or summarize schemas without breaking anything.
But read-only is not a safety model. It is a limitation.
The moment your agent needs to do useful work, read-only stops it. If an agent finds a bad index or a corrupted row, it cannot fix it. You end up with an assistant that points at a fire but cannot pick up a hose.
Teams often give up and hand the agent write access. That is when the real danger starts.
The real question is not "should the agent write." The real question is "how do you govern those writes."
Do not try to govern writes with instructions. Do not put rules in the system prompt like "never drop a table."
Prompt injection makes these rules useless. An attacker can use a row of data or a comment to trick the agent into ignoring your rules. If the guardrail lives in the same window as the agent, the agent can argue its way around it.
You need a distinction between ungoverned writes and mediated writes.
• Ungoverned writes: The agent decides to run a command, and the database executes it. The only control is the agent's own judgment. • Mediated writes: The command passes through a checkpoint outside the agent. This checkpoint sits in the data path between the agent and the database.
A mediated write works like this:
- The agent proposes a statement.
- A proxy or control plane parses the statement.
- The proxy classifies the risk.
- The proxy decides whether to allow it or ask a human for approval.
This approach protects you from prompt injection. A malicious instruction might trick the agent into writing a DROP TABLE command, but it cannot trick the proxy. The proxy does not read the agent's intent; it only looks at the actual SQL command.
Use this structure to stay safe:
- Auto-allow safe reads. Let agents run SELECT queries freely to keep work fast.
- Gate risky writes. Require human approval for DELETE, UPDATE, or schema changes.
- Log everything. Keep an immutable record of who proposed a change and who approved it.
Do not rely on read replicas for safety. Replicas help with investigation, but they cannot apply fixes. To fix a production issue, you must write to the primary database.
Mediation allows the agent to be useful while keeping your data safe.
Optional learning community: https://t.me/GyaanSetuAi