How should security teams connect AI agents to SQL databases without exposing the database to the model?

Connect agents through least privilege enforced in the database, not through prompt instructions. Create purpose built roles, expose only required tables and columns, and use row level security to limit what each agent can see. Keep credentials outside the LLM context and pass them through a controlled tool layer so the model can request actions without ever handling secrets directly.

How to Keep the Model Away from the Database Itself

The cleanest pattern is to treat the agent as a requester, not as a database client. The model should ask for an action through a controlled tool layer, while the tool layer enforces the database session, role, and scope. That keeps secrets out of the prompt, prevents the model from seeing raw credentials, and lets the database enforce what the agent can actually do.

A practical architecture starts with purpose built database roles that expose only the tables, views, and columns the agent truly needs. If the use case is read only, make it read only. If the agent needs a narrow write path, separate that path from general access and keep it tightly scoped. The database, not the prompt, should define the boundary.

Row level security is the right control when the same table contains data for multiple tenants, accounts, or business units. It lets one agent query the table without getting everything in it. That matters because even a well behaved agent can overreach if the database response is too broad. For agent workflows that touch sensitive data, a safer pattern is to expose curated views instead of direct table access, then apply row level policy on top. AI Agent Authorisation Guide is a useful companion for this access model, and Zero Trust for AI Agents covers the same principle of verifying each request rather than trusting the agent context.

Why Prompt Instructions Are Not an Access Control

Prompting the model to “only use approved tables” is helpful for behavior, but it is not a security boundary. Agents can misinterpret instructions, chain tools in unexpected ways, or be induced to request data outside their intended scope. If the credential or connection string is in the model context, the model can also leak it, repeat it, or reuse it in an unsafe downstream action.

That is why the controlled tool layer matters. It becomes the policy enforcement point for authentication, authorization, logging, and secret handling. The model can request “get customer summary” or “update invoice status,” but the tool decides whether that request is valid, which database identity to use, and which SQL statements are allowed. Agentic AI Security Guide gives the broader control model for tools and identity, while AI Agent Observability, Audit and Incident Response Guide is the right companion when you want to make every agent action attributable.

Keep the database credential outside the LLM conversation entirely. The agent should never hold the secret directly, even temporarily in prompt text, memory, or chat history. If the credential is retrievable by the model, then any prompt injection, log exposure, or context leak can turn into database exposure. MCP Security Guide is relevant here because the same principle applies to tool-mediated access, where token passthrough and gateway design can either contain or widen the blast radius.

What Good Agent-to-SQL Boundaries Look Like in Practice

The best implementations separate planning from execution. The agent plans the task, but a backend service validates the request, maps it to an approved query pattern, and executes it under a scoped database role. That service should apply allowlists for tables, columns, and actions, and it should reject ad hoc SQL unless there is a very strong operational reason to permit it.

For write operations, require a tighter approval path than for reads. A safe default is read access through restricted views, then write access only for explicit workflows with fixed statements or parameterized commands. If the agent needs to work across tenants or business units, create separate roles or separate execution paths rather than one broad role with conditional logic. Separation is cleaner to audit and easier to revoke.

AI Coding Agents Security Guide reinforces the same operational lesson for secrets and over-scoped tokens, while AI Agent Observability, Audit and Incident Response Guide helps teams prove which action was requested, which query was executed, and whether the agent stayed inside its intended scope.

Risk and Threat Considerations

The main risk is not that the model “knows SQL,” but that it can become an overpowered intermediary if it is given direct database credentials, broad roles, or unrestricted query generation. In that failure mode, prompt injection, accidental misuse, or simple model error can turn into unauthorized data exposure or destructive database activity.

Failure mechanism: Excess privilege, secret exposure, and unconstrained query execution let the agent move from asking questions to exercising broad database authority, including across tenants or sensitive columns.

Impact: The result can be data leakage, unauthorized modification, broken tenant isolation, or destructive actions that are difficult to contain once the database session has been abused.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agent access to SQL must be tightly authorized to avoid privilege abuse.
Recommendation — Enforce per-action authorization and limit agent privileges to the minimum required.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Database-connected agents are non-human identities that must not receive broad access.
Recommendation — Scope each agent credential to the smallest set of tables, columns, and actions.
NIST SP 800-53 Rev 5	IA-9 — Service Identification and Authentication	Agents and tool services need controlled non-human authentication to reach databases safely.
	AC-6 — Least Privilege	Least privilege directly governs what a database-connected agent can query or change.
	AC-3 — Access Enforcement	Database and tool-layer enforcement are central to preventing unauthorized agent access.
Recommendation — Authenticate the agent through a controlled service layer rather than exposing database secrets. Assign database roles that expose only the minimum required data and commands. Enforce authorization in the database and tool layer, not in prompts.
NIST Zero Trust (SP 800-207)	SC.L2-3 — Least Privilege Access	Zero trust supports per-request verification and narrow agent access paths.
Recommendation — Verify each agent request and remove standing access wherever possible.
OWASP ASVS	V8 — Authorization	The boundary between agent intent and database access depends on strong authorization controls.
	V14 — Data Protection	Limiting exposed tables, columns, and row scope is a data protection requirement.
Recommendation — Validate that every database action is authorized for the calling workflow before execution. Restrict database responses to the minimum data needed for the agent's task.

Practitioner Guidance

What to prioritise: Design the database permission model first, then build the agent tool around it. If the role design is vague, the agent boundary will be vague too.

What to verify: Confirm that the model never sees database passwords, long-lived tokens, or connection strings, and that the backend can prove which role, query pattern, and row scope were used for each request.

Decision rule: If the agent needs raw SQL to function, treat that as a higher-risk design and constrain it with parameterization, allowlists, and separate credentials per environment or task.

Practitioner takeaway: The safest design is one where the model can request data, but only the control layer can obtain it, authorize it, and bound it.