Seguridad de agentes de AI: permisos, sandboxes y aprobaciones

Traducción automática

Este artículo se tradujo automáticamente a partir de la versión original en inglés.

La seguridad de los agentes de AI controla qué puede leer, cambiar y enviar la aplicación. Un agente que utiliza herramientas puede procesar datos privados, usar credenciales y modificar sistemas externos. Sus acciones permitidas necesitan comprobaciones en el código, aunque la respuesta del modelo parezca segura.

Expón solo las herramientas que necesita la tarea. Comprueba los permisos antes de cada tool call, aísla la ejecución, limita las credenciales y registra el resultado. Exige aprobación para las acciones de alto impacto. Los filtros de texto pueden ayudar a detectar contenido inseguro, pero no pueden sustituir esos controles.

Esta lista de comprobación presupone que el agente lee entradas no fiables y puede acceder a datos privados o modificar sistemas externos. Una prompt injection es una instrucción en esas entradas que intenta redirigir al agente. Por ejemplo, un documento recuperado puede indicarle que suba archivos privados. Restringir las herramientas y las solicitudes salientes limita lo que puede causar esa instrucción.

Controles por capacidad

CapacidadControlQué exigir
Cualquier uso de herramientasMínimo privilegioExpón solo las herramientas necesarias, como recomiendan las directrices de OWASP para MCP.
Lectura de datos privados o cambios externosComprobaciones de permisosComprueba el usuario, los argumentos, el destino y la acción permitida justo antes de la ejecución.
Código, archivos o automatización del navegadorSandboxLimita los archivos, procesos y estados del navegador accesibles, y los destinos de salida.
Acciones de alto impactoAprobación humanaMuestra el destino exacto y el cambio antes de un despliegue en producción, un pago, una eliminación o un envío externo.
Servicios autenticadosCredenciales con alcance limitadoRestringe cada integración a los recursos y las acciones necesarios.
Servidores MCP no fiablesAislamiento de servidoresRevisa las definiciones de las herramientas e impide que las instrucciones devueltas por un servidor concedan acceso a otra herramienta.
Ejecución de herramientasTrazas de auditoríaRegistra la identidad, el destino, la decisión sobre permisos, la aprobación y el resultado; oculta los datos privados de las cargas.
Procesamiento de entradas y salidasGuardrailsComprueba la cobertura de cada herramienta. Un filtro de texto no concede permisos ni revierte una acción completada.
Pruebas de versiones y regresiónPruebas de ataquesPrueba prompt injection, definiciones de herramientas engañosas, divulgación de datos privados y elusión de permisos.

Qué implementar primero

Elimina primero las capacidades innecesarias. Si el agente no necesita escribir en GitHub, no le des un token de escritura. Si solo necesita consultar la disponibilidad del calendario, no le concedas acceso completo al buzón.

Después, comprueba la política antes de cada tool call. Inspecciona el nombre de la herramienta, los argumentos, el recurso de destino, el usuario, el entorno y el efecto secundario. Una solicitud aparentemente inocua puede generar un comando de shell peligroso.

Añade sandboxes para la ejecución de código, la automatización del navegador, el acceso a archivos y el procesamiento de documentos no fiables. Un sandbox no hace que la acción sea correcta, pero reduce los daños provocados por un tool result comprometido o por un modelo confundido.

Controla tanto el flujo de datos como la ejecución. Restringe los destinos de red salientes, oculta los secretos en los tool results, separa el contenido no fiable de las credenciales y registra los intentos de salida. Un sandbox del sistema de archivos que siga permitiendo acceso arbitrario a la red deja una vía directa de exfiltración.

Usa aprobación humana para las acciones irreversibles. No apruebes cada paso. Aprueba acciones específicas de alto impacto: despliegues en producción, eliminación de datos, envíos de correo electrónico, transferencias de dinero, cambios de permisos y decisiones reguladas.

Riesgos específicos de MCP

MCP es útil porque estandariza el acceso a herramientas. Es arriesgado porque las descripciones de las herramientas, los esquemas, las identidades de los servidores, los alcances de OAuth y las salidas de las herramientas pasan a formar parte del contexto de decisión del modelo.

Para MCP, mantendría estas reglas en la revisión de código:

  • revisa las descripciones y los esquemas de las herramientas antes de aprobarlas
  • prioriza credenciales acotadas por servidor
  • aísla los servidores MCP no fiables de las herramientas sensibles
  • vigila los cambios en las definiciones de las herramientas después de la instalación
  • trata las salidas de las herramientas como entradas no fiables
  • registra las identidades de los servidores y las herramientas, las decisiones de las políticas y los resultados; minimiza los argumentos y resultados y oculta sus datos sensibles antes de guardarlos

Los guardrails no bastan

Los guardrails pueden comprobar texto y tool calls. En el OpenAI Agents SDK, los guardrails de entrada de las herramientas pueden bloquear una herramienta de función protegida antes de que se ejecute. Las herramientas alojadas y las herramientas de ejecución integradas no utilizan ese mismo pipeline, por lo que debes comprobar la cobertura de cada herramienta que expongas. Las comprobaciones de salida se realizan después de la ejecución y no pueden deshacer un efecto secundario.

Aplica los permisos antes de la ejecución, junto con las comprobaciones de guardrails que correspondan. Mantén las credenciales acotadas y aísla las herramientas incluso cuando sus entradas superen la validación.

Sigue las directrices de OWASP sobre registro de eventos: excluye los secretos y los datos personales innecesarios de las trazas. Restringe quién puede leer los registros y establece un periodo de retención. Un registro de auditoría debe ayudar a reconstruir una acción sin copiar todas las cargas privadas.

Lecturas para profundizar

Referencias