http_fetch, web_search o cualquier herramienta
que abre una conexión saliente, el destino es la parte que más necesitas
gobernar. Un agente confundido o secuestrado que puede alcanzar
169.254.169.254 lee tus credenciales de nube; uno que puede hacer POST a un
host atacante exfiltra tus datos. El control de egress de agentes gobierna
ese destino — autoras una regla de permitidos/denegados de host/CIDR en la
superficie egress del firewall, la adjuntas a una clave, y el gateway
verifica cada destino saliente que la herramienta de un agente reporta
antes de que la llamada salga.
Esta es una página de caso de uso enfocada. Para la gramática de reglas
completa y la semántica de veredictos ver
Esquema de regla y
Veredictos; para cómo se sitúa el egress
entre los otros puntos de aplicación ver
Etapas.
1. Control de egress de agentes en la superficie egress
De las cuatro superficies del firewall,egress es la que ve el destino de red saliente que una herramienta
reporta — un host, un literal de IP o un CIDR. Una regla fijada a
stage: egress coincide sobre ese destino, no sobre el nombre de la
herramienta ni sus argumentos, lo que la convierte en el control de SSRF y
exfiltración de datos: responde a dónde puede alcanzar este agente,
independiente de qué herramienta hizo el alcance.
El egress es acotamiento de destino, no bloqueo de herramienta. Para
impedir que una herramienta exista en absoluto, deniégala por nombre en la
superficie inbound (Bloquear herramientas).
El control de egress asume que la herramienta puede recuperar legítimamente —
solo restringe hacia dónde.
2. Un ejemplo: denegar los destinos SSRF
La regla de egress canónica deniega el endpoint de metadatos de nube y los rangos privados RFC-1918 — los destinos que una herramienta con forma de fetch nunca debería alcanzar. En la consola de tu espacio de trabajo, abre una política y añade una regla constage egress, veredicto deny y una lista de egress:
egress_json es un string codificado en JSON que lleva las listas de
host/CIDR — decodificado, es {"deny": [...], "allow": [...]}. Cada entrada
coincide como un CIDR, un literal de IP o un nombre de host
insensible a mayúsculas. Para un veredicto deny la lista deny es el
conjunto en alcance (destinos que la regla bloquea) y la lista allow talla
excepciones de ella — así que la regla de arriba bloquea los cuatro rangos
pero deja pasar api.openai.com incluso si alguna vez resolviera a uno de
ellos. Cuando un destino es un nombre de host en vez de una IP literal y tu
lista lleva entradas IP/CIDR, el nombre se resuelve con mejor esfuerzo y sus
direcciones se reverifican, así que metadata.internal aún coincide con una
denegación 169.254.0.0/16 aunque no esté listado por nombre.
3. Tú autoras las reglas CIDR — ningún preset las incluye
Lo que el nivel de autonomíatight y su
preset block_ssrf_egress sí incluyen es un conjunto de denegaciones sobre
los nombres de herramienta con forma de fetch — http_fetch,
web_search, fetch_url, request, más sus variantes MCP
<server>.<tool>. Esa es una postura contundente: rechaza las herramientas
con forma de egress de plano en vez de acotar a dónde pueden alcanzar.
Recurre a ella cuando un agente no tiene por qué hacer llamadas de red en
absoluto; recurre a una regla de destino (§2) cuando sí recupera pero solo
de un conjunto aprobado de hosts.
| Enfoque | Qué restringe | Autor |
|---|---|---|
Preset SSRF tight | Nombres de herramienta con forma de fetch (los deniega) | Integrado |
| Regla de CIDR/host de egress | El destino que un fetch puede alcanzar | Tú |
4. Cómo se ve un egress bloqueado
Cuando un destino coincide con una regla de egress de aplicación, la llamada se deniega antes de salir del gateway y la evaluación se registra como un evento del firewall con superficieegress y veredicto deny. En
modo shadow el deny se degrada a audit
con la razón prefijada con [shadow] would …, así que puedes medir
exactamente qué destinos bloquearía una regla contra tráfico real antes de
aplicarla.
Una lista de egress malformada o sin entradas se trata de forma
conservadora: una regla
deny de aplicación aún gobierna (un error
tipográfico no puede detenerla silenciosamente de bloquear), pero una regla
allow con una lista rota no se disparará — de lo contrario una lista de
permitidos mal escrita se volvería permitir-todo y eclipsaría un default
deny. Las reglas nuevas se validan al guardar (la lista debe declarar al
menos una entrada allow o deny), así que esto solo protege filas heredadas.5. Autora desde el tráfico real, luego lanza
Ve los destinos que realmente estás alcanzando
Ve los destinos que realmente estás alcanzando
El registro de eventos registra el
host de destino en cada evento de superficie
egress
(egress_host/egress_url), así que fíltralo a superficie egress y
autora tu lista de denegados desde los destinos que realmente aparecieron
en vez de adivinar. La pestaña Discovered Tools es un resumen por
nombre de herramienta (nombres de herramienta y las superficies en que se
dispararon) — te dice qué herramientas con forma de fetch se ejecutaron,
no los hosts que alcanzaron. Ver
Analítica.Ejecuta en seco un veredicto antes de depender de él
Ejecuta en seco un veredicto antes de depender de él
La pestaña Test de la consola ejecuta en seco una política contra un
tool_name + superficie de muestra (+ args opcionales) y devuelve el
veredicto, la regla coincidente y la razón — nada se despacha. Confirma
qué regla resuelve una llamada; para confirmar tu cálculo de CIDR/host
contra destinos reales, usa el modo shadow de abajo (el payload de Test no
lleva un destino, así que la coincidencia de lista de egress se ejercita
sobre tráfico de egress en vivo). Ver
Probar reglas.Mide en vivo con el modo shadow
Mide en vivo con el modo shadow
Activa el modo shadow y el deny de
egress se registra como se dispararía sin bloquear. Observa el
registro de eventos filtrado a
superficie
egress, confirma que captura los destinos que esperas, luego
apaga shadow.6. Adjunta la política y quién puede editarla
Una política no hace nada hasta que una clave resuelve a ella. Adjunta en la consola estableciendofirewall_policy_id en la
clave, o haz la política el valor por
defecto del espacio de trabajo. La resolución es: la política adjunta de la
clave (cuando existe y está habilitada), si no el valor por defecto del
espacio de trabajo.
Toda la configuración de reglas de egress se ejecuta en la consola bajo tu
sesión (/api/workspace/firewall/*):
| Acción | Rol |
|---|---|
| Leer políticas, presets, herramientas descubiertas, Simulate de autonomía | Member |
| Crear / editar / eliminar reglas de egress y políticas | Developer+ |
Endpoint de Test de ejecución en seco (POST /test) | Developer+ |
| Leer el registro de eventos y agregados de ejecuciones | Developer+ |
Relacionado
Exfiltración de datos
La amenaza que aborda el control de egress.
Etapas
Las cuatro superficies, y dónde se sitúa el egress.
Veredictos
Qué hacen deny, audit y allow en el cable.
Bloquear herramientas
Deniega una herramienta de fetch por nombre en vez de por destino.
Llamadas a herramienta peligrosas
La clase de riesgo más amplia.
Referencia del Firewall
La referencia completa de reglas + coincidencia, incluidas las listas de
egress.