Require Human Approval Before an AI Agent Runs Ad Hoc SQL on Customer Data

Why approval belongs at the tool-call boundary

An agent with database access can write SQL from natural-language input and run it. Guidance from NIST on agentic security describes this as a risk: agents produce scripts or actions from prompts and may execute them without strong validation, and untrusted inputs or poisoned context can lead an agent to generate harmful commands. When the target tables hold customer data, one generated query can be consequential.

Each common control has a limit. Prompt instructions tell the agent what it should do, but the same NIST material advises not to trust prompt instructions, metadata, or artefacts from users or other agents. Database role permissions bound what the agent's credentials can reach, but they cannot distinguish a routine lookup from an unusual export when both fall inside the granted role. Reviewing query logs afterward gives you a record, but the query has already run. Telemetry is still necessary, since NIST advises against running agents without it, yet it is a different control from approval.

The workable pattern is to treat approval as a runtime enforcement decision. The gate acts on the individual tool call, before execution, and it works alongside least privilege and scoped tools rather than replacing them. A January 2026 federal request for information lists human oversight controls, such as approvals for consequential actions, among the controls organizations are considering for agents. It is a request for comment, not a requirement, but it supports aiming approval at consequential actions instead of every query.

Classify SQL tool calls and write the policy conditions

Start by separating routine patterns from ad hoc SQL. A routine pattern is a parameterized, pre-approved query template the agent fills with values. Ad hoc SQL is a free-form statement the agent composed. Matching an approved template should allow the call without human involvement, which keeps the gate from blocking normal work.

For everything else, evaluate conditions that can be read from the tool call itself. These attributes are design judgment and should be tuned to your data model: statement type (SELECT versus INSERT, UPDATE, DELETE, or DDL), target tables, the sensitivity classification of those tables and columns, query origin (which agent, which user request, whether the context included untrusted input), and scope, such as the absence of a row limit or filter.

A reasonable starting policy maps these conditions to four outcomes.

• Allow: Approved templates, or read-only statements on non-sensitive tables within a bounded scope.
• Redact: Reads that touch sensitive columns where the agent does not need raw values; mask the fields in the result.
• Block: Statements that should never run from an agent, such as schema changes or deletes on customer tables.
• Escalate: Ad hoc reads or writes on customer data that are legitimate in some cases but consequential, such as unbounded selects or any write.

Design the approver experience and fail-closed behavior

An approval is only as good as the information in front of the approver. Show the exact SQL as it would execute, not a summary written by the agent. Add the target tables and the sensitivity of the data, the statement type, the estimated scope where it can be determined, the originating agent, the user request or task that led to the call, and the policy condition that triggered escalation. Approvers who see only a natural-language description cannot catch a mismatch between what was asked and what was written.

Define who may approve. NIST AI RMF 1.0 calls for human roles and responsibilities in overseeing AI systems to be clearly defined and differentiated, and the Generative AI Profile includes documenting oversight roles. In practice that means a named approver group per data domain, authentication of the approver's identity, and a rule against self-approval by the person who triggered the request.

Then specify every outcome. On approval, execute exactly the statement that was reviewed; if the agent changes the SQL, it is a new request. On denial, return a clear refusal to the agent so it does not retry in a modified form without a new decision. On timeout, deny. If no approver is available, deny or queue to a secondary approver group, but never execute by default. A gate that fails open under load or outage is not an enforcement control.

Evidence and governance

Each escalation should produce one durable record linking four things: what was requested, who decided and when, the decision and any stated reason, and what ran, including the executed statement and its outcome. Include allow, redact, and block decisions as well, so the record shows the policy operating on routine traffic and not only on exceptions. The NIST Generative AI Profile includes monitoring and documenting instances where human operators override a system's decisions, and that practice maps directly to approver decisions. Retention and access to these records should follow your own policy.

Confirm which data-protection obligations apply to the tables in scope. For example, 16 CFR Part 314, which implements parts of the Gramm-Leach-Bliley Act, sets standards for reasonable administrative, technical, and physical safeguards for customer information. As of November 2026, whether it applies depends on whether you hold customer information it covers. NIST AI RMF material is general oversight guidance and does not prescribe an approval gate for SQL.

Trussed enforces policy in the execution path at the level of individual interactions and tool calls, with allow, redact, block, and escalate for human approval, and it generates audit-ready evidence from that enforcement. It is one way to implement the pattern described here; the design decisions above apply regardless of tooling.