CrowdStrike Blueprint Alliance enfrenta la unidad de proveedores a la brecha de identidad de los agentes de IA
CrowdStrike se unió a otros 11 proveedores fundadores en una nueva alianza construida en torno a un conflicto que las empresas ya no pueden evitar. Los agentes de IA necesitan un acceso amplio para ser útiles, pero ese mismo acceso dificulta su gobernanza. CrowdStrike Blueprint Alliance busca cerrar esta brecha mediante una arquitectura de seguridad compartida.
La coalición, denominada formalmente Blueprint Alliance, se lanzó el 22 de septiembre de 2026. Sus miembros abarcan identidad, infraestructura cloud, ciberseguridad, plataformas de datos, desarrollo de aplicaciones y software empresarial. Esa amplitud importa porque un agente puede atravesar varios de esos ámbitos al completar una sola tarea.
El anuncio es más que otra asociación de CrowdStrike sobre seguridad de agentes de IA. Pide a proveedores que compiten por presupuestos empresariales que respalden un modelo operativo común. Ese modelo trata a los agentes como actores identificables con autoridad limitada, delegación rastreable, monitorización continua y contención reversible.
La cuestión más difícil es si los principios compartidos se convertirán en controles interoperables. Las empresas necesitan más que un acuerdo entre proveedores sobre la terminología. Necesitan comportamientos coherentes de descubrimiento, autorización, registro y apagado en productos que no fueron diseñados como un único sistema.
CrowdStrike Blueprint Alliance conecta 12 partes de la pila de agentes
La alianza convierte la seguridad de los agentes de IA de una función a nivel de producto en un problema de arquitectura entre proveedores.
Los 12 miembros fundadores son AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Okta, Proofpoint, Salesforce, ServiceNow, Wiz y Zscaler. GE Appliances y World Central Kitchen actúan como asesores estratégicos.
Según el anuncio oficial de la alianza, los miembros desarrollarán una arquitectura de referencia abierta y multivendor. El trabajo amplía un plan de seguridad que Okta presentó por primera vez en marzo de 2026.
La arquitectura parte de cuatro preguntas operativas:
¿Dónde están los agentes de la organización?
¿Qué puede hacer cada agente?
¿Qué está haciendo cada agente?
¿Cómo deberían responder los defensores?
Estas preguntas parecen básicas. La mayoría de las empresas no puede responderlas de forma coherente en cuentas cloud, plataformas de software, entornos de desarrollo, sistemas de datos y herramientas instaladas por empleados.
Un agente de IA es software capaz de interpretar un objetivo, recopilar contexto, seleccionar herramientas y ejecutar acciones con supervisión limitada. Un agente de atención al cliente podría leer un ticket de soporte, revisar el historial de una cuenta, aprobar un reembolso y actualizar un registro de CRM.
Cada paso introduce un punto de control diferente. El agente necesita una identidad antes de autenticarse. Necesita autorización antes de acceder a un registro de cliente. Sus acciones requieren monitorización mientras se ejecuta la tarea. Su acceso debe revocarse cuando esta termina.
Los principios fundacionales reflejan esa secuencia. Los miembros afirman que cada agente debería recibir una identidad de primera clase en lugar de utilizar una credencial humana. El acceso debería limitarse a una tarea, en vez de concederse de forma permanente. La delegación debería seguir siendo rastreable cuando un agente llama a otro.
La alianza también pide monitorización continua en tiempo de ejecución. Esta monitorización observa lo que hace un agente mientras opera, en lugar de depender solo de una aprobación previa a la ejecución. Si el comportamiento se vuelve inseguro, la contención debería ser inmediata y reversible.
CrowdStrike entra en este acuerdo desde el ámbito de la detección y respuesta de la seguridad empresarial. Okta aporta controles de identidad, mientras que AWS y Google Cloud representan la infraestructura. Salesforce y ServiceNow gestionan entornos de aplicaciones en los que los agentes pueden iniciar acciones empresariales.
Databricks cubre la infraestructura de datos, mientras que Docker y Lovable intervienen en los flujos de desarrollo y despliegue. Proofpoint, Wiz y Zscaler añaden controles en torno a las comunicaciones, la exposición cloud y el acceso a redes.
Esta división de funciones explica por qué ningún miembro puede proporcionar toda la arquitectura. Una plataforma de identidad puede autenticar a un agente, pero no puede ver automáticamente cada acción posterior. Un producto de seguridad de endpoints o cloud puede detectar comportamientos sospechosos sin controlar todos los permisos previos.
Por tanto, la alianza parte de un diagnóstico creíble. La seguridad de los agentes abarca sistemas propiedad de distintos equipos y suministrados por distintos proveedores. La cuestión sin resolver es si esos proveedores conectarán sus controles con la suficiente profundidad como para que la gobernanza sea continua.
Por qué los agentes de IA convierten problemas conocidos de acceso en fallos más rápidos
Los agentes amplifican antiguas debilidades de identidad porque pueden reutilizar permisos, encadenar acciones y operar durante más tiempo que una sesión humana.
La automatización empresarial tradicional ya utiliza cuentas de servicio, claves de API e identidades de cargas de trabajo. Los equipos de seguridad saben lo difíciles que pueden volverse esas credenciales cuando la propiedad no está clara o los permisos siguen activos indefinidamente.
Los agentes de IA añaden rutas de decisión inciertas a ese problema existente. Su siguiente acción puede depender de la salida del modelo, contenido recuperado, respuestas de herramientas o instrucciones proporcionadas por otro agente. El software puede cambiar de ruta sin modificar su objetivo declarado.
Esa flexibilidad es la fuente de la utilidad de un agente. También explica por qué un acceso amplio y permanente supone un riesgo especialmente grave. Un agente comprometido o manipulado puede utilizar permisos válidos mientras actúa fuera de la intención del operador.
NIST ha identificado este problema de identidad como una prioridad. Su iniciativa de estándares para agentes abarca seguridad, identidad, interoperabilidad y estándares liderados por la industria para agentes autónomos.
La agencia describe a los agentes como sistemas capaces de realizar acciones autónomas en correo electrónico, calendarios, desarrollo de software, compras y otros flujos de trabajo. Su utilidad depende de conexiones con sistemas externos y datos internos.
Estas conexiones plantean varias preguntas superpuestas. ¿Puede la organización distinguir a un agente del empleado que lo inició? ¿Puede identificar al propietario del agente y el origen de su software? ¿Puede demostrar qué autoridad respaldó una acción concreta?
El intercambio de credenciales dificulta estas respuestas. Un empleado podría conectar un asistente mediante un token empresarial personal. Las aplicaciones posteriores ven entonces la identidad del empleado, incluso cuando un agente seleccionó y ejecutó la acción.
Esa disposición debilita la rendición de cuentas. La aplicación puede registrar una solicitud válida del usuario sin revelar si una persona aprobó la transacción específica. Los investigadores de seguridad reciben un registro técnicamente preciso que carece del contexto más importante.
El riesgo crece cuando los agentes delegan trabajo. Un agente principal podría llamar a un agente especializado, que después invoca una herramienta a través de un servicio independiente. Cada transferencia puede ocultar al usuario original, la tarea aprobada y el alcance restante.
El acceso a nivel de tarea ofrece un modelo mejor. Un agente recibe solo los recursos y acciones necesarios para una asignación. La autoridad expira cuando la tarea se completa, cambia de forma sustancial o incumple una condición definida.
Sin embargo, el mínimo privilegio se vuelve más difícil cuando la ruta requerida no es totalmente predecible. Un agente de investigación puede descubrir que necesita una fuente de datos después de iniciar su trabajo. Conceder todos los permisos posibles anula el propósito de limitar el alcance de la tarea.
Por tanto, las empresas necesitan autorización dinámica. Un sistema de políticas debe evaluar la identidad, la tarea, el recurso, el contexto y la acción solicitada a medida que cambia el flujo de trabajo. Los pasos de alto riesgo pueden requerir una nueva aprobación sin detener cada acción rutinaria.
Esta es la presión que explica Blueprint Alliance en términos prácticos. Las empresas quieren agentes que puedan actuar en entornos de software fragmentados. Los equipos de seguridad necesitan que esas acciones sigan siendo atribuibles y delimitadas en cada transferencia.
La principal disyuntiva es entre acceso útil y autoridad controlable
La alianza solo tendrá éxito si limita la autoridad de los agentes sin convertir cada flujo de trabajo en una aprobación humana repetida.
Un agente sin acceso a sistemas es poco más que una interfaz conversacional. Un agente con acceso sin restricciones puede convertirse en un administrador sin supervisión. Los despliegues empresariales deben operar entre esos dos extremos.
Consideremos un agente que prepara una actualización semanal de ventas. Podría leer registros de CRM, recuperar datos de productos, analizar reuniones recientes, redactar recomendaciones y publicar un resumen. Ese flujo de trabajo atraviesa información propiedad de varios sistemas y equipos empresariales.
El agente no necesita autoridad para eliminar registros de clientes ni cambiar territorios de ventas. Puede necesitar acceso de lectura a detalles de cuentas, pero solo permiso temporal para publicar un documento. Su alcance debería seguir la tarea.
La identidad proporciona el ancla para esas decisiones. La organización necesita un registro único para el agente, su propietario, su desarrollador y sus capacidades aprobadas. Esa identidad debería seguir siendo visible cuando el agente delega parte del trabajo.
La guía de identidad de NIST señala que los agentes deberían tener identificadores, credenciales y derechos únicos. Estas propiedades deberían permanecer conectadas a la persona o sistema que opera el agente.
Las tecnologías existentes ofrecen parte de la base. OAuth puede delegar acceso limitado sin compartir una contraseña. Los sistemas de identidad de cargas de trabajo pueden autenticar procesos de software. Los motores de políticas pueden evaluar el acceso a recursos frente a condiciones definidas.
Sin embargo, estas herramientas no capturan automáticamente la intención de un agente. Un token válido puede mostrar que el software tenía permiso para llamar a una API. No demuestra que la acción resultante coincidiera con la tarea que aprobó un usuario.
Esa distinción separa la autenticación de la gobernanza. La autenticación responde quién o qué presentó una credencial. La autorización determina qué puede hacer esa identidad. La gobernanza vincula esos permisos con propiedad, propósito, supervisión y revisión.
El comportamiento en tiempo de ejecución añade otra capa. Un agente podría comenzar dentro de la política y después recuperar instrucciones maliciosas de un documento. La inyección indirecta de prompts ocurre cuando contenido no confiable manipula un modelo mediante datos que se pidió al agente procesar.
Una arquitectura segura debe asumir que la aprobación previa a la ejecución no basta. La monitorización debería comparar las acciones del agente con su tarea declarada y sus límites permitidos. Los defensores también necesitan poder pausar o finalizar la ejecución.
La reversibilidad es especialmente importante. Detener un agente evita acciones adicionales, pero no deshace un mensaje, un cambio en una base de datos o una transacción externa. Los sistemas necesitan mecanismos de reversión siempre que la aplicación subyacente los admita.
Algunas acciones no pueden revertirse. Un secreto divulgado no puede volver a ser privado. Un pago enviado fuera de la organización podría no regresar de inmediato. Un comando destructivo puede eliminar datos antes de que la monitorización genere una alerta.
Blueprint Alliance no puede resolver estas limitaciones específicas de cada aplicación con un único control. Puede definir cómo los productos intercambian señales de identidad, autorización, telemetría y respuesta. Cada plataforma aún debe aplicar la acción pertinente.
Por eso la tensión principal es una disyuntiva, no una simple brecha técnica. Un acceso más amplio aumenta lo que los agentes pueden lograr. Restricciones más fuertes reducen la exposición, pero también pueden interrumpir flujos de trabajo e incrementar la carga de aprobaciones.
El mejor resultado no es una autonomía ilimitada ni una confirmación humana constante. Es una autonomía condicional, en la que las acciones de bajo riesgo avanzan y los pasos sensibles activan controles más estrictos. Lograr ese equilibrio entre 12 proveedores exige más que un acuerdo sobre principios.
La seguridad de agentes de IA de CrowdStrike ahora abarca varias alianzas
CrowdStrike está construyendo una posición amplia en seguridad de agentes, pero las coaliciones superpuestas también pueden generar confusión sobre los entregables.
La Blueprint Alliance es distinta de la Open Secure AI Alliance, a la que CrowdStrike se unió a principios de 2026. Los nombres suenan parecidos y ambas abordan la seguridad de la IA, pero sus enfoques declarados difieren.
CrowdStrike se describió como socio inaugural de la coalición de seguridad abierta el 27 de julio. Esta iniciativa respaldada por Nvidia pone el foco en modelos abiertos, investigación compartida, herramientas de seguridad, evaluación y defensa colectiva.
La Blueprint Alliance se centra más específicamente en una arquitectura multivendedor para agentes empresariales. Sus temas centrales son el descubrimiento, la identidad, el acceso limitado por alcance, la delegación trazable, la supervisión en tiempo de ejecución y la contención.
CrowdStrike también ofrece sus propios productos de creación y seguridad de agentes. Charlotte AI AgentWorks permite a las organizaciones crear agentes de seguridad personalizados dentro de la plataforma Falcon. CrowdStrike afirma que el entorno incluye gobernanza y mecanismos de protección.
El ecosistema AgentWorks de la empresa admite modelos e infraestructura de varios proveedores. Esto otorga a CrowdStrike un interés comercial directo en las reglas que rigen los agentes empresariales.
La participación en productos, asociaciones bilaterales y coaliciones puede reforzar la influencia de CrowdStrike. Le da a la empresa acceso a varias capas de discusión técnica, desde la investigación abierta sobre seguridad hasta la aplicación de controles empresariales.
También puede fragmentar la atención. Las empresas se enfrentan ahora a múltiples alianzas, marcos, arquitecturas de producto y estándares propuestos. Un vocabulario similar no garantiza una implementación compatible.
Una arquitectura de referencia documenta componentes y relaciones. No proporciona necesariamente un protocolo, una certificación, una suite de pruebas ni una integración de producción. Los compradores deben distinguir entre el acuerdo arquitectónico y la interoperabilidad demostrada.
La amplitud de la Blueprint Alliance es una ventaja si los miembros aportan conexiones funcionales entre sus sistemas. Se convierte en una debilidad si cada proveedor adapta los principios a productos existentes sin un comportamiento técnico común.
Por ejemplo, todos los miembros pueden respaldar la idea del descubrimiento de agentes mientras utilizan identificadores y formatos de inventario diferentes. Todos pueden apoyar la contención mientras exponen controles de apagado incompatibles.
El grupo necesitará definiciones concretas. ¿Qué se considera un agente? ¿Cómo se registra un subagente efímero? ¿Qué sistema posee la identidad autorizada? ¿Cómo viaja la autoridad delegada entre límites de nube y aplicaciones?
También necesita un modelo de eventos común. La supervisión en tiempo de ejecución es menos útil si un producto no puede interpretar la telemetría de otro. La respuesta a incidentes se ralentiza cuando los equipos deben reconstruir cadenas de identidad y autorización a partir de registros no relacionados.
La validación independiente también será importante. Los proveedores fundadores tienen incentivos para moldear un mercado emergente en torno a sus plataformas. Su participación es valiosa, pero no sustituye las pruebas realizadas por clientes, investigadores u organismos de normalización.
Los asesores estratégicos GE Appliances y World Central Kitchen pueden ayudar a mantener el trabajo vinculado a operaciones reales. Los entornos de fabricación, la logística humanitaria y el software empresarial generan distintos niveles de tolerancia al retraso, la autonomía y el fallo.
Aun así, dos asesores no pueden representar todos los modelos de despliegue. Las transacciones financieras, los flujos de trabajo sanitarios, el desarrollo de software y los agentes de consumo plantean requisitos de responsabilidad distintos. La arquitectura debe seguir siendo adaptable sin volverse imprecisa.
Para los compradores empresariales, la respuesta prudente es interés sin presunciones. La lista de miembros indica que los principales proveedores reconocen un problema compartido. Aún no demuestra que sus productos funcionen como un único sistema gobernado.
Una arquitectura de referencia todavía no es un estándar exigible
La mayor incertidumbre es si la alianza publicará interfaces comprobables en lugar de un documento de diseño alineado con los proveedores.
El anuncio de lanzamiento establece principios y una estructura de coalición. No establece un estándar obligatorio. Tampoco describe una autoridad de certificación ni un proceso de cumplimiento vinculante.
Esta distinción importa porque las arquitecturas voluntarias pueden mejorar la planificación sin cambiar el comportamiento de los productos. Una empresa puede afirmar que se alinea con conceptos amplios como el mínimo privilegio y la supervisión continua, mientras los implementa de manera diferente.
La escala proyectada de la alianza también merece una atribución cuidadosa. Su anuncio cita una predicción de Gartner según la cual una empresa global promedio del Fortune 500 utilizará más de 150.000 agentes para 2028. También afirma que solo el 13 por ciento de las organizaciones cree contar con una gobernanza adecuada.
Estas cifras se presentaron a través del anuncio de la coalición. Incluso si el número de agentes crece rápidamente, la definición de agente afectará de forma importante a cualquier total. Los asistentes persistentes, los subagentes de corta duración, las automatizaciones y las invocaciones de herramientas no deberían contarse indistintamente.
El descubrimiento se vuelve difícil antes de que una organización alcance siquiera algo cercano a esa escala. Los empleados pueden autorizar asistentes externos sin un despliegue centralizado. Los desarrolladores pueden crear agentes temporales durante las pruebas. Los productos SaaS pueden añadir agentes integrados mediante actualizaciones rutinarias.
Por tanto, un inventario debe combinar varias señales. Los sistemas de identidad pueden mostrar credenciales y autorizaciones de aplicaciones. Las plataformas en la nube pueden mostrar cargas de trabajo. Las herramientas de seguridad pueden observar procesos, actividad de red y comportamiento de API.
Ninguna señal individual captura de forma fiable todos los agentes. Un agente puede existir brevemente, usar una credencial compartida u operar dentro de otra aplicación. Por eso tiene sentido la estructura multivendedor de la alianza.
Sin embargo, la interoperabilidad introduce sus propias cuestiones de confianza. Los proveedores deben decidir qué datos de identidad, contexto de autorización y telemetría de comportamiento intercambiarán. Los clientes necesitarán controles sobre cuánta información sensible se mueve entre plataformas.
Los falsos positivos presentan otro riesgo. La contención automatizada puede interrumpir trabajo legítimo si la supervisión interpreta erróneamente una acción inusual. Una contención débil deja activo a un agente peligroso. La arquitectura necesita formas de calibrar la respuesta según el impacto y la confianza.
Los controles humanos también requieren un diseño cuidadoso. Exigir aprobación para cada decisión elimina gran parte del beneficio de productividad. Permitir que los operadores aprueben categorías amplias puede recrear el acceso permanente bajo otro nombre.
La coalición debería definir propiedades medibles. Un producto participante podría demostrar que conserva el historial de delegación a lo largo de una transferencia. Otra prueba podría verificar que la autoridad revocada detiene el acceso a través de servicios conectados dentro de un intervalo establecido.
Las suites de pruebas permitirían a los clientes comparar implementaciones. Los esquemas compartidos ayudarían a las plataformas a intercambiar datos de inventario y actividad. La certificación podría mostrar que un producto cumple requisitos básicos sin implicar seguridad completa.
La alianza también debería documentar el comportamiento ante fallos. La arquitectura de seguridad suele describir la ruta prevista y prestar menos atención a servicios de políticas no disponibles, telemetría retrasada o revocación parcial.
Un agente no debería obtener una autoridad más amplia porque un control se vuelva inaccesible. Sin embargo, una respuesta de denegación por defecto puede detener procesos empresariales esenciales. El modo de fallo apropiado depende de la tarea y sus consecuencias.
Hasta que aparezcan estos mecanismos, la Blueprint Alliance seguirá siendo una propuesta seria en lugar de una capa de seguridad verificada. Su valor reside en alinear a las categorías adecuadas de proveedores en torno a las preguntas adecuadas. La ejecución determinará si esa alineación cambia el riesgo.
Tres señales mostrarán si la alianza puede cumplir
La siguiente prueba no es otro anuncio de miembros, sino evidencia de que la arquitectura funciona entre productos operados de forma independiente.
La primera señal es una especificación técnica publicada. La alianza debería definir campos de identidad de agentes, registros de delegación, contexto de autorización, formatos de telemetría e interfaces de respuesta.
Una especificación detallada reforzaría la idea de que los miembros pretenden crear controles compartidos. Un marco de alto nivel con asignaciones específicas por producto la debilitaría, porque los clientes aún necesitarían integración personalizada.
La segunda señal es una demostración funcional multivendedor. Un ejemplo creíble debería seguir a un agente a través de sistemas de identidad, nube, datos, aplicaciones y seguridad.
La demostración debería mostrar permisos limitados a la tarea, trabajo delegado, supervisión en tiempo de ejecución y revocación. También debería mostrar cómo los investigadores reconstruyen la cadena después de una acción insegura.
Esta evidencia revelaría si la seguridad de agentes de IA de CrowdStrike puede consumir contexto de identidad y actividad de otros miembros de la alianza. También mostraría si esos sistemas pueden actuar sobre las detecciones de CrowdStrike.
La tercera señal son las pruebas independientes. NIST, socios empresariales de diseño, investigadores de seguridad u otro grupo neutral deberían evaluar cómo la arquitectura gestiona el uso compartido de credenciales, la inyección indirecta de prompts, los permisos excesivos y los agentes comprometidos.
Los resultados independientes reforzarían las afirmaciones de seguridad de la alianza. Las pruebas retrasadas, las demostraciones cerradas o la autoevaluación por sí solas dejarían sin resolver la cuestión central.
Los compradores no necesitan esperar antes de mejorar sus propios controles. Pueden inventariar los agentes actuales, eliminar credenciales compartidas, asignar propietarios claros y reducir los permisos persistentes.
Los equipos también deberían documentar qué acciones requieren aprobación humana y cuáles pueden realizarse automáticamente. Cada flujo de trabajo sensible necesita registros que conecten al agente, el usuario, la tarea, el permiso, la herramienta y el resultado.
Las organizaciones que crean agentes internos pueden conservar materiales de origen, aprobaciones y decisiones operativas en una base de conocimientos de IA con capacidad de búsqueda. Ese registro no sustituye la telemetría de seguridad, pero puede preservar el contexto empresarial detrás de los despliegues de agentes.
La CrowdStrike Blueprint Alliance es importante porque identifica el plano de control que les falta a las empresas. Los agentes deben ser detectables, identificables individualmente, autorizados de manera limitada, observados continuamente y rápidamente contenibles.
Ahora sus miembros deben traducir ese consenso en un comportamiento interoperable. Los equipos empresariales deberían pedir a los proveedores esquemas, pruebas, garantías de revocación y demostraciones multiplataforma. Esas respuestas mostrarán si la alianza está construyendo infraestructura compartida o simplemente un vocabulario compartido.
