Aislar el acceso de un agente de IA a Postgres de los archivos del host

En modo restringido, la herramienta ejecuta una llamada en la cláusula FROM a pg_read_file('/etc/passwd') y devuelve el archivo, pero sigue bloqueando la misma función cuando se invoca directamente. La brecha es un problema de cobertura del parser. Para un operador, se trata de un fallo en el límite del host, no de un bug exclusivo de la base de datos.

Un informe de Synvestable de 2026 sitúa el ecosistema MCP en 97 millones de descargas mensuales del SDK, más de 10.000 servidores públicos activos y un 28 por ciento de las empresas Fortune 500 ejecutando servidores MCP en producción. Esa escala convierte a una herramienta de base de datos en una exposición seria. El informe describe un entorno de producción, no un laboratorio. Un agente con acceso a la base de datos puede convertirse en una vía hacia los archivos del host si el sandbox es débil.

El bypass convierte una consulta en una lectura de archivo

La vulnerabilidad de Postgres MCP Pro se rastrea como CVE-2026-85620 y tiene una puntuación CVSS v4.0 de 9.2. George Chen la reportó el 6 de junio de 2026. La capa safe_sql.py omite las funciones en la cláusula FROM porque su verificación de lista de permisos se aplica solo a nodos FuncCall del AST, no a nodos RangeFunction.

Con la vulnerabilidad, un atacante puede extraer archivos a los que el servidor de base de datos tiene acceso, como datos de configuración, credenciales y claves TLS, extendiendo el acceso desde la base de datos al sistema de archivos del host. En el momento de la publicación, no se había publicado ninguna versión corregida posterior a la versión 0.3.0, y una corrección estaba en revisión como una pull request abierta en el repositorio crystaldba/postgres-mcp. Si estás ejecutando ese paquete, verifica el parche y el comportamiento del parser antes de confiar en el control y documenta el resultado. Considera el control como no verificado hasta que confirmes ambos.

Cinco controles cierran la brecha

Empieza por el rol, luego ajusta el parser, aísla el proceso y audita la salida. El orden importa porque cada control cubre una ruta de escape diferente. Trata al agente como no confiable dentro de la base de datos. El rol establece el límite. El parser lo estrecha. El límite del host lo cierra. La auditoría de salida es el registro que muestra qué control falló. El registro también le da a la siguiente auditoría un punto de partida.

• Crea un rol de base de datos de mínimo privilegio para el agente. Concede solo las tablas, esquemas y operaciones que el agente necesita. El estado final es un rol que no puede leer catálogos del sistema, crear objetos ni invocar funciones administrativas.
• Elimina las funciones de archivo y superusuario de la superficie alcanzable del agente. Revoca la ejecución sobre funciones de archivo y cualquier otra función que toque el sistema de archivos. El estado final es una consulta que nombra una función de archivo y devuelve un error de permisos, no un conjunto de resultados.
• Impón una lista de permisos a nivel de parser, no un filtro de cadenas. Tu parser debe rechazar funciones desconocidas dondequiera que aparezcan, incluidas funciones de tabla, subconsultas y llamadas que devuelven conjuntos. El estado final es una lectura de archivo que falla antes de llegar a la base de datos.
• Aísla el proceso de base de datos del host. Ejecuta la instancia de base de datos orientada al agente en un contenedor, una VM o un host dedicado con un sistema de archivos mínimo, sin secretos montados y sin credenciales fuera de la base de datos. El estado final es un proceso que no puede ver archivos del host incluso si se ejecuta una función de archivo.
• Audita la salida y los registros de consultas. Captura cada instrucción que envía el agente, cada función que invoca y cada ruta de red a la que el proceso de base de datos puede llegar. El estado final es una alerta cuando una función de archivo, una conexión saliente o una exportación de datos aparece en el registro.

La verificación es parte del sandbox

Pasa el sandbox por una revisión de red team. Pide al agente que lea un archivo, liste un directorio, copie datos hacia fuera e invoque una función que no debería tener. La prueba debe fallar en el rol, el parser o el límite del host. Si tiene éxito, el sandbox no está terminado. Guarda los resultados de la prueba junto al registro de despliegue. Trata los resultados como evidencia, no como una casilla por marcar. Manténlos actualizados. Si una nueva herramienta o una nueva concesión de base de datos cambia la superficie, vuelve a ejecutar las mismas comprobaciones.