---
title: Físicamente ineludible. Confianza cero.
summary: Todo límite de seguridad de esta arquitectura es físicamente ineludible: se aplica en capas que el código del agente no puede evitar.
date: 2026-09-11
---

# Físicamente ineludible. Confianza cero.

Todo límite de seguridad de esta arquitectura es físicamente ineludible: se aplica en capas que el código del agente no puede evitar.

Los agentes que ejecutan código y hacen solicitudes HTTP necesitan una seguridad que no dependa de que el agente se comporte correctamente. Siete mecanismos lo garantizan:

1. **Intermediario de credenciales**: identificadores opacos en lugar de tokens OAuth reales; las credenciales se inyectan solo durante la propia solicitud HTTP.
2. **Política de salida**: GET está ampliamente permitido; POST/PUT/PATCH/DELETE se restringen a endpoints de integración aprobados, HTTPS es obligatorio.
3. **Defensa contra DNS rebinding**: la resolución DNS, la validación de IP y la conexión TCP ocurren de forma atómica en la pila de red.
4. **Proxy de salida**: un contenedor Docker aislado con reglas `iptables` aplicadas a nivel de kernel es la única vía para el tráfico saliente.
5. **Depuración de tokens**: cada frontera de salida (contexto del LLM, registros, historial de herramientas) se escanea para eliminar tokens OAuth, claves de API y JWT.
6. **Autenticación WebSocket**: las conexiones requieren un token firmado, no caducado y delimitado a la organización antes de aceptarse.
7. **Endurecimiento de contenedores**: ejecución sin privilegios de root, capacidades de Linux reducidas, sistema de archivos raíz de solo lectura, aislamiento por organización, límites de recursos aplicados.

## Componible por diseño

Una sola solicitud (por ejemplo, publicar en una API de calendario) pasa por varios de estos mecanismos en secuencia: la política de salida la valida, el intermediario de credenciales resuelve el token, la defensa DNS verifica la IP, la autenticación inyecta la credencial, y la depuración de tokens limpia los registros resultantes.

## Verificado, no solo declarado

El escaneo de secretos se ejecuta en CI y en pre-commit en cada commit, además de un escaneo periódico del historial completo en todos los commits y etiquetas, no solo en el árbol actual. Es un control del que puedes pedir pruebas, no una simple declaración de política.

La comodidad de desarrollo y la seguridad de producción se mantienen estructuralmente separadas: el arranque se niega a ejecutarse con secretos predeterminados o de marcador de posición, a menos que un único indicador explícito, registrado de forma visible, habilite el desarrollo local inseguro. No existe un ajuste intermedio silencioso.

## Relacionado

- [Integraciones](/es/docs/features/integrations): el modelo OAuth 2.0 + PKCE que protegen estos límites
- [Habilidades](/es/docs/features/skills): las habilidades autoconstruidas permanecen dentro de estos mismos límites