La Linux Foundation ha publicado una Solicitud de Comentarios sobre Shared AI Findings Exchange, o SAFE, un marco propuesto para recopilar y compartir información sobre incidentes de ciberseguridad que involucran agentes de IA. La iniciativa está siendo desarrollada por la Open Secure AI Alliance a medida que las empresas pasan de probar modelos a sistemas que pueden acceder a herramientas, datos y aplicaciones empresariales.

NVIDIA, Cisco, CrowdStrike, Hugging Face y Red Hat se encuentran entre las organizaciones que contribuyen a la propuesta, según una entrada de blog de NVIDIA. La alianza afirma que ahora incluye a más de 120 organizaciones. La idea central es convertir informes confidenciales sobre incidentes y cuasi incidentes en orientación basada en evidencia que pueda ayudar a otros desarrolladores a evitar los mismos fallos.

SAFE apunta a la capa operativa de la seguridad de IA

La propuesta SAFE va más allá de la divulgación convencional de vulnerabilidades. Las directrices descritas por NVIDIA piden la recopilación y el análisis confidenciales de incidentes relacionados con IA, la notificación a las partes afectadas, la identificación de fallos de control recurrentes y la publicación de recomendaciones operativas destinadas a reducir el riesgo sistémico.

Ese alcance refleja un cambio en cómo se están construyendo los sistemas de IA. Un agente no es solo un modelo; también puede incluir un arnés de orquestación, controles de identidad, herramientas, restricciones de ejecución, guardrails, sistemas de registro y evaluación. Una debilidad en cualquiera de esas capas puede afectar lo que un agente es capaz de ver, acceder o cambiar.

Para los desarrolladores, un formato compartido de incidentes podría facilitar la comparación de fallos de seguridad de agentes entre productos y despliegues. Hoy en día, la información sobre inyección de prompts, uso indebido de herramientas, credenciales filtradas o acciones autónomas inseguras puede permanecer dentro de empresas individuales. El enfoque propuesto por SAFE pretende crear un mecanismo para compartir lecciones sin exponer de inmediato detalles operativos sensibles.

La propuesta sigue siendo un borrador. El anuncio disponible no especifica la taxonomía completa de informes, el modelo de gobernanza, los requisitos de participación ni el calendario para finalizar las directrices.

La alianza combina la notificación con herramientas abiertas

NVIDIA presentó SAFE junto con un conjunto más amplio de contribuciones de seguridad de miembros de la Open Secure AI Alliance. Sus propios ejemplos incluyen el arnés de investigación NVIDIA Labs Object-Oriented Agent, que según la empresa está diseñado para facilitar las pruebas, el seguimiento y la auditoría del comportamiento de los agentes, y NVIDIA OpenShell, un entorno de ejecución destinado a limitar a qué puede acceder y qué puede hacer un agente.

NVIDIA también destacó Garak, su escáner de vulnerabilidades de código abierto para modelos de lenguaje de gran tamaño, que comprueba problemas como fuga de datos, inyección de prompts y comportamiento de jailbreak. Otras herramientas mencionadas incluyen NeMo Guardrails, NeMo Anonymizer y NeMo Safe Synthesizer, que cubren la aplicación de políticas, la protección de datos sensibles y la generación de datos sintéticos orientados a la privacidad.

Varios miembros de la alianza están aportando herramientas en distintos puntos de la pila. Okta está desarrollando implementaciones de referencia para la identidad y el acceso de agentes mediante Cross App Access. Palo Alto Networks ha contribuido con Agent Guard y Agent Watch desde su plataforma de seguridad de identidad Idira. Red Hat ha introducido asago, un proyecto de código abierto que mapea requisitos de gobernanza a permisos de ejecución y registros de auditoría, según NVIDIA.

Amazon, descrita como un nuevo miembro de la alianza en la publicación, está aportando Strands Agents y Cedar. Strands Agents es un conjunto de herramientas de código abierto para crear agentes, mientras que Cedar es un lenguaje de autorización diseñado para definir y hacer cumplir límites de acceso. Estos proyectos abordan cuestiones de implementación que SAFE por sí solo no puede resolver: qué puede hacer un agente, qué identidad usa y cómo se registran esas decisiones.

La evidencia se basa actualmente en los reportes de los participantes

La noticia central está confirmada por la fuente de NVIDIA: la Linux Foundation ha emitido un RFC para SAFE, y un grupo de trabajo de la Open Secure AI Alliance está contribuyendo a ello. El recuento de miembros y las descripciones de las herramientas participantes también provienen de NVIDIA, un miembro de la alianza con interés directo en promover una infraestructura abierta de seguridad de IA.

La fuente disponible no incluye pruebas independientes de SAFE, evidencia de que el marco haya sido adoptado por empresas, ni demostración de que las herramientas enumeradas reduzcan las tasas de incidentes en producción. Las afirmaciones sobre las capacidades de los productos de NVIDIA y las contribuciones de otros miembros deben tratarse, por tanto, como descripciones de proveedores o participantes, y no como hallazgos de rendimiento verificados de forma independiente.

Tampoco hay todavía indicios de que SAFE se haya convertido en un estándar formal. Un RFC crea una oportunidad de revisión y revisión, pero su valor práctico dependerá de si las organizaciones se ponen de acuerdo sobre qué reportar, cómo anonimizar los incidentes y con qué rapidez llegan los hallazgos útiles a desarrolladores y operadores.

Por qué la propuesta importa para los equipos de IA

Para los equipos de producto que despliegan agentes, el beneficio potencial más importante es el aprendizaje operativo. Una estructura común de reportes podría ayudar a los ingenieros de seguridad a distinguir el comportamiento aislado del modelo de los fallos causados por permisos, integraciones de herramientas, lógica de orquestación o monitorización débil. Esa distinción importa porque cambiar el modelo puede no corregir una vulnerabilidad que existe en el sistema circundante.

Los compradores empresariales también podrían fijarse en un proceso SAFE maduro al evaluar proveedores. Podrían preguntar si un proveedor de IA participa en la divulgación de incidentes, cómo gestiona los cuasi incidentes y si sus controles se vinculan a evidencia concreta. Pero esos beneficios solo se materializarán si el marco produce informes consistentes y accionables, en lugar de advertencias amplias que sean difíciles de aplicar.

La iniciativa también pone de relieve una tensión competitiva en la infraestructura de IA. Las herramientas de seguridad de código abierto pueden mejorar la inspección y la portabilidad, mientras que la notificación compartida puede exponer debilidades repetidas entre proveedores. Al mismo tiempo, las empresas pueden mostrarse reacias a divulgar incidentes que involucren datos de clientes, sistemas propietarios o riesgo reputacional. Las reglas de confidencialidad y gobernanza de SAFE serán centrales para resolver esa tensión.

Qué observar a continuación

La próxima señal será el contenido del proceso de comentarios de la Linux Foundation: en particular, si SAFE define un esquema de incidentes utilizable, protecciones claras para la información sensible y responsabilidades para notificar a las organizaciones afectadas.

Los desarrolladores también deberían vigilar pruebas de implementación y no solo anuncios adicionales de membresía. Indicadores útiles serían informes de incidentes anónimos publicados, integraciones con herramientas de observabilidad y evaluación de agentes, y ejemplos que muestren cómo un hallazgo compartido condujo a un cambio en permisos, controles de ejecución o política de despliegue.

Por último, el mercado necesitará ver si SAFE se conecta con marcos existentes de seguridad y gobernanza, incluidas las directrices de NIST y OWASP, sin crear otra capa de cumplimiento desconectada. La adopción por parte de organizaciones fuera de la alianza fundadora sería una prueba más sólida que el recuento actual de participantes.

Perspectiva de Creati.ai

SAFE aborda una debilidad real en la seguridad de los agentes: se pide a los equipos que gestionen sistemas que pueden actuar a través de modelos, herramientas y recursos empresariales, mientras gran parte del conocimiento disponible sigue fragmentado. Un proceso compartido para incidentes y cuasi incidentes podría hacer que la ingeniería defensiva fuera más acumulativa en lugar de obligar a cada empresa a redescubrir los mismos modos de fallo.

Pero la credibilidad de la propuesta dependerá de su ejecución. El marco necesita reglas de notificación precisas, incentivos para una participación franca y suficiente detalle técnico para producir controles que los desarrolladores puedan realmente implementar. Hasta que esos elementos sean visibles, SAFE se entiende mejor como un importante esfuerzo de normalización, no todavía como una solución de seguridad demostrada.