La frontera de despliegue es la arquitectura. Un plano de control decide qué debe ocurrir después y no retiene datos del cliente en reposo; un plano de ejecución dentro de su propia cuenta de nube es lo único que toca sus sistemas. Todo lo demás en este desglose se deriva de esa única división, incluida la respuesta a cada pregunta que hará una revisión de seguridad.
Esto es un desglose, no un argumento. Describe cómo está construido el sistema realmente: qué componente contiene qué, dónde está la frontera de confianza y contra qué defiende cada capa de aislamiento. El razonamiento sobre por qué la topología se decide primero se cubre aparte en el artículo de topología de despliegue; esta página es la implementación.
Del estándar
“Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.”
La división
Dos planos, una frontera dura entre ellos. El plano de control es nuestro y funciona como servicio. El plano de ejecución es suyo y corre en su cuenta de nube, bajo su proveedor de identidad, dentro de su política de red.
- Ciclo de vida de sesión, enrutamiento, compilación del agente
- Evaluación de políticas y puerta previa a la ejecución
- Recolección de trazas y medición
- Filtro eBPF y sumidero DNS — salida denegada por defecto
- Sus almacenes y sus sistemas de registro
La propiedad que le importa a un revisor no es que el plano de control esté bien protegido. Es que el plano de control no tiene nada que proteger. Nunca contiene sus registros, así que un compromiso de nuestro servicio no se convierte en un compromiso de sus datos.
Aislamiento, capa por capa
1. La frontera del hipervisor
El código generado por el agente es código que ningún humano revisó antes de ejecutarse. Ese es un modelo de amenaza distinto al de ejecutar su propia aplicación, y el aislamiento a nivel de contenedor no lo cubre. Los contenedores comparten kernel con el anfitrión, y los escapes de kernel son una clase de vulnerabilidad conocida, no teórica.
Por eso cada ejecución corre en una MicroVM con su propio kernel. La frontera de aislamiento es el hipervisor, no un espacio de nombres. Un escape exitoso deja al atacante dentro de una máquina virtual vacía.
2. Salida denegada por defecto
El aislamiento por sí solo aún deja una ruta de red hacia fuera. Por eso cada sandbox lleva un filtro de red eBPF y un sumidero DNS, restringiendo el tráfico saliente a una lista que usted define. Un agente totalmente comprometido no tiene a dónde enviar nada, porque la exfiltración requiere un destino y no lo hay.
Por qué ambos, y no uno u otro
El filtro de paquetes detiene el tráfico hacia una dirección. El sumidero DNS detiene la resolución que habría producido esa dirección. Juntos cierran tanto la conexión directa como la ruta de resolución, que es lo que hace que la lista de permitidos sea vinculante y no orientativa.
3. Tokenización de entrada, escaneo de salida
La tokenización contextual reemplaza fragmentos sensibles antes de la transmisión y reinyecta los valores reales cuando vuelve la respuesta, de modo que el usuario lee una respuesta completa mientras el modelo solo vio marcadores. La política es declarativa y por inquilino: una lista de categorías que controla qué clases de datos se tokenizan, patrones de identificadores personalizados y una lista de exclusión para valores que parecen sensibles pero no lo son, para que la sobre-tokenización no degrade la respuesta.
La defensa en profundidad significa que ambos corren en direcciones opuestas: el tokenizador a la entrada, el escáner a la salida.
Qué transporta la unión
TLS mutuo en ambas direcciones, y contexto de traza W3C propagado a través de la frontera para que una sola traza distribuida abarque ambos planos. Esa segunda propiedad es lo que hace funcionar la auditoría: el plano de control puede demostrar qué turno disparó qué llamada de herramienta sin haber visto nunca los datos que esa llamada devolvió.
Identidad y el catálogo de herramientas
El ingreso es SAML 2.0 u OIDC contra Azure AD, Okta, Google, ADFS o un proveedor propio. El agente actúa bajo la identidad de la persona que lo dirige, no de una cuenta de servicio, que es lo que hace que la pregunta de autorización tenga respuesta.
warehouse.query · warehouse.preview · catalog.search · metrics.aggregate · crm.read
Hay 0 herramientas que este rol permite y que aún así están ausentes: el inquilino nunca las habilitó. Intersección, no unión.
Cada herramienta que este rol permite también está habilitada por el inquilino, así que aquí la intersección es el rol.
El catálogo de herramientas disponible se calcula por turno como la intersección de lo que soporta la plataforma, lo que el inquilino ha habilitado y lo que permite el rol del usuario que actúa, y luego se compila en un manifiesto de sesión firmado. Una instrucción inyectada en el contenido no puede alcanzar una capacidad fuera de esa intersección, porque la capacidad nunca estuvo en el manifiesto.
-
available_tools = platform ∩ tenant ∩ rbac Tres conjuntos, intersecados Lo que ofrece la plataforma, lo que habilitó el inquilino y lo que permite el rol de esta persona.
-
MANIFIESTO DE SESIÓN FIRMADO Compilado una vez por turno
-
ESQUEMAS INYECTADOS JUSTO A TIEMPO Solo cuando una herramienta va a usarse Así, un catálogo grande de conectores nunca consume la ventana de contexto.
Conectores como configuración
Los conectores son manifiestos declarativos en lugar de código. La capa descubre cada esquema de herramienta en tiempo de ejecución y lo inyecta justo a tiempo, lo que significa que agregar un sistema es un commit de configuración revisado como cualquier otro cambio, no un lanzamiento. Diecinueve conectores cubren actualmente cinco almacenes de datos en la nube y catorce adaptadores de archivos y servicios.
Una consecuencia que vale la pena mencionar: cuando un conjunto de resultados supera un umbral de tamaño, el conector lo materializa en almacenamiento de objetos y devuelve una URL prefirmada en lugar de las filas. Los resultados grandes nunca transitan por el contexto del modelo, lo que acota tanto el costo como la exposición.
El caso de salida restringida
La topología también funciona aislada o con salida totalmente restringida. La inferencia se enruta por la pasarela que su organización ya haya aprobado, el despliegue soporta Kubernetes y Helm en instalaciones propias, y el modelo de embeddings para recuperación corre residente y localmente en lugar de llamar a un servicio alojado. Ese último detalle es lo que hace real y no nominal el caso aislado: un sistema que debe alcanzar un endpoint de embeddings alojado no está aislado, sea lo que sea cierto de él.
Lo que cuesta esta forma
No es gratis. Usted opera infraestructura, la parchea y asume una guardia para ella. Un despliegue alojado de inquilino único es operacionalmente más barato y pasa la revisión en muchísimas organizaciones. La división en dos planos justifica su costo solo donde un contrato, un regulador o una cláusula de residencia dicen que los datos no salen; y en ese caso no es una preferencia, es la única forma que responde la pregunta con un diagrama de red en lugar de una garantía legal.
El sistema desplegado que describe este desglose ejecuta 60 módulos en producción respaldados por 1.800 pruebas automatizadas, y está diseñado para clasificar cada turno conversacional en menos de 100 milisegundos antes de que corra ningún pipeline.
Axionalytics
IA agéntica en producción para equipos empresariales de ingeniería, datos e ingresos.