Claix es la capa controlada de recuperación de datos y de seguridad para agentes de IA: se conecta a tu base relacional y permite que cada agente recupere solo las tablas y columnas que tú autorizas y ejecute solo las acciones permitidas según tus reglas y límites, sin mover tus datos. Disponible vía API REST, MCP y A2A.

Conecta cualquier base de datos SQL con un rol de solo lectura (Claix redacta un Data Map para que lo revises), define rutas y agentes con tus reglas (sin YAML ni código), escribe reglas de Guard en lenguaje natural para los cambios que un agente puede proponer, y llama a un endpoint para que tu agente obtenga respuestas tipadas en vivo y un veredicto antes de cualquier cambio, dentro del perímetro que fijaste.

¿Claix copia mis datos a un almacén vectorial?

No. Claix no copia tus datos ni construye un índice vectorial sobre ellos. Los agentes consultan tu base donde vive, dentro de las tablas y columnas que permites. Cada consulta se valida antes de ejecutarse y queda trazada después.

¿Claix escribe en mi base de datos?

No. Claix nunca escribe en tu base de datos. Retrieve se conecta con un rol de solo lectura. Cuando un agente propone un INSERT, UPDATE o DELETE, Claix Guard responde permitir o denegar, con el motivo, y tu código ejecuta. Cargar documentos en campos estructurados es un producto aparte, Claix Ingest, que usas solo si lo eliges.

¿Qué bases de datos admite Claix?

Cualquier base de datos SQL, incluidas Postgres, MySQL y MariaDB, y los entornos compatibles con Postgres como Supabase. Te conectas con un rol de solo lectura. Claix nunca ejecuta escrituras: Guard solo responde si un cambio propuesto está permitido, y tu código lo ejecuta.

¿Qué son las rutas y los agentes?

Una ruta es una capacidad de recuperación: las tablas y columnas permitidas más una guía breve con tus reglas y vocabulario. Un agente es la identidad que las usa: su propio endpoint, prompt de negocio, rutas asociadas y modo de respuesta (resultados en bruto o respuestas razonadas tipadas). Crea una ruta una vez y asígnala a tantos agentes como necesites.

¿Cómo llamo a un agente Retrieve?

Haz POST a /retrieve/{agent_name} con un body JSON de preguntas (cada una con format opcional: string, int, boolean, json o array:string). Recibes respuestas tipadas en orden y un log_id. El mismo agente está disponible por MCP (claix.retrieve.ask) y A2A.

¿Qué formatos de respuesta puedo pedir?

En modo razonada puedes pedir string, int, boolean, timestamp, timestamptz, date, json, array:string o array:int. Los valores tipados permiten ramificar por booleanos, usar números y listas directamente y evitar parsear texto libre.

¿Cómo funciona el precio?

Con la IA gestionada de Claix la tarifa es 0,10 € por pregunta. Con tu propia clave LLM (BYOK) de OpenAI, Google, Anthropic o xAI, la tarifa de Claix baja a 0,02 € por pregunta y pagas los tokens de tu proveedor. Con tu propia clave, los resultados dependen del modelo: pruébalo en el Sandbox antes de pasar a producción. Claix Guard cuesta 0,01 € por llamada: cada comprobación de un INSERT, UPDATE o DELETE. En esa comprobación no hay modelo ni IA gestionada.

¿Agentic RAG es lo mismo que vector RAG?

No. Están en ejes distintos. “Agentic” habla de quién dispara la recuperación (pipeline fijo vs agente que llama a una herramienta). “Vector” habla de cómo se emparejan resultados (embeddings). Un agente puede llamar a SQL, BM25 o embeddings; un pipeline fijo puede usar búsqueda híbrida. Para datos de negocio relacionales, los embeddings suelen ser el default equivocado.

¿La recuperación por SQL es RAG?

Sí. RAG significa que la información recuperada alimenta al modelo. No exige embeddings ni que lo recuperado sean trozos de texto. Una consulta SQL que devuelve registros en vivo para el modelo sigue siendo recuperación.

¿Cuándo sigue teniendo sentido una base vectorial?

Cuando necesitas descubrimiento semántico sobre una colección grande y permanente de texto, mucho tráfico de búsqueda repetido, o un producto donde la búsqueda es el producto. Para valores exactos, conteos, fechas y filas en vivo que ya están en tu base SQL, consulta la base donde vive con acceso acotado en lugar de copiarla a un índice.

¿Puedo usar Claix desde LangChain, Cursor o n8n?

Sí. Claix no es un framework de agentes: es una capa de recuperación que llamas desde el stack que ya usas. Llama por REST desde cualquier cliente HTTP (incluido n8n), expón el agente como herramienta MCP para Cursor y clientes compatibles, o conéctalo por A2A para que otros agentes deleguen preguntas de datos.

¿Qué pasa si la respuesta no está en las tablas permitidas?

El campo vuelve vacío en lugar de una invención. Las consultas solo se ejecutan dentro de las rutas que adjuntaste al agente; todo lo que queda fuera de ese perímetro no existe para ellos. Las trazas muestran qué se preguntó, qué ruta respondió y qué volvió.

¿En qué se diferencia Claix de un servidor MCP genérico sobre la base?

Conectar un MCP de base es rápido, pero el modelo de acceso depende del servidor y del rol. Claix añade rutas, allowlists por agente, validación antes de ejecutar, respuestas tipadas multi-pregunta, Claix Guard —que comprueba cada cambio propuesto contra reglas exactas antes de que tu código lo ejecute— y una traza revisable: defines el límite una vez y se aplica en cada llamada.

¿Necesito guardrails si ya uso Row Level Security?

Sí. RLS decide qué filas puede ver o modificar un rol, pero no controla qué tipo de acciones intenta un agente ni limita cuántas filas toca una operación. Son capas complementarias.

¿Sirve para cualquier modelo o agente?

Al aplicarse fuera del agente, las reglas no dependen del modelo que uses ni del framework con el que lo hayas construido.

¿Puedo empezar solo con lectura?

Sí, y es lo más recomendable: da acceso de lectura primero, observa qué consulta tu agente y añade permisos de escritura gradualmente.

¿Qué pasa cuando el agente intenta una acción bloqueada?

La acción no se ejecuta y queda registrada, de modo que puedes revisar qué intentó hacer y ajustar las reglas. Claix Guard responde permitir o denegar, con el motivo. Tu código es el que ejecuta la sentencia si la respuesta es permitir.

¿Tengo que saber SQL o escribir políticas complejas?

No. Con Claix Guard describes las reglas en lenguaje natural y revisas las reglas generadas antes de activarlas. En el momento del chequeo la decisión es exacta: ningún modelo decide permitir o denegar.

Ya tengo un agente en producción con acceso directo a la base de datos, ¿qué hago?

Primero reduce sus permisos al mínimo y retira credenciales con acceso de escritura que no necesite. Después coloca una capa de guardrails entre el agente y la base de datos, empezando por bloquear DELETE y limitar las filas afectadas.

Prueba Claix Guard

Volver al blog

Seguridad · GuardrailsNovember 6, 2026PorGael Anaya

Cómo evitar que un agente de IA borre tu base de datos: guía de guardrails y reglas (2026)

Un agente de IA puede borrar tu base aunque el prompt lo prohíba. Comprueba cada acción con guardrails externos antes de que llegue a la base de datos.

Claix · Actualizado noviembre 2026. Guías relacionadas: rol Postgres de solo lectura (/es/blog/read-only-postgres-role-for-ai-agents), consultas seguras (/es/blog/how-to-let-an-ai-agent-query-postgres-safely) y las seis formas de dar acceso seguro (/es/blog/best-way-give-ai-agents-safe-database-access). Producto: Claix Guard (https://www.claix.dev/es/guard).

¿Puede un agente de IA borrar de verdad una base de datos?

Sí, y ya ha pasado en producción. En abril de 2026, un agente de programación de Cursor que usaba Claude Opus 4.6 borró la base de datos de producción de la startup PocketOS y todos sus backups volumen a volumen con una sola llamada a la API de su proveedor de infraestructura, Railway. Según los informes, tardó nueve segundos y el agente ignoró las instrucciones que le prohibían ejecutar comandos destructivos. Los backups estaban dentro del mismo volumen que se borró, y el último respaldo externo tenía tres meses.

No es un caso aislado: antes hubo otros incidentes similares con agentes de programación que eliminaron bases de datos de producción. Y no se trata de un modelo concreto. El patrón se repite: un agente con permisos más amplios de los necesarios y sin una capa que valide sus acciones.

¿Por qué no basta con decirle al agente «no borres nada»?

Porque un prompt es una petición al modelo, no una restricción. Un modelo de lenguaje funciona de forma probabilística: puede razonar que una acción destructiva es la solución a un problema (por ejemplo, un error de credenciales) y ejecutarla igualmente.

La regla de seguridad es simple: el control tiene que estar fuera del modelo. Lo que el agente no debe poder hacer tiene que estar bloqueado aunque el agente decida intentarlo.

¿Es suficiente un usuario de base de datos de solo lectura?

Es un buen primer paso, pero no basta por sí solo. Un rol de solo lectura en PostgreSQL deja varias brechas abiertas:

Configuraciones de sesión que el propio rol puede cambiar. Parámetros como default_transaction_read_only pueden desactivarse desde la sesión; lo que de verdad bloquea una escritura son los permisos concedidos (GRANT), no ese ajuste.
Funciones SECURITY DEFINER. Se ejecutan con los privilegios de su propietario, y por defecto PostgreSQL permite ejecutar funciones a cualquiera, así que un rol sin acceso a una tabla puede acabar escribiendo en ella a través de una función.
Permisos demasiado amplios. Usar GRANT SELECT ON ALL TABLES expone tablas que no pensabas exponer. Es más seguro conceder acceso solo a tablas y columnas concretas.
Row Level Security (RLS). Con RLS activado y sin políticas, un rol no ve ninguna fila, así que hay que definir políticas explícitas por rol.
Todo lo que no es SQL. En el caso de PocketOS la acción destructiva no fue una consulta SQL, sino una llamada a la API de infraestructura con un token de permisos amplios. Un rol de base de datos no protege de eso.

¿Qué son los guardrails para agentes de IA que acceden a datos?

Un guardrail es una regla que se evalúa fuera del agente, antes de ejecutar la acción, y que permite o deniega. Un buen sistema de guardrails sigue tres principios:

Denegar por defecto. Lo que no está permitido explícitamente, no se ejecuta.
Aplicación determinista. La decisión de permitir o bloquear no la toma un modelo que pueda equivocarse o dejarse convencer.
Auditoría. Cada acción intentada, permitida o bloqueada, queda registrada.

Este enfoque ya lo adoptan plataformas de gran tamaño; por ejemplo, Amazon Bedrock AgentCore evalúa cada petición de un agente a una herramienta contra políticas definidas fuera del agente.

¿Cómo funciona Claix Guard?

Claix Guard es un servicio gestionado que se sitúa entre tus agentes de IA y tus bases de datos. Tú describes las reglas en lenguaje natural; Claix las convierte en reglas y límites exactos, y comprueba cada INSERT, UPDATE y DELETE antes de que tu código lo ejecute. La respuesta es permitir o denegar, con el motivo. La comprobación es determinista: ningún modelo decide en el momento del chequeo. Claix no ejecuta la sentencia ni toca tus datos. Claix también recupera información para los agentes de forma acotada. No tienes que montar ningún framework ni escribir un lenguaje de políticas.

Ejemplo de regla en lenguaje natural: «Los agentes pueden consultar pedidos y clientes, pero nunca ver emails ni teléfonos. Pueden cambiar el estado de un pedido, pero no borrar nada. Ninguna operación puede afectar a más de 10 filas.»

Ejemplo de cómo se traduce (ilustrativo)

Lo que escribes	Lo que se aplica
Pueden consultar pedidos y clientes	Lectura permitida solo en esas tablas
Nunca ver emails ni teléfonos	Columnas sensibles bloqueadas
Pueden cambiar el estado de un pedido	UPDATE permitido solo en el campo estado
No borrar nada	DELETE denegado
Máximo 10 filas	Límite de filas afectadas por operación

¿Qué reglas debería definir primero?

Separa lectura y escritura. Empieza con agentes de solo lectura y añade escritura solo donde haga falta.
Deniega por defecto DELETE, DROP y TRUNCATE.
Limita las filas afectadas por operación para evitar cambios masivos.
Oculta columnas sensibles: emails, teléfonos, documentos de identidad, tokens.
En operaciones destructivas o irreversibles, deniega y exige la aprobación humana en tu propio flujo (Slack, email, n8n). Guard responde permitir o denegar; no hay un tercer veredicto.
Usa credenciales distintas por entorno, para que un agente de pruebas no tenga acceso a producción.
Registra todo y revisa los intentos bloqueados: te dicen qué intenta hacer realmente tu agente.
Mantén backups fuera del alcance del agente, no en el mismo volumen.

Comparativa: ¿qué protege qué?

Medida	Evita borrados accidentales	Controla columnas y filas	No depende del modelo	Cubre acciones fuera de SQL
Instrucciones en el prompt	No fiable	No	No	No
Usuario de solo lectura	Sí, pero solo para escrituras SQL	Parcial	Sí	No
Row Level Security	No	Filas	Sí	No
Guardrails externos	Sí	Sí	Sí	Depende de dónde se apliquen

Las medidas se complementan: lo recomendable es combinar permisos mínimos en la base de datos con una capa de guardrails delante.

Preguntas frecuentes

¿Necesito guardrails si ya uso Row Level Security?: Sí. RLS decide qué filas puede ver o modificar un rol, pero no controla qué tipo de acciones intenta un agente ni limita cuántas filas toca una operación. Son capas complementarias.
¿Sirve para cualquier modelo o agente?: Al aplicarse fuera del agente, las reglas no dependen del modelo que uses ni del framework con el que lo hayas construido.
¿Puedo empezar solo con lectura?: Sí, y es lo más recomendable: da acceso de lectura primero, observa qué consulta tu agente y añade permisos de escritura gradualmente.
¿Qué pasa cuando el agente intenta una acción bloqueada?: La acción no se ejecuta y queda registrada, de modo que puedes revisar qué intentó hacer y ajustar las reglas. Claix Guard responde permitir o denegar, con el motivo. Tu código es el que ejecuta la sentencia si la respuesta es permitir.
¿Tengo que saber SQL o escribir políticas complejas?: No. Con Claix Guard describes las reglas en lenguaje natural y revisas las reglas generadas antes de activarlas. En el momento del chequeo la decisión es exacta: ningún modelo decide permitir o denegar.
Ya tengo un agente en producción con acceso directo a la base de datos, ¿qué hago?: Primero reduce sus permisos al mínimo y retira credenciales con acceso de escritura que no necesite. Después coloca una capa de guardrails entre el agente y la base de datos, empezando por bloquear DELETE y limitar las filas afectadas.

Conclusión

Dar acceso a una base de datos a un agente de IA es útil, pero las instrucciones en el prompt no son un control de seguridad. La combinación que funciona es permisos mínimos, reglas externas deterministas y registro de todo lo que el agente intenta. Con Claix Guard defines esas reglas en lenguaje natural y el servicio se encarga del resto. Prueba Claix Guard en https://www.claix.dev/es/guard.