Okta anunció Blueprint Alliance el 22 de septiembre de 2026 con miembros fundadores que incluyen AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Proofpoint, Salesforce, ServiceNow, Wiz y Zscaler. La coalición dice que impulsa una arquitectura de referencia abierta y multi proveedor para asegurar agentes de IA en identidad, datos, aplicaciones, infraestructura, redes, endpoints y operaciones de seguridad.
Esta es la historia de seguridad de IA más sólida de este ciclo porque no es otra afirmación aislada de un proveedor sobre guardrails. Describe una arquitectura compartida para la empresa agentic y nombra con claridad el problema de seguridad: los agentes necesitan identidad, autoridad limitada, visibilidad en tiempo de ejecución y contención entre sistemas que no controlan.
Qué propuso la alianza
El anuncio plantea cuatro preguntas operativas para empresas: dónde están mis agentes, qué pueden hacer, qué están haciendo y cómo respondo. Esa secuencia es útil porque empieza antes de la aplicación en tiempo de ejecución. Un equipo no puede monitorear, contener o auditar un agente que no ha identificado.
La arquitectura propuesta incluye descubrimiento e identidad de agentes, gestión de postura de seguridad, políticas de acceso limitadas a la tarea, delegación trazable, autorización en línea en tiempo de ejecución, monitoreo, seguimiento de recursos aguas abajo, contención dirigida y recuperación por etapas. También menciona interoperabilidad mediante MCP, OCSF, SSF y CAEP para que un plano de control pueda compartir señales con otro.
Proofpoint describió por separado su incorporación a la alianza y enmarcó la seguridad de agentes como un problema de ecosistema. Su publicación señaló que los agentes pueden actuar en nombre de usuarios o procesos, acceder a permisos delegados, recuperar datos sensibles, llamar APIs y continuar de forma asíncrona después de que el humano que inició la tarea cerró sesión.
Por qué la identidad no basta
La identidad es el punto de partida, no el final. Un agente registrado con nombre y propietario aún puede excederse si conserva acceso permanente, crea subagentes sin trazabilidad o usa autoridad delegada fuera de la tarea actual.
Por eso importa el acceso limitado a la tarea. La pregunta no es solo si el agente es conocido. Es si este agente, actuando para este usuario, bajo esta tarea, puede acceder ahora a esta herramienta, almacén de datos o sistema de pagos. La guía de flujos de aprobación de Maetra aplica el mismo principio en el límite de la acción: la autoridad debe estar ligada al sobre de acción, no concederse como un permiso permanente vago.
La alianza también reconoce que la visibilidad debe incluir recursos aguas abajo. Servidores MCP, aplicaciones SaaS, almacenes de datos y sistemas de pago definen el verdadero radio de impacto. Sin ese mapa, los equipos de seguridad solo saben que un agente actuó, no qué podía afectar.
El problema de auditoría detrás de la seguridad de agentes
La capa de respuesta de la arquitectura de referencia es especialmente importante. La contención mediante revocación de tokens, terminación de sesión o cuarentena de red puede detener daño, pero también necesita evidencia. ¿Quién contuvo el agente? ¿Qué señal activó la respuesta? ¿Qué acceso fue retirado? ¿Cómo se aprobó la recuperación? ¿Qué cambió después de la reincorporación?
La guía de Maetra sobre registros de auditoría de IA trata esas preguntas como registros operativos. Para seguridad de agentes, el rastro de auditoría debe incluir identidad del agente, propietario humano, tarea, autoridad delegada, llamada de herramienta, decisión de política, señal de riesgo, acción de contención y efecto observado.
Qué sigue siendo incierto
El anuncio es un lanzamiento de alianza y una declaración de arquitectura. Las fuentes públicas revisadas aquí no prueban interoperabilidad en producción entre todos los miembros, no muestran pruebas conjuntas de conformidad, no publican implementaciones de referencia detalladas y no establecen que la arquitectura haya prevenido incidentes en entornos de clientes.
Ese límite importa. La alianza es útil porque da a compradores un modelo concreto de control para exigir. No es una certificación y no debe tratarse como garantía independiente de ningún producto.
Análisis de Maetra
Blueprint Alliance refleja hacia dónde se dirige la seguridad de agentes de IA. El riesgo principal no son solo prompts maliciosos o modelos inseguros. Es autoridad compuesta entre sistemas de identidad, plataformas de datos, endpoints, aplicaciones SaaS, recursos cloud y herramientas de tiempo de ejecución.
Para equipos de seguridad, la conclusión práctica es tratar a los agentes como actores responsables con tareas limitadas y efectos observables. Construyan primero el inventario. Vinculen el acceso a la tarea. Monitoreen lo que hace el agente en sesión. Sigan el recurso aguas abajo, no solo el modelo. Conserven evidencia de cada decisión de política y cada paso de contención.
Eso convierte la seguridad de agentes de un panel de prompts en una arquitectura de autoridad. También da a los equipos de cumplimiento y auditoría algo que inspeccionar después de la acción, que es donde muchos programas de agentes siguen siendo débiles.