Nota del autor: A partir del caso de cliente de Cisco, presentamos 3 prioridades de seguridad para agentes que ayudan a los equipos empresariales a distinguir los ataques maliciosos de los errores cometidos por agentes con buenas intenciones, y a trasladar esa distinción al diseño de la supervisión y los controles.
Una vez que los agentes entran en producción, los equipos de seguridad ya no solo tienen que preocuparse por los ataques externos. Un agente con permisos adecuados y un objetivo legítimo también puede tomar un camino que nadie había previsto para completar su tarea: por ejemplo, relajar una política de acceso para «solucionar una incidencia cuanto antes». Este artículo se centra en tres prioridades de seguridad para agentes que te ayudarán a determinar si un comportamiento anómalo se debe a un ataque o a un agente que, con buenas intenciones, ha cometido un error.
Esto no es una repetición del material promocional de un cliente. Nos basamos en el caso de cliente de Cisco publicado por OpenAI el 3 de noviembre de 2026, cuyo contenido sobre seguridad de agentes recoge principalmente las opiniones de Jeetu Patel, presidente y director de producto de Cisco. Convertiremos esas ideas en una lista de preguntas para la autoevaluación y señalaremos cuáles son opiniones del directivo y cuáles carecen por ahora de datos públicos que las respalden.
Valor principal: al terminar, tendrás un marco que podrás usar directamente en una revisión interna: qué datos recopilar, en qué puntos intervenir, qué nivel de respuesta en tiempo real necesitas y cómo integrarlo en los procesos de análisis de seguridad existentes.
Seguridad de los agentes: 3 prioridades del caso Cisco
En el caso, Patel plantea que, a medida que los agentes ganan autonomía, los equipos de seguridad deben distinguir entre dos situaciones: una interferencia maliciosa y un agente que persigue un objetivo legítimo de una forma no prevista. Para lograrlo, propone combinar la telemetría de seguridad con los datos de observabilidad y establece tres prioridades.
| Prioridad | Significado original | Aplicación para los equipos empresariales |
|---|---|---|
| Proteger frente a ataques maliciosos | Proteger a los agentes de ataques maliciosos | Controlar las fuentes de entrada, los permisos de las herramientas y las credenciales de identidad del agente |
| Detectar y bloquear comportamientos no previstos | Identificar y bloquear comportamientos no previstos | Determinar si el comportamiento excede los límites de la tarea e interrumpir la ejecución cuando sea necesario |
| Operar casi en tiempo real | Funcionar a una velocidad cercana al tiempo real | Detectar y bloquear las acciones antes de que surtan efecto o muy poco después |
Según el caso, estas tres prioridades están orientando la estrategia de seguridad hacia «políticas y controles capaces de adaptarse a las acciones de los agentes». En otras palabras, las listas de permisos estáticas y las aprobaciones puntuales ya no son suficientes: los controles deben seguir las acciones reales del agente.
La clave de la seguridad de los agentes: distinguir entre «sufrir un ataque» y «equivocarse con buena intención»
En las operaciones de seguridad tradicionales, se suele asumir que una anomalía equivale a una amenaza, y la respuesta habitual es bloquearla y rastrear su origen. Pero una anomalía en un agente puede deberse simplemente a una interpretación incorrecta del objetivo o a una mala elección de cómo alcanzarlo. Si todas se tratan como ataques, los falsos positivos consumirán mucho tiempo del equipo y harán que las áreas de negocio pierdan confianza en los agentes. A la inversa, si un ataque real de inyección de indicaciones se considera «un error tonto del modelo», se puede perder la oportunidad de actuar a tiempo.
Por eso Patel insiste en combinar ambos tipos de datos. La telemetría de seguridad te dice «qué pasa fuera»: conexiones anómalas, cargas útiles sospechosas o uso de credenciales. Los datos de observabilidad te muestran «qué piensa y hace el propio agente»: el objetivo de la tarea, qué herramientas ha invocado y las entradas y salidas de cada paso. Si solo observas uno de los dos, no podrás responder a la pregunta: «¿De quién es esta intención?».
Naturaleza de la evidencia sobre seguridad de agentes: opiniones y conclusiones verificadas
Antes de utilizar este caso para tomar decisiones internas, conviene tener clara la naturaleza de la evidencia. El material fue publicado por OpenAI y es un caso de cliente, por lo que tiene un carácter promocional. Ofrece puntos de vista orientativos, pero no aporta detalles técnicos verificables ni resultados cuantificados.
| Afirmación del caso | Naturaleza | Información que falta en el material público |
|---|---|---|
| La seguridad de los agentes requiere combinar telemetría de seguridad y datos de observabilidad | Opinión de un directivo de Cisco | Campos de datos concretos y métodos de correlación |
| Tres prioridades: proteger frente a ataques, bloquear comportamientos imprevistos y actuar casi en tiempo real | Opinión de un directivo de Cisco | Arquitectura de implementación y ejemplos de reglas de detección |
| Daybreak y GPT‑6 Astra aportan una «mejora sustancial» | Valoración de un directivo de Cisco | Indicadores cuantitativos, como el tiempo de corrección y la tasa de detección |
| Las capacidades pueden integrarse en los procesos de análisis existentes sin cambiar de raíz la forma de trabajar | Opinión de un directivo de Cisco | Método de integración y alcance de la compatibilidad |
| Daybreak Defense Network ayuda a acelerar la priorización de exposiciones y a aplicar controles en Cisco Cloud Control | Línea de trabajo que ambas partes están explorando | Funciones concretas, alcance de disponibilidad y fecha de lanzamiento |
| OpenAI plantea como enfoque de privacidad empresarial la retención cero de datos, límites estrictos de datos y aislamiento verificable | Declaración de OpenAI | Evaluación independiente de terceros |
Por tanto, lo más prudente es tratar el caso como una «fuente de preguntas», no como una «prueba de la eficacia de la solución». Las tres prioridades tienen una lógica clara y sirven para revisar la arquitectura propia. En cuanto a la mejora que pueden aportar productos concretos, habrá que esperar documentación técnica independiente o evaluaciones de terceros, o bien probarlos en el propio entorno.
El enfoque de red en el caso de seguridad de agentes
La primera parte del caso aborda el enfoque de defensa de red de Cisco, que también ofrece ideas útiles para los escenarios con agentes. Patel describe una transición desde un único perímetro de seguridad hacia controles distribuidos entre microservicios, contenedores y clústeres, colocando una «mini pila de seguridad» delante de cada microservicio, cada contenedor de Kubernetes y cada clúster. Los controles en la capa de aplicación pueden limitar la comunicación a las conexiones que cada servicio necesita realmente, reduciendo las vías de movimiento lateral de un atacante.
Aplicar esta idea a los agentes es sencillo: cada agente también debería tener únicamente las conexiones y los permisos de herramientas necesarios para completar su tarea. Si se detecta una anomalía, el equipo puede aislar solo al agente o servicio afectado y mantener el resto de la actividad en marcha, en lugar de detener todo para investigar. El caso también señala que dos señales pueden parecer inofensivas por separado, pero revelar un patrón relevante al combinarlas. Ahí reside precisamente el valor del análisis de correlación.
Primeros pasos con la seguridad de agentes: una lista de comprobación con tres prioridades
A continuación, desglosamos las tres prioridades en aspectos concretos que puedes evaluar. Los criterios propuestos son recomendaciones elaboradas para este artículo a partir del caso, no procedimientos específicos publicados por Cisco.
Paso 1: identifica los dos tipos de datos necesarios para la seguridad de agentes
Antes de hablar de detección, comprueba qué datos tienes disponibles. Muchos equipos cuentan con una telemetría de seguridad completa, pero apenas registran el comportamiento interno de sus agentes. Sin esa información, resulta difícil determinar si un agente ha cometido un error pese a tener buenas intenciones.
| Categoría de datos | Contenido habitual | Pregunta principal que responde | Dónde suelen recopilarse |
|---|---|---|---|
| Telemetría de seguridad | Conexiones de red, uso de credenciales, cargas útiles anómalas, registros de acceso denegado | ¿Hay interferencias maliciosas externas? | Pasarelas, cortafuegos, sistemas de identidad |
| Datos de observabilidad | Objetivos de la tarea, secuencia de llamadas a herramientas, entradas y salidas de cada paso, tiempos y reintentos | ¿Qué está haciendo el agente y por qué? | Frameworks de agentes, punto de entrada para la invocación del modelo |
| Contexto de negocio | Solicitante de la tarea, alcance de la autorización, ventana de cambios | ¿Está esta acción dentro de lo previsto? | Sistemas de tickets, flujos de aprobación |
| Metadatos de invocación del modelo | Modelo invocado, hora de la solicitud, identidad del solicitante, consumo de tokens | ¿Son las invocaciones inusualmente frecuentes o provienen de una fuente sospechosa? | Punto de entrada unificado de API de modelos, como las interfaces agregadoras de APIYI apiyi.com |
Hay un detalle que suele pasarse por alto: el propio punto de entrada de las invocaciones es un buen lugar para recopilar datos de observabilidad. Si varios agentes del equipo se conectan directamente a interfaces de distintos proveedores, los registros quedan dispersos. En cambio, al acceder a modelos de varios proveedores mediante una interfaz unificada como APIYI, las invocaciones se concentran en un solo punto, lo que facilita etiquetar y conservar los registros, así como realizar análisis de correlación.
Paso 2: definir los puntos de control de seguridad del agente
Cuanto antes se intercepte una acción, menor será el costo, pero también aumentará el riesgo de bloquear tareas legítimas. Conviene definir los puntos de control y los requisitos de tiempo de respuesta según el nivel de riesgo de cada acción.
| Punto de control | Comprobaciones habituales | Requisito de tiempo de respuesta | Medida |
|---|---|---|---|
| Al recibir la entrada | Si las páginas web externas, los correos o los documentos contienen instrucciones de inyección | Síncrono, antes de la ejecución | Eliminar o marcar el contenido no confiable |
| Antes de invocar una herramienta | Si la llamada excede la autorización de la tarea o si sus parámetros sobrepasan los permisos | Síncrono, de milisegundos a segundos | Rechazar, limitar o solicitar confirmación humana |
| Antes de una acción de alto riesgo | Cambiar configuraciones, eliminar datos, enviar información al exterior o ampliar permisos | Síncrono, con confirmación humana o mediante políticas | Segunda aprobación |
| Después de ejecutar la acción | Si el resultado coincide con el objetivo o si se han producido efectos secundarios | Casi en tiempo real, de segundos a minutos | Revertir la acción o aislar los recursos afectados |
| Revisión posterior | Análisis de la relación entre el historial de acciones y los incidentes de seguridad | Sin conexión | Actualizar políticas y reglas |
La importancia de actuar «casi en tiempo real» se ve especialmente clara en esta tabla. Para las acciones irreversibles, la detección debe producirse antes de la ejecución; para las que pueden revertirse, es aceptable detectar el problema casi en tiempo real después de la ejecución y aplicar una reversión rápida. Al dejar claro este límite, el equipo evita caer en el dilema de «bloquearlo todo o permitirlo todo».
Paso 3: preguntas para distinguir entre interferencia maliciosa y comportamiento no previsto
Cuando aparezca una alerta de anomalía, puedes revisar las siguientes preguntas en orden. Para responderlas, combina datos de telemetría de seguridad y de observabilidad:
- ¿Es confiable el origen de la instrucción? ¿La instrucción que provocó la acción vino de un usuario autorizado o de contenido externo que leyó el agente? Si vino de contenido externo, la primera sospecha debería ser un ataque de inyección.
- ¿La acción contribuye al objetivo original? Al compararla con el objetivo de la tarea, ¿puede explicarse razonablemente como una forma de completarla? Si tiene sentido, pero el método excede los límites permitidos, apunta más bien a un comportamiento no previsto.
- ¿Hay señales externas anómalas? Durante el mismo período, ¿hubo conexiones inusuales, uso sospechoso de credenciales o indicios de extracción de datos? Si los hay, aumenta la probabilidad de que se trate de una acción maliciosa.
- ¿Se puede reproducir el comportamiento? Al repetir la prueba con la misma entrada, ¿el agente realiza la misma acción de forma consistente? Si es así, lo más probable es que haya un problema en la estrategia o en el diseño de la indicación.
Para la prueba de reproducción del punto 4, una práctica útil es ejecutar la misma tarea con distintos modelos y observar si la desviación se debe a las características de un modelo concreto o a una falla en el diseño de la tarea. Con la interfaz unificada de APIYI, basta con cambiar el parámetro del nombre del modelo, lo que facilita este tipo de comparaciones rápidas en un entorno de prueba.
🎯 Recomendación técnica: al montar un entorno de pruebas de seguridad para agentes, conviene centralizar la invocación de los modelos en un único punto de entrada. Nosotros usamos APIYI apiyi.com para acceder a varios modelos populares a través de una interfaz unificada. Así, los metadatos de las invocaciones quedan centralizados y cambiar de modelo resulta sencillo, lo que facilita repetir una misma tarea con varios modelos y comparar sus comportamientos.
Cuarto paso: integrar la seguridad en los procesos de escaneo existentes
Patel menciona en el caso que estas capacidades pueden integrarse en los procesos de escaneo existentes, sin que el equipo tenga que cambiar radicalmente su forma de trabajar. Aunque no detalla cómo hacerlo, la idea merece atención: la seguridad de los agentes no exige crear una plataforma aparte, sino incorporar nuevas fuentes de datos y comprobaciones a los procesos actuales.
- Proceso de escaneo de vulnerabilidades: incluir en el inventario de activos y en el alcance del escaneo las herramientas, los plugins y las API que los agentes pueden invocar.
- Proceso de clasificación de alertas: añadir una categoría de alertas de «comportamiento de agentes» al SIEM o sistema de tickets existente, junto con el registro correspondiente de llamadas a herramientas.
- Proceso de gestión de cambios: aplicar a los cambios de configuración iniciados por agentes los mismos mecanismos de aprobación y reversión que a los cambios manuales.
- Proceso de auditoría de permisos: revisar periódicamente los privilegios mínimos de cada agente, junto con la auditoría de las cuentas de servicio.
Lista de comprobación para la seguridad de agentes
Esta lista resume los puntos anteriores para revisarlos uno por uno en la reunión previa al despliegue de un agente.
| Dimensión | Pregunta de comprobación | Prioridad correspondiente |
|---|---|---|
| Confiabilidad de las entradas | ¿Se marca como no confiable el contenido externo que lee el agente? | Protección frente a ataques maliciosos |
| Privilegios mínimos | ¿Cada agente tiene acceso únicamente a las herramientas y conexiones necesarias para completar su tarea? | Protección frente a ataques maliciosos |
| Registro de actividad | ¿Se registran por completo los objetivos de la tarea, la secuencia de invocaciones de herramientas y el resultado de cada paso? | Detección y bloqueo de comportamientos no deseados |
| Acciones de alto riesgo | ¿Las operaciones irreversibles están sujetas a una política o confirmación humana antes de ejecutarse? | Detección y bloqueo de comportamientos no deseados |
| Correlación de datos | ¿Se pueden consultar de forma correlacionada los datos de telemetría de seguridad y observabilidad por tiempo e identidad? | Base común para las tres prioridades |
| Latencia de detección | ¿El tiempo transcurrido entre una acción y la generación de una alerta cumple los requisitos de la clasificación de riesgos? | Operación casi en tiempo real |
| Capacidad de aislamiento | ¿Se puede aislar un solo agente sin afectar a los demás servicios? | Operación casi en tiempo real |
Si la respuesta a cualquiera de estas preguntas es «no», existe una brecha en la prioridad correspondiente. Conviene abordar primero el «registro de actividad» y la «correlación de datos»: sin ellos, las demás detecciones carecen de una base para evaluar lo ocurrido.
Preguntas frecuentes
Q1: ¿Qué significa que un agente «cause problemas con buenas intenciones»?
Ocurre cuando un agente, sin estar bajo ataque, persigue un objetivo legítimo de una forma no prevista; por ejemplo, al modificar una configuración sin autorización para terminar antes una tarea. El caso lo describe como «un agente que persigue objetivos legítimos de maneras no previstas» y lo distingue de la interferencia maliciosa.
Q2: ¿En qué se diferencia la seguridad de los agentes de la seguridad tradicional de aplicaciones?
La seguridad tradicional de aplicaciones se centra en prevenir ataques externos y suele tener rutas de comportamiento relativamente fijas. Los agentes deciden de forma autónoma qué herramientas usar y en qué orden, por lo que sus rutas de comportamiento no son fijas. Además de prevenir ataques, hay que detectar sus propios comportamientos no previstos y contar con datos de observabilidad para entender sus intenciones.
Q3: ¿Cuándo se publicó el caso de Cisco y son fiables sus conclusiones?
OpenAI publicó el caso el 3 de noviembre de 2026. Su contenido sobre seguridad de agentes recoge principalmente las opiniones de Jeetu Patel. Valoraciones como «mejora sustancial» no van acompañadas de datos cuantitativos, como tiempos de resolución o tasas de detección. Tampoco se especifican las funciones concretas ni el alcance de disponibilidad de Daybreak y Daybreak Defense Network. Conviene tomarlo como referencia y verificar los resultados por cuenta propia.
Q4: ¿Para qué escenarios es más adecuado este marco?
– **Agentes de operaciones**: escenarios en los que pueden cambiar configuraciones, reiniciar servicios o ajustar políticas de acceso.
– **Agentes de procesamiento de datos**: escenarios en los que leen documentos externos, correos o páginas web y actúan en función de su contenido. El riesgo de inyección de indicaciones es mayor.
– **Flujos de colaboración entre varios agentes**: escenarios en los que la salida de un agente se convierte en la entrada de otro y las anomalías pueden amplificarse de una etapa a otra.
Q5: ¿Cómo se pueden comprobar a bajo costo las diferencias de comportamiento de un agente entre distintos modelos?
En un entorno de prueba, ejecuta la misma tarea con el mismo conjunto de herramientas, cambiando de modelo en cada ejecución. Después, compara las secuencias de llamadas a herramientas y el número de veces que se exceden los límites establecidos. Al acceder a modelos de distintos proveedores a través de APIYI apiyi.com, basta con cambiar el nombre del modelo. Además, los registros de llamadas quedan concentrados en un mismo punto de acceso, lo que facilita organizar y comparar los resultados.
Q6: ¿Para qué sirven los registros de invocación del modelo en la seguridad de los agentes?
Son una parte importante de los datos de observabilidad. Ayudan a determinar si las llamadas se producen con una frecuencia anómala y si quien las realiza es confiable, además de permitir correlacionarlas temporalmente con la telemetría de seguridad. Si el equipo centraliza las invocaciones del modelo en una plataforma de agregación como APIYI, resulta más fácil recopilar y correlacionar estos datos.
Q7: ¿Qué limitaciones tiene este marco?
Las tres prioridades son principios orientativos y no incluyen reglas de detección listas para usar. En los casos límite, distinguir entre comportamientos maliciosos y no previstos sigue requiriendo criterio humano. El bloqueo en tiempo casi real añade latencia, por lo que hay que evaluar el equilibrio según el nivel de riesgo de cada acción. La evidencia del caso procede de material promocional de un cliente y carece de una evaluación independiente.
Puntos clave sobre la seguridad de los agentes
- Distingue dos tipos de riesgo: una interferencia maliciosa y un error cometido con buena intención requieren respuestas completamente distintas.
- Combina dos tipos de datos: la telemetría de seguridad revela amenazas externas; los datos de observabilidad ayudan a entender la intención del agente.
- Tres prioridades: protegerse frente a ataques maliciosos, detectar y bloquear comportamientos no previstos, y operar casi en tiempo real.
- Ajusta el punto de intervención al riesgo: bloquea las acciones irreversibles antes de que se ejecuten y revierte rápidamente las acciones recuperables después de su ejecución.
- Distingue el tipo de evidencia: las conclusiones del caso son útiles como referencia, pero aún no hay datos públicos que respalden resultados cuantificados.
- Primer paso: centraliza la invocación del modelo en un punto de acceso que agrupe servicios, como APIYI, para facilitar la recopilación de metadatos y las pruebas comparativas entre modelos.
Conclusión
Al analizar la seguridad de los agentes a partir del caso de Cisco, lo más valioso no es el nombre de un producto, sino un marco claro para abordar el problema:
- Primero, distingue la intención: determinar si una anomalía se debe a un ataque o a un error cometido con buena intención define cómo responder.
- Después, reúne los datos necesarios: sin datos de observabilidad, no puedes determinar la intención del agente; sin telemetría de seguridad, no puedes descartar interferencias externas.
- Por último, controla la latencia: define el punto de intervención según el riesgo de cada acción, de modo que la detección y el bloqueo se realicen casi en tiempo real y se integren con los procesos existentes de análisis y aprobación.
Te recomendamos revisar los agentes que ya tienes en funcionamiento con la lista de comprobación de este artículo y priorizar el registro de comportamiento y la correlación de datos. Durante las pruebas y comparaciones, puedes usar APIYI apiyi.com para acceder a modelos de distintos proveedores desde un mismo lugar, recopilar registros de invocación y comparar rápidamente su comportamiento. Así tendrás una base más sólida para la evaluación previa al despliegue.
📚 Referencias
- How Cisco defends at machine speed with OpenAI: caso de cliente de Cisco publicado por OpenAI
- Enlace:
openai.com/index/cisco-cyber - Nota: fuente de las tres prioridades y las opiniones relacionadas de este artículo. Publicado el 3 de noviembre de 2026, es material promocional sobre un cliente; los datos cuantitativos y los detalles del producto deben verificarse por separado.
Autor: equipo técnico de APIYI
Intercambio técnico: puedes contactarnos desde la página de inicio de APIYI apiyi.com. Para más información, visita el centro de documentación en docs.apiyi.com.
