Agentes SQL: cómo consultar datos con IA sin dar acceso peligroso a tu base de datos

Un agente SQL no debe recibir una cadena de conexión, un usuario con permisos amplios ni la autoridad de inventar su propio alcance. Un LLM traduce una intención —por ejemplo, «compara ingresos por región este trimestre»— a una propuesta estructurada; el runtime decide si esa propuesta cabe en el contrato; y la base de datos vuelve a aplicar identidad, rol, allowlist, coste y RLS.

Esto también reduce prompt injection. La pregunta y los comentarios de una columna son datos no confiables; no pueden cambiar tenant, rol o política. La [guía de prompt injection en agentes](/prompt-injection-agentes-ia-seguridad-evals/) explica la frontera general: las instrucciones recuperadas o introducidas por el usuario nunca deben convertirse en permisos.

Arquitectura de tres capas

Capa 1 — intención. El adaptador recibe el texto y el contexto autenticado. Devuelve un objeto tipado con métrica, dimensiones, periodo, filtros declarados y nivel de precisión. Rechaza peticiones ambiguas que podrían revelar datos personales y pide aclaración. El tenant, el usuario y la región no salen del prompt: se inyectan desde la sesión validada.

Capa 2 — plan permitido. Un planner genera una consulta lógica sobre un catálogo pequeño de vistas analíticas, no sobre todas las tablas. Un validador comprueba que cada relación, columna, función y ordenación esté en la allowlist; que no existan INSERT, UPDATE, DELETE, DDL, subconsultas inesperadas ni acceso a funciones peligrosas; y que el coste estimado y la cardinalidad máxima sean aceptables. Si el plan no se puede demostrar, se rechaza o pasa a revisión.

Capa 3 — ejecutor. El servicio obtiene la identidad real del usuario, fija `app.tenant_id` en la conexión, usa un rol de solo lectura, prepara la consulta con parámetros y aplica `statement_timeout`, límite de filas y cancelación. El resultado se serializa con un esquema conocido y se registra con un hash de la consulta, política, duración, filas y decisión. La respuesta del modelo se construye a partir de ese resultado, no de una ejecución que el modelo pueda repetir libremente.

<figure style="margin:34px 0;font-family:system-ui,sans-serif;"><img src="https://devaisemanal.com/content/images/2026/09/architecture-8.png" alt="Arquitectura de tres capas para agentes SQL: intención, plan permitido y ejecutor con identidad, allowlist, RLS, timeout, límites y aprobación de mutaciones" style="width:100%;height:auto;border-radius:12px;border:1px solid #dbe3ef;background:#f8fafc;" /><figcaption style="font-size:14px;color:#64748b;margin-top:10px;line-height:1.5;">El LLM propone una intención y un plan; la identidad, la política y la base de datos deciden qué llega a ejecutarse. Las mutaciones salen por una rama separada con aprobación.</figcaption></figure>

from dataclasses import dataclass
import re

VIEWS = {"analytics_orders", "analytics_tickets"}
IDENT = re.compile(r"^[a-z_][a-z0-9_]*$")

@dataclass(frozen=True)
class Plan:
    view: str
    metric: str
    dimension: str
    tenant_id: str
    limit: int = 100
    timeout_ms: int = 1500

def build_read_only_sql(plan: Plan) -> tuple[str, tuple[object, ...]]:
    if plan.view not in VIEWS or not IDENT.fullmatch(plan.view):
        raise ValueError("vista no permitida")
    if plan.metric != "revenue" or plan.dimension != "region":
        raise ValueError("operación fuera del contrato")
    if not plan.tenant_id or plan.limit < 1 or plan.limit > 1000:
        raise ValueError("identidad o límite inválido")
    if plan.timeout_ms < 100 or plan.timeout_ms > 5000:
        raise ValueError("timeout fuera de política")
    sql = (
        "SELECT region, SUM(revenue) AS revenue "
        f"FROM {plan.view} "
        "WHERE tenant_id = %s "
        "GROUP BY region ORDER BY revenue DESC LIMIT %s"
    )
    return sql, (plan.tenant_id, plan.limit)

# tenant_id viene de la sesión autenticada, nunca del prompt del LLM.
plan = Plan("analytics_orders", "revenue", "region", tenant_id="t_42")
sql, params = build_read_only_sql(plan)
print(sql, params)

PostgreSQL: identidad, rol de solo lectura y RLS

En PostgreSQL crea un rol de aplicación sin privilegios de escritura y concédele acceso únicamente a las vistas analíticas. Revoca `CREATE` en schemas accesibles y evita que el usuario del agente pueda cambiar funciones, search_path o políticas. El pool de conexiones debe limpiar estado al devolver una conexión: un `tenant_id` heredado sería una fuga silenciosa.

Coste, límites y mutaciones

La seguridad también es disponibilidad. Define un máximo de filas, columnas, duración, memoria y llamadas por identidad. Configura `statement_timeout` y cancela la consulta al superar el presupuesto; PostgreSQL documenta este parámetro en su [configuración de cliente](https://www.postgresql.org/docs/current/runtime-config-client.html). Añade límites del gateway para que una persona no pueda abrir cientos de consultas caras en paralelo.

No devuelvas millones de filas para que otro modelo las resuma. Agrega en la base de datos, pagina con cursores controlados y redondea o suprime grupos pequeños si existe riesgo de reidentificación. Muestra al usuario cuándo una respuesta es aproximada, truncada o requiere exportación aprobada.

Las mutaciones son otro producto. No las escondas detrás de una herramienta `execute_sql`. Si el caso necesita crear un ticket o corregir un dato, expón una operación de dominio con argumentos tipados, validación, idempotencia, dry-run y aprobación humana. El principio de mínimo privilegio y la reducción de agencia excesiva son precisamente el foco de [OWASP LLM06](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/).

Microsoft describe un principio parecido para Copilot Agent Mode con SQL Server: el agente debería operar con least privilege y permisos alineados con el usuario, no con un acceso administrativo global. La implementación concreta cambia entre motores, pero la frontera es la misma: la herramienta propone; la identidad y el servidor autorizan.