Seguridad y supervisiónActualizado 2026-08-25 · Versión 1.1

Lista de Salida Permitida

Restringe adónde puede ir el tráfico de un agente. El robo de datos y la entrega de un payload de inyección terminan ambos en una petición saliente, así que una lista de destinos permitidos con denegación por defecto es el control que sigue funcionando cuando todos los demás ya han fallado.

Evidencia: Observación del sectorConfianza: AltaFuente: Observación del sectorFuente: Experiencia personalFuente: Paper
Legible por máquina: JSON

Definición

Una lista de salida permitida es una política de red o de sandbox que solo autoriza las peticiones salientes del agente hacia un conjunto de destinos nombrados explícitamente y deniega todo lo demás por defecto, de modo que los datos no puedan salir hacia un endpoint elegido por el atacante ni siquiera con el agente completamente secuestrado.

Problema

Toda ruta de exfiltración termina en una petición saliente. Un agente que puede llegar a hosts arbitrarios puede recibir la instrucción de enviar todo lo que ha leído a cualquier dirección, y ninguna instrucción a nivel de prompt lo impide.

Cuándo usarlo

Úsala allí donde un agente procesa contenido no confiable y además puede hacer peticiones de red: descargar páginas, invocar herramientas, renderizar imágenes, ejecutar código generado. El patrón vale más justo donde la inyección es más probable.

Solución

Deniega por defecto. La lista es la única salida; lo que no esté nombrado se rechaza, y el rechazo se registra como señal en lugar de tragarse como error.

Enumera los destinos a partir de la tarea: las APIs que el agente debe llamar, los dominios que debe descargar, los registros de los que debe instalar, cada uno con responsable y motivo escrito.

Aplica la política por debajo del agente. Ponla en el sandbox, en el proxy o en la red, nunca en el código de la herramienta del que se puede convencer al modelo. Una regla que el agente puede sortear hablando es documentación, no un control.

Cierra los canales silenciosos. Las URLs de imágenes renderizadas, las previsualizaciones de enlaces, las resoluciones DNS, los webhooks, los reportes de error y las instalaciones de paquetes son todos salida, y todos se usan.

Permite hosts sobre los que puedas razonar. Un comodín sobre un host que sirve contenido de usuario —un CDN de ficheros crudos, un sitio de pastes, un almacén de objetos público— es un canal abierto disfrazado de lista de permitidos.

Deriva la lista de la medición y vuelve a derivarla cuando cambie la tarea. Parte de lo que el agente llama de verdad, no de lo que alguien supone que llama.

Componentes

Una pasarela de salida o política de red del sandbox que todo el tráfico deba atravesar.Una regla de denegación por defecto con un inventario de destinos explícito y con responsables.Políticas por rol, para que un agente de investigación y uno de despliegue no compartan una misma lista.Registro de denegaciones conectado a alertas, porque una denegación es un evento de alta señal.Restricciones de método y de payload donde el destino por sí solo no basta (solo GET, límites de tamaño de cuerpo).Una cadencia de revisión que retire los destinos que nadie ha usado.

Beneficios

  • Acota la exfiltración incluso tras un compromiso total del razonamiento del agente.
  • Hace visibles los intentos: un destino denegado es una de las pocas señales de ataque inequívocas que produce una pila agéntica.
  • Es independiente del modelo: sigue funcionando entre cambios de modelo, de prompt y de framework.
  • Es barata de extender una vez existe la pasarela; cada agente nuevo hereda el punto de aplicación.

Riesgos

  • El relé permitido: un host autorizado que a su vez reenvía los datos convierte la lista en un trámite.
  • Roturas cuando una dependencia legítima cambia de host, lo que genera presión para ampliar la lista con prisa.
  • Erosión por comodines: cada entrada amplia añadida «temporalmente» es permanente hasta que alguien la audita.
  • Aplicación en la capa equivocada: una comprobación en el propio proceso que el código generado simplemente esquiva.

Cuándo no usarlo

  • Agentes completamente sin red, donde no hay salida que acotar y el control sería teatro.
  • Cuando el diseño ya permite exactamente un destino, así que la lista es una propiedad de la arquitectura y no una política que añadir.
  • Cuando un proxy corporativo ya aplica la misma política y una segunda lista repartiría la responsabilidad sin añadir restricción.

Tecnologías

Egress proxiesContainer network policiesService mesh policyDNS filteringDenial logging and alerting

Ejemplos

  • Un agente de programación en un contenedor cuya política de salida nombra el registro de paquetes y el host Git interno, y nada más. Una instrucción inyectada para hacer POST del repositorio a un recolector externo falla en la capa de red y aparece como denegación.
  • Un agente de investigación con permiso para descargar ampliamente pero forzado a pasar por un proxy que solo permite GET y limita el tamaño de los cuerpos salientes: puede leer la web sin tener un canal para escribir en ella.
  • El paquete stdio publicado para esta base de conocimiento: su único destino saliente es el endpoint público del que hace de proxy, así que la lista de permitidos es una propiedad del diseño y no una política añadida después.

KPIs

Intentos de salida denegados
La señal que el patrón existe para producir. Una subida sostenida es un ataque o una tarea que se ha salido de su lista; conviene saber cuál.
Tamaño de la lista
Destinos permitidos por rol de agente. Crecer sin retirar es la lista degradándose hacia «permitir todo».
Entradas con comodín
Número de entradas amplias. Cada una es un canal sobre el que no puedes razonar; el objetivo es cero.
Tiempo de denegación a triaje
Cuánto espera una denegación antes de que alguien la mire. Una denegación sin leer es una alerta que en realidad no tienes.

Modos de fallo observados

  • El relé permitido: un host aprobado que reenvía lo que le den, así que la comprobación de destino pasa y los datos salen igual.
  • Erosión por comodines: entradas amplias temporales que sobreviven al motivo por el que se añadieron.
  • Aplicación en el propio proceso: la comprobación vive donde corre el código generado, así que el código puede saltársela.
  • Denegaciones silenciosas: rechazos registrados como errores de red corrientes, así que la única señal que genera el patrón no llega a nadie.

Lecciones aprendidas

  • La salida es el último control que sigue funcionando cuando ya han convencido al modelo. Constrúyelo antes de necesitarlo.
  • Deriva la lista de tráfico medido y no de suposiciones. Hacer exactamente eso para la regla de origen entrante de nuestro propio endpoint MCP produjo una regla distinta de la que habríamos escrito partiendo de un valor por defecto.
  • Trata una denegación como alerta, no como error. Es la señal de ataque más barata de toda la pila.
  • Cada comodín es una promesa que no puedes cumplir. Nombra hosts, o admite que no tienes una lista de permitidos.

FAQs

¿Es realista una lista de salida para un agente que navega por la web?
Sí, si acotas la forma en lugar del conjunto. Permite tráfico GET amplio a través de un proxy que prohíba cuerpos de petición y limite tamaños: el agente puede leer mucho sin tener un canal lo bastante ancho para sacar lo que ha leído.
¿Hay que incluir el DNS?
Sí. Un resolutor que el agente puede consultar libremente es un canal de exfiltración: los datos codificados en consultas de subdominio salen sin una sola petición HTTP. Enruta el DNS por la misma política.
Ya tenemos herramientas con mínimo privilegio, ¿esto es redundante?
No; cubren mitades distintas. El mínimo privilegio acota lo que el agente puede hacer; el control de salida acota adónde puede ir lo que ya leyó. Un agente de solo lectura con salida abierta puede filtrar todo lo que es capaz de leer.

Referencias