Most AI agent stacks share a single database connection with broad privileges, which means every agent can read everything. Effective database access control for LLM agents requires least-privilege, per-agent permissions — the same role-based access control (RBAC) principles you already apply to human users.
Issue each agent its own credential instead of a shared secret. QueryShield hands out per-agent API keys so you can grant, rotate, and revoke access for one agent without touching the others, and every audit-log entry ties a query back to a specific agent.
Role-based table grants are coarse. Row-level security (RLS) lets you say “this agent may read orders for tenant A only.” QueryShield applies a per-agent RLS policy to every validated query before it executes, so scope is enforced deterministically outside the LLM — even if a prompt injection tries to widen it.
Classic RBAC assumes a principal with a fixed intent. An agent is different: it is handed a high-level goal and improvises the path to it, so a role that permits every individual step also permits chains of steps nobody anticipated. An agent allowed to read users and read invoices can join them into a customer list that neither grant contemplated on its own.
That is why role grants have to be paired with enforcement on the query itself. QueryShield evaluates each generated statement against the agent’s policy at execution time — the AST is checked, the RLS predicate is applied, and the mandatory LIMIT caps the result — so widening the scope requires changing the policy, not just chaining permitted calls.
Combine scoped keys and RLS with SELECT-only AST validation and an append-only audit log. The result is that an agent’s blast radius is bounded by its permissions, and you can prove exactly which rows each agent touched.
A secure SQL proxy for AI agents: natural language in, SELECT-only validated SQL out, per-agent row-level security, and an append-only audit log. Your agents never see connection strings.