La seguridad de correo electrónico AgentCore de Abnormal AI escala los agentes al limitar su alcance
Abnormal AI ha implementado Amazon Bedrock AgentCore Code Interpreter dentro de un sistema de detección que procesa miles de millones de mensajes de correo electrónico cada día. El diseño de seguridad de correo electrónico Abnormal AI AgentCore ofrece a los agentes autónomos capacidad de cómputo temporal, pero niega a ese entorno acceso sin restricciones a internet. Esa limitación es la idea central, no una decisión menor de configuración.
Los agentes manejan solo decenas de miles de los casos diarios más complejos de la canalización. Clasificadores ligeros procesan primero miles de millones de mensajes, mientras que modelos de machine learning más grandes examinan millones de resultados inciertos. Abnormal reserva el análisis impulsado por agentes para los casos que las etapas anteriores no pueden clasificar con confianza.
Esta arquitectura cuestiona la idea más simple de que una mejor seguridad de correo electrónico procede de enviar cada mensaje al modelo más grande disponible. También difiere de sistemas centrados en analistas como Microsoft Security Copilot, que puede explicar clasificaciones de phishing para la revisión humana. Abnormal sitúa a los agentes directamente en una canalización de detección en línea, donde la latencia, el aislamiento y límites previsibles ante fallos importan de inmediato.
La implementación es relevante porque sus agentes pueden escribir y ejecutar scripts mientras analizan datos de amenazas conductuales. Esta capacidad ofrece más flexibilidad que un clasificador fijo, pero también crea una nueva superficie de ataque. Un correo electrónico es tanto evidencia como una entrada potencialmente hostil, por lo que todo agente que lo examine debe considerarse capaz de tomar una decisión insegura.
La respuesta de Abnormal es un sistema por capas basado en una escalada selectiva y una ejecución restringida. El modelo dispone de espacio para calcular, agregar y verificar dentro de un sandbox temporal. La arquitectura circundante decide qué entra, qué puede salir y qué acciones siguen sin estar disponibles.
La seguridad de correo electrónico AgentCore de Abnormal AI se centra en los casos más complejos
El cambio principal no es que Abnormal añadiera un agente de IA. Es que colocó agentes que escriben código dentro de una canalización de detección activa sin asignarles toda la carga de trabajo.
Según el caso de estudio de implementación, Abnormal utiliza tres niveles de procesamiento. El primer nivel aplica modelos pequeños, reglas heurísticas y clasificadores de regresión logística a miles de millones de mensajes diarios. Esos métodos gestionan los casos que no requieren análisis costosos.
Los mensajes que siguen siendo inciertos pasan al segundo nivel. El deep learning y otros modelos de machine learning inspeccionan millones de mensajes cada día utilizando señales conductuales más amplias. Solo los casos sin resolver más difíciles llegan al tercer nivel.
Ese nivel final procesa decenas de miles de mensajes diarios con agentes en línea y Code Interpreter. Los agentes reciben datos de inteligencia de amenazas, escriben scripts de forma dinámica y analizan cómo encaja cada caso en el modelo conductual de Abnormal. Después contribuyen a una decisión de detección antes de que el correo llegue a la bandeja de entrada.
Este embudo es importante tanto para la economía como para la fiabilidad. Ejecutar un agente general sobre cada mensaje consumiría la mayor parte del cómputo donde a menudo aporta el menor valor adicional. También expondría una parte mayor de la canalización de producción a comportamientos no deterministas.
La escalada selectiva convierte al agente en un gestor de excepciones. Las etapas anteriores absorben el volumen previsible, mientras los agentes investigan casos que se asemejan al trabajo tradicionalmente asignado a un analista humano. El diseño emplea la complejidad del modelo según la incertidumbre, no según el posicionamiento del producto.
La arquitectura también limita las consecuencias operativas de un fallo del agente. Un error en el tercer nivel sigue siendo importante, pero el agente no controla la clasificación de todos los mensajes ordinarios. Un sistema independiente gestiona las clasificaciones erróneas y las utiliza para mejorar el sistema de detección más amplio.
Abnormal afirma que los sistemas de monitorización también verifican la canalización activa. El caso de estudio de AWS no publica mediciones independientes de precisión, falsos positivos o latencia. Por tanto, documenta una arquitectura operativa, no una prueba comparativa de que los agentes superen a todos los métodos convencionales de detección.
La empresa también ejecuta un agente analista fuera de la ruta en línea. Ese sistema por lotes ingiere clasificaciones erróneas y señales de ajuste, y después busca patrones en conjuntos de mensajes más amplios. Redacta heurísticas candidatas para el primer nivel y aporta mejoras para el segundo.
AWS afirma que este agente analista ejecuta cerca de 100 trabajos por lotes cada semana. Los trabajos individuales pueden permanecer activos durante más de 30 minutos. Algunos flujos de trabajo abarcan un día completo porque el entrenamiento de modelos ocurre fuera de la sesión de Code Interpreter.
Este ciclo de retroalimentación otorga al agente un segundo papel. No solo evalúa mensajes difíciles. También extrae de resultados complejos reglas que los clasificadores más baratos pueden aplicar después.
El resultado es una división práctica del trabajo. Las reglas fijas aportan rendimiento, los modelos entrenados ofrecen un reconocimiento de patrones más amplio y los agentes proporcionan investigación flexible. El razonamiento más costoso se reserva para casos en los que esa flexibilidad tiene un propósito claro.
El bloc de trabajo es cómputo, no más contexto para el modelo
Code Interpreter importa porque permite al agente calcular y comprobar afirmaciones, en lugar de tratar la generación de lenguaje como si fuera computación.
Un modelo de lenguaje de gran tamaño puede describir un cálculo y aun así producir un resultado incorrecto. También puede proponer un script útil sin saber si ese script se ejecuta correctamente. Los agentes de Abnormal necesitan un espacio de trabajo donde el código generado pueda ejecutarse contra datos permitidos.
Amazon Bedrock AgentCore Code Interpreter proporciona ese espacio de trabajo mediante una API. El servicio ofrece a los agentes un entorno aislado para ejecutar comandos, cargar archivos y devolver resultados. No impone un ciclo de razonamiento ni un framework de agentes específicos.
AWS describe esta capacidad como un entorno de ejecución totalmente gestionado y serverless. Las sesiones se ejecutan dentro de MicroVMs efímeras, máquinas virtuales ligeras con cómputo, memoria y sistemas de archivos aislados. Una sesión dura 15 minutos de forma predeterminada y puede configurarse hasta por ocho horas.
El entorno incluye runtimes de Python y Node.js con bibliotecas comunes para procesamiento de datos, estadística y visualización. Los archivos de hasta 100 MB pueden pasar directamente a través de la API. Los conjuntos de datos más grandes pueden usar Amazon S3 o configuraciones de sistemas de archivos gestionadas por el cliente.
La distinción entre contexto y computación es importante. Añadir inteligencia de amenazas al prompt de un modelo le da más material que interpretar. Darle Code Interpreter permite al agente transformar, contar, comparar y probar ese material mediante programación.
El ejecutivo de Abnormal AI, Shrivu Shankar, describe este entorno como un bloc de cómputo necesario para casi cualquier agente. Este enfoque lleva la ejecución de código más allá de los asistentes de desarrollo de software. Un agente de seguridad puede utilizar scripts para agregación, comparaciones conductuales, validación de datos o puntuaciones repetibles.
El agente también puede ejecutar verificadores programáticos. Las pruebas, los linters y las comprobaciones de integración proporcionan retroalimentación legible por máquinas antes de que una salida llegue a otro componente de producción. No garantizan la corrección, pero ofrecen al agente evidencia más allá de su propia explicación generada.
Este enfoque se parece a un patrón más amplio en el diseño de agentes. Los desarrolladores separan cada vez más el modelo que propone el trabajo del entorno de ejecución que lo realiza. El modelo sigue siendo probabilístico, mientras que el entorno de ejecución proporciona resultados deterministas para operaciones específicas.
AWS presentó por primera vez Code Interpreter como infraestructura para ejecutar de forma segura código generado por agentes. Su valor en la canalización de Abnormal procede de esa separación. Abnormal puede conservar su arnés de agentes existente mientras trata el cómputo aislado como un servicio externo.
Un arnés ligero también aporta flexibilidad al agente. Abnormal afirma que los flujos de trabajo rígidos y paso a paso pueden rendir peor que los principios de alto nivel combinados con herramientas generales. El agente elige un método, pero debe operar dentro de los límites establecidos por el sistema circundante.
Ese equilibrio es difícil. Demasiada poca libertad reduce al agente a un flujo de trabajo fijo y costoso. Demasiada libertad permite que entradas no fiables influyan en el código, las solicitudes de red, los archivos y las credenciales.
El modelo de bloc de trabajo encuentra una posición intermedia. Otorga al agente libertad local para crear scripts y artefactos temporales. No concede automáticamente autoridad sobre el entorno de producción que rodea ese espacio de trabajo.
Para los desarrolladores, este diseño plantea una pregunta clara antes de añadir otro modelo o una ventana de contexto más grande. ¿El agente necesita más conocimiento o necesita un lugar controlado donde calcular? Estos problemas requieren infraestructuras diferentes.
Los equipos que desarrollan agentes internos también necesitan registros duraderos fuera del prompt del modelo. Una base de conocimiento con capacidad de búsqueda puede preservar especificaciones y hallazgos operativos. El sandbox de ejecución debe seguir siendo temporal, mientras que el conocimiento aprobado persiste mediante sistemas gobernados.
Los sandboxes sin salida de red convierten el riesgo de los agentes en un problema acotado
La decisión de diseño más sólida de Abnormal es negar al sandbox de análisis acceso de red sin restricciones, incluso cuando el agente se comporta de manera inesperada.
Un agente de seguridad de correo electrónico procesa contenido creado por personas externas. Los atacantes pueden incluir instrucciones, enlaces, material codificado o texto adversarial dentro de ese contenido. Un modelo podría interpretar esos elementos como evidencia, pero también podría tratarlos como instrucciones.
Este problema se conoce como prompt injection, cuando contenido no fiable intenta desviar a un agente de su tarea prevista. Las defensas a nivel de modelo pueden reconocer algunos ataques. No pueden ofrecer una garantía determinista frente a todas las manipulaciones.
Por ello, Abnormal seleccionó la configuración de red del sandbox para Code Interpreter. En su implementación, el entorno de ejecución no tiene salida a la internet pública. La inteligencia de amenazas puede entrar para su análisis, pero el código generado no puede transmitir libremente esa información a un endpoint externo.
La restricción cumple dos objetivos. Primero, mejora la reproducibilidad porque los sitios web o servicios externos no pueden cambiar el comportamiento de una sesión durante la ejecución. Segundo, limita la exfiltración de datos si un modelo sigue instrucciones maliciosas o genera código inseguro.
Esta es la tensión principal del artículo: flexibilidad de los agentes frente a ejecución acotada. El sistema da al modelo libertad para elegir cálculos y escribir scripts. La infraestructura limita los lugares a los que esos scripts pueden llegar.
AWS admite varios modos de red para Code Interpreter. El modo sandbox proporciona acceso externo restringido, incluidas operaciones compatibles con Amazon S3. El modo público permite recursos de internet, mientras que el modo VPC conecta el entorno a recursos privados aprobados.
Estas opciones no deben tratarse como ajustes intercambiables de conveniencia. El acceso público amplía lo que un agente puede hacer, pero también amplía los posibles riesgos de exfiltración y dependencia. El acceso VPC puede llegar a sistemas internos valiosos, por lo que los roles de ejecución y las políticas de red se vuelven críticos.
Abnormal añade el sandbox gestionado a su entorno existente con aislamiento de red. Ese enfoque de defensa en profundidad evita considerar suficiente un único límite de aislamiento. La empresa también controla qué datos entran en Code Interpreter y qué acciones de escritura puede realizar el agente.
Esta arquitectura se alinea con la orientación de seguridad que está surgiendo en otros ámbitos del desarrollo de agentes. Anthropic sostiene que la contención de agentes necesita límites tanto de sistema de archivos como de red. Sin restricciones de salida, un proceso comprometido puede enviar secretos accesibles a otros destinos.
El posterior análisis de contención de Anthropic expone el punto subyacente de forma más directa. La supervisión probabilística no puede sustituir un límite estricto sobre los recursos accesibles. La contención limita las consecuencias incluso cuando el modelo toma una decisión equivocada.
La documentación de AWS añade otra salvedad importante. Cada sesión de AgentCore recibe recursos aislados de CPU, memoria y sistema de archivos, y su MicroVM se termina después. Sin embargo, los clientes siguen siendo responsables de los permisos, las asignaciones de sesiones, la validación de entradas, las credenciales y las herramientas conectadas.
La guía de seguridad también advierte que el código dentro de una MicroVM puede acceder a las credenciales asignadas a ese entorno. El aislamiento respecto de otras sesiones no hace seguros los permisos excesivos dentro de la sesión actual.
Por tanto, un sandbox seguro exige más que cómputo efímero. Los desarrolladores deben delimitar los roles de ejecución, restringir las rutas de red, filtrar las entradas de herramientas y excluir credenciales innecesarias. También deben decidir qué artefactos pueden salir una vez finalizada la ejecución.
El patrón sin salida funciona especialmente bien para tareas con entradas autocontenidas. Un agente puede recibir un paquete de evidencias acotado, calcular localmente y devolver un resultado limitado. Los flujos de trabajo que requieren sitios web arbitrarios o API externas plantean un problema de políticas más difícil.
Una respuesta es una capa de herramientas intermediada. En lugar de conceder conectividad general, el agente invoca herramientas con nombre mediante un proxy controlado. Cada herramienta puede aplicar autenticación, validación de entradas, listas de permitidos, registro y esquemas de salida limitados.
Ese diseño preserva acciones externas útiles sin convertir el sandbox en una máquina común conectada a internet. También proporciona a los equipos de seguridad un registro de lo que solicitó el agente y de lo que devolvió la herramienta.
El despliegue de Abnormal no elimina la inyección de prompts. Reduce lo que una inyección exitosa puede lograr dentro de un entorno. Es una afirmación de producción más defendible que decir que el modelo siempre reconocerá contenido malicioso.
El pipeline de tres niveles presiona tanto a los proveedores de seguridad como a los desarrolladores de agentes
La arquitectura de Abnormal eleva el estándar: pasar de producir respuestas de agentes persuasivas a producir decisiones acotadas bajo restricciones operativas reales.
Los proveedores de seguridad de correo electrónico ya emplean reglas, sistemas de reputación, aprendizaje automático y análisis de comportamiento. La nueva presión surge al situar agentes flexibles más profundamente dentro de los flujos de detección. Los competidores deben decidir si los agentes deben trabajar junto a los analistas o directamente en la ruta de clasificación.
El enfoque de Microsoft ofrece una comparación útil sin establecer un ganador simple. Su Security Copilot Phishing Triage Agent evalúa el contenido del correo, la reputación del remitente y las señales de comportamiento. Produce una clasificación y una justificación en lenguaje natural que los analistas pueden revisar o anular.
Ese modelo de triaje de phishing pone el énfasis en identidades de agentes gobernadas, desencadenantes definidos, permisos de acceso y derechos de acción. Sitúa la transparencia y la revisión humana cerca del centro del flujo de trabajo.
En cambio, el despliegue reportado de Abnormal utiliza agentes en línea para un subconjunto de mensajes cuidadosamente filtrado. La salida participa en una decisión antes de la entrega, aunque está rodeada de monitorización y sistemas de aprendizaje independientes. La diferencia se refiere más a la ubicación en el flujo de trabajo que a la capacidad básica del modelo.
Ninguno de los dos enfoques vuelve obsoletos a los analistas humanos. Los casos más difíciles de Abnormal son los que tradicionalmente exigirían atención de un analista. Sus agentes absorben parte de ese trabajo de investigación, mientras los humanos siguen diseñando controles, interpretando fallos y gobernando los cambios del modelo.
La arquitectura también presiona a los proveedores de plataformas generales de agentes. Un entorno de ejecución de producción debe admitir más que la ejecución de código. Necesita aislamiento de sesiones, controles de ciclo de vida, observabilidad, manejo predecible de archivos y políticas de red que los administradores puedan comprender.
El servicio gestionado reduce el trabajo necesario para operar cómputo desechable. Sin embargo, no elimina las decisiones de diseño a nivel de aplicación. Los desarrolladores siguen eligiendo qué entradas llegan al sandbox, cómo se asignan las sesiones a las tareas y qué resultados pueden alterar los sistemas de producción.
El embudo de tres niveles aporta otra lección. El escalado de agentes es, en parte, un problema de enrutamiento. Los equipos deben medir la incertidumbre y escalar de forma selectiva, en lugar de asumir que cada solicitud merece el mismo modelo, contexto, herramientas y presupuesto de cómputo.
Ese principio se aplica más allá de la seguridad. Los sistemas de atención al cliente pueden dirigir las solicitudes rutinarias a flujos de trabajo deterministas y reservar los agentes para los casos ambiguos. Los sistemas de datos pueden usar primero transformaciones fijas y luego llamar a agentes cuando los esquemas o las evidencias entren en conflicto.
El analista por lotes ofrece un segundo patrón reutilizable. Los fallos de producción pueden alimentar a un agente fuera de línea que busque causas repetidas y proponga reglas más económicas. Humanos o verificadores automatizados pueden evaluar esas propuestas antes de promoverlas.
Sin embargo, este bucle de retroalimentación introduce cuestiones de gobernanza. Una heurística candidata derivada de clasificaciones erróneas pasadas puede codificar un patrón temporal o amplificar una muestra sesgada. Los desarrolladores necesitan conjuntos de evaluación, controles de despliegue y vías de reversión antes de actualizar etapas anteriores del pipeline.
El caso de estudio de AWS no proporciona esos detalles operativos. Indica que un sistema independiente aprende de los errores y que la monitorización verifica el sistema en vivo. No revela los umbrales de aprobación, la metodología de evaluación ni la proporción de propuestas de agentes que llegan a producción.
Tampoco revela la latencia de extremo a extremo. La detección de correo electrónico en línea opera bajo restricciones de entrega, y un tercer nivel lento puede afectar la experiencia de usuario. El enrutamiento selectivo reduce esa exposición, pero los desarrolladores siguen necesitando latencia por percentiles y comportamiento ante tiempos de espera.
El coste sigue siendo igualmente poco claro. El embudo casi con certeza evita ejecutar cómputo de agentes sobre miles de millones de mensajes rutinarios. El material publicado no ofrece costes por mensaje, utilización de sesiones ni comparaciones de infraestructura con un sandbox autogestionado.
Estas omisiones no invalidan la arquitectura. Definen el límite entre un útil caso de estudio de cliente y evidencia de rendimiento verificada de manera independiente. Los compradores empresariales deberían evaluar el patrón mientras solicitan mediciones específicas para su carga de trabajo.
Para los responsables de seguridad, la pregunta más útil no es si un proveedor cuenta con detección “agéntica”. Es dónde entra el agente en la ruta de decisión, qué evidencias recibe y qué ocurre cuando falla.
Para los equipos de plataforma, la pregunta es igual de concreta. ¿Puede el agente completar trabajo valioso dentro de un entorno de alcance limitado, o el flujo de trabajo propuesto depende de credenciales amplias y conectividad abierta?
Si el trabajo útil requiere acceso ilimitado, el diseño no ha resuelto la disyuntiva central. Ha trasladado ese riesgo al entorno de ejecución.
Lo que el caso de estudio de Abnormal AI no demuestra
El despliegue muestra un patrón de contención creíble, pero no establece mejoras independientes en precisión, velocidad o coste operativo total.
La fuente central es un artículo de AWS escrito con la participación de Abnormal. AWS proporciona la infraestructura y Abnormal es el cliente destacado. Los lectores deberían considerar las cifras de escala y las descripciones del flujo de trabajo como afirmaciones atribuidas a la empresa.
Los volúmenes reportados siguen siendo informativos. Miles de millones de mensajes entran en el primer nivel, millones llegan al segundo y decenas de miles alcanzan a los agentes cada día. Sin embargo, esos recuentos no revelan con qué frecuencia los agentes mejoran el veredicto final.
Varias mediciones ausentes cambiarían la evaluación. Las tasas de falsos positivos mostrarían si los mensajes legítimos difíciles afrontan un riesgo adicional. Las tasas de falsos negativos mostrarían si el agente detecta ataques que los modelos anteriores no detectaron.
Los datos de revisión por analistas también ayudarían. Si los humanos revocan con frecuencia las decisiones de los agentes, el tercer nivel podría funcionar como una herramienta de priorización en lugar de detección autónoma. Si las revocaciones son poco frecuentes, los compradores seguirían necesitando evidencia de que la monitorización detecta errores silenciosos.
Las distribuciones de latencia importan porque los promedios pueden ocultar fallos operativos. Un pequeño grupo de sesiones de larga duración podría retrasar el correo incluso cuando las clasificaciones típicas terminan rápidamente. Los tiempos de espera y los mecanismos alternativos deben probarse con tanto cuidado como la calidad del modelo.
La misma cautela se aplica a las afirmaciones de determinismo. Eliminar el acceso a la internet pública reduce la variabilidad externa, pero las salidas del modelo pueden seguir siendo estocásticas. Las bibliotecas de software, el orden de las entradas, las versiones del entorno de ejecución y la lógica de orquestación también pueden influir en los resultados.
“No egress” también debe interpretarse con precisión. Restringe la comunicación de red pública desde el sandbox. No valida automáticamente los datos entrantes, evita cálculos locales dañinos ni garantiza que los artefactos devueltos no contengan información sensible.
Por ello, los controles de salida siguen siendo necesarios. Un informe generado puede contener por sí mismo datos confidenciales. Un script puede crear un artefacto sobredimensionado, consumir recursos de sesión o producir un resultado engañoso sin conectarse a internet.
El almacenamiento persistente plantea consideraciones adicionales. Abnormal utiliza archivos como puntos de control cuando el trabajo dura más que una sesión. Los desarrolladores que adopten ese patrón deben definir la retención, los límites de acceso, el cifrado, las escrituras simultáneas y la propiedad de los artefactos.
El sistema de archivos es un punto de recuperación, no una política de seguridad. Los datos que salen de una sesión efímera se vuelven duraderos en algún otro lugar. Sus protecciones pasan entonces a depender del servicio de almacenamiento y de la aplicación que los utiliza.
El trabajo de larga duración también complica la identidad. Un proceso de un día puede atravesar varias sesiones y trabajos externos de entrenamiento. Cada transferencia necesita una identidad de tarea autenticada, entradas explícitas y salidas verificables.
La observabilidad ayuda a reconstruir estas transiciones. AgentCore puede enviar registros a Amazon CloudWatch y auditar actividad mediante AWS CloudTrail. Los equipos aún deben elegir qué registrar sin copiar contenido sensible de los mensajes a otro sistema.
Monitorizar un agente exige señales tanto operativas como de seguridad. Los errores de ejecución, los tiempos de espera y el consumo de recursos revelan problemas de fiabilidad. Los comandos inesperados, los intentos de red bloqueados y los tamaños de salida inusuales pueden exponer comportamientos hostiles o confusos.
Los desarrolladores también deberían probar deliberadamente las rutas de fallo. ¿Qué ocurre cuando el sandbox no puede iniciarse, un script supera los límites o el modelo produce código no válido? El sistema necesita un mecanismo alternativo seguro que no clasifique silenciosamente la incertidumbre como seguridad.
En el caso de Abnormal, los niveles de detección anteriores proporcionan parte de esa estructura circundante. El caso publicado no especifica el mecanismo alternativo final para cada fallo del tercer nivel. Esa laguna merece examinarse durante la evaluación técnica.
Por tanto, el caso de estudio respalda una conclusión más limitada de lo que su escala por sí sola podría sugerir. El cómputo efímero gestionado puede encajar en un pipeline de seguridad de gran volumen cuando el enrutamiento limita estrictamente la carga de trabajo de los agentes. Una contención sólida también puede reducir las consecuencias de un fallo del modelo.
No demuestra que todas las decisiones de seguridad se beneficien de un agente. Muestra dónde Abnormal considera que el cómputo flexible merece su lugar: la pequeña y difícil cola de casos que los sistemas más simples no pueden resolver con confianza.
Tres señales mostrarán si este patrón se sostiene a escala
La próxima prueba será comprobar si Abnormal y AWS publican evidencia operativa que conecte la arquitectura de aislamiento con resultados de detección medibles.
La primera señal son los datos sobre la calidad de las cargas de trabajo. Habrá que observar las tasas de falsos positivos, falsos negativos, anulaciones por parte de analistas y mejoras medibles frente al proceso anterior de tercer nivel. Esos resultados reforzarían la idea de que los agentes aportan valor de detección, en lugar de complejidad arquitectónica.
La ausencia de esas mediciones no demostraría un fracaso. Mantendría las afirmaciones más contundentes dentro de la categoría de experiencia de implementación reportada por el proveedor. Los compradores tendrían que realizar evaluaciones controladas con su propio tráfico y perfiles de amenazas.
La segunda señal es un control de políticas más profundo en los servicios gestionados de ejecución de código. Entre los avances útiles se incluyen listas de permitidos de salida más restrictivas, autorización por herramienta, análisis de artefactos, intermediación de credenciales y procedencia detallada de las sesiones. Estos controles mejorarían el equilibrio al otorgar capacidades sin ampliar todo el sandbox.
Un avance hacia redes sin restricciones debilitaría este patrón. Podría facilitar las integraciones, pero también pondría mayor presión sobre las defensas probabilísticas de los modelos. La arquitectura más segura mantiene la autoridad fuera del modelo siempre que sea posible.
La tercera señal es la adopción de enrutamiento selectivo de agentes por parte de otros proveedores de seguridad. Microsoft ya conecta agentes con la clasificación de phishing y los flujos de trabajo de analistas. El siguiente paso importante es demostrar que los proveedores pueden situar agentes en línea manteniendo mecanismos de respaldo y rutas de revisión transparentes.
Una adopción más amplia sugeriría que el embudo de tres niveles de Abnormal se está convirtiendo en un patrón del sector. Un retroceso hacia copilotos exclusivos para analistas indicaría que la latencia, la fiabilidad o la gobernanza aún bloquean la autonomía en línea.
Los equipos de desarrollo no necesitan esperar ese veredicto del mercado. Pueden probar la arquitectura ahora con cargas de trabajo acotadas y criterios de evaluación explícitos. Empiecen por casos en los que el paquete de entrada sea autosuficiente y un verificador determinista pueda evaluar el resultado.
Mantengan las credenciales duraderas fuera del entorno de ejecución. Otorguen únicamente los datos y las herramientas necesarios para una tarea. Traten cada documento, mensaje, sitio web y respuesta de herramienta como una entrada potencialmente hostil.
Hagan que la finalización de la sesión forme parte del diseño, no de un detalle de limpieza. Conserven únicamente los artefactos aprobados y asócienlos a una identidad de tarea auditable. Definan comportamientos seguros para cada tiempo de espera agotado, resultado malformado y dependencia no disponible.
Sobre todo, midan el embudo. Registren cuántos casos resuelve cada nivel, por qué se produce la escalación y si el siguiente nivel mejora el resultado. La capacidad de cómputo de los agentes debe ganarse su lugar mediante valor medible.
La historia de la seguridad de correo electrónico de Abnormal AI AgentCore trata, en última instancia, de una limitación disciplinada. Los agentes reciben suficiente libertad para investigar casos que los sistemas fijos no pueden resolver. No reciben alcance ilimitado simplemente porque su razonamiento parezca útil.
Esa es la pregunta práctica para cada equipo de agentes en producción: ¿qué trabajo valioso puede terminar su agente dentro de un entorno desechable, observable y estrictamente acotado? Construyan primero ese límite y, después, decidan cuánta autonomía corresponde dentro de él.
