Databricks: inocente hasta que una política combinada bloquee el riesgo de los agentes en el punto de combinación
Databricks ha publicado un nuevo patrón de seguridad de Omnigent que bloquea a un agente solo después de que tres capacidades individualmente ordinarias formen una cadena peligrosa. El enfoque de Databricks de inocente hasta que se combine apunta al momento en que los datos privados, el contenido no confiable y la comunicación externa quedan disponibles dentro de una misma sesión.
Esa combinación se conoce como la trifecta letal. Un agente puede leer de forma segura un archivo interno, inspeccionar una página web pública o enviar un mensaje cuando cada acción ocurre por separado. Pero al reunir las tres capacidades en una misma ruta de ejecución, una instrucción inyectada puede convertir un acceso legítimo en robo de datos.
El cambio importante no es otra advertencia sobre la inyección de prompts. Databricks traslada la decisión de aplicación fuera del modelo y hacia Omnigent, su meta-arnés de código abierto para ejecutar y gobernar agentes. La capa de políticas recuerda lo que una sesión ha encontrado y luego cambia cómo trata las acciones posteriores.
Los permisos estáticos preguntan si un agente puede llamar a una herramienta. Las políticas contextuales también preguntan qué ocurrió antes de esa llamada. Esta diferencia presiona a los equipos que usan acceso amplio y persistente a herramientas mediante agentes de programación, agentes de navegador e integraciones de Model Context Protocol.
Qué cambió Databricks en Omnigent
Databricks está tratando el historial de un agente como parte de su conjunto efectivo de permisos.
El caso de estudio de seguridad de la empresa amplía una serie de publicaciones sobre políticas contextuales en Omnigent. Los ejemplos anteriores se centraron en el estado de sesión, los ataques de desarrollo lento y la autorización vinculada a la intención original del usuario.
El ejemplo más reciente aplica ese modelo a la trifecta letal. El investigador de seguridad Simon Willison definió el patrón en junio de 2025 como acceso a datos privados, exposición a contenido no confiable y un canal de comunicación externo. Su modelo de amenazas advierte que combinar los tres ofrece a las instrucciones inyectadas una vía para robar información.
Omnigent se sitúa por encima de un arnés de agentes, el entorno de ejecución que gestiona el modelo, las herramientas y el ciclo de ejecución. El proyecto es compatible con entornos establecidos de agentes de programación y agentes personalizados, lo que permite que una capa de políticas común observe su actividad.
Esta posición importa porque la política no necesita que el modelo subyacente reconozca cada frase maliciosa. Puede gobernar el uso de herramientas basándose en hechos registrados durante la sesión.
Consideremos un agente al que se pide revisar un documento interno de producto. Leer ese documento es lo esperado. Enviar un resumen aprobado a un canal de la empresa también podría serlo.
Ahora supongamos que el agente visita una incidencia pública, una página web o un repositorio que contiene instrucciones ocultas. Una solicitud saliente posterior adquiere un significado de seguridad diferente porque la sesión ha cruzado otro límite de confianza.
Una lista de permitidos convencional ve las mismas herramientas aprobadas durante todo el flujo de trabajo. Una política contextual ve una secuencia cuyo riesgo cambió con el tiempo.
Las políticas de Omnigent pueden devolver una decisión de permitir, preguntar o denegar. Permitir autoriza la acción, preguntar la dirige a una persona y denegar la bloquea. Por tanto, la respuesta puede volverse más estricta a medida que la sesión acumula accesos sensibles o eventos riesgosos.
Este modelo de aplicación no exige que cada fuente, herramienta o acción sea peligrosa por sí misma. En cambio, la política vigila combinaciones que crean una ruta de datos insegura.
Databricks también ofrece Omnigent como una beta gestionada conectada a la identidad del espacio de trabajo y a servicios de modelos. Su despliegue gestionado admite actualmente controladores de políticas contextuales integrados, mientras que las funciones de políticas personalizadas arbitrarias siguen sin estar disponibles allí.
Esa limitación separa el diseño de código abierto del producto gestionado. Los equipos que evalúan el anuncio deben distinguir entre un patrón de políticas demostrado y los controles disponibles en el despliegue que elijan.
Aun así, el cambio central es claro. La autorización de los agentes está pasando a depender de la sesión en lugar de quedar fija al iniciar sesión o registrar herramientas.
Por qué el enfoque de Databricks de inocente hasta que se combine cambia el límite de seguridad
El objeto riesgoso ya no es una única llamada a una herramienta; es la ruta que conecta varias llamadas permitidas.
El control de acceso tradicional evalúa identidades, recursos y acciones. Una cuenta de servicio puede leer una base de datos, escribir en un bucket o llamar a una API. Estas reglas siguen siendo necesarias porque los agentes aún operan mediante credenciales convencionales.
No son suficientes cuando un lenguaje no confiable influye en cómo se usan esas credenciales. Un atacante quizá nunca necesite robar un token ni explotar código de una aplicación. Solo necesita que contenido malicioso llegue a un modelo que pueda acceder a datos y actuar externamente.
El primer elemento son los datos privados. Esta categoría incluye documentos internos, código fuente, credenciales, registros de clientes, correo electrónico, resultados de bases de datos y cualquier información fuera de la autorización del atacante.
El segundo elemento es el contenido no confiable. Una página web, un ticket de soporte, una solicitud de extracción, un correo electrónico, un archivo compartido, la respuesta de una herramienta o una imagen pueden contener instrucciones controladas por alguien fuera del límite de confianza del agente.
El tercer elemento es la comunicación externa. El correo electrónico y las solicitudes HTTP son ejemplos evidentes, pero la categoría es más amplia. Publicar un comentario, enviar código, cargar un recurso remoto o escribir en un sistema compartido puede crear un canal saliente.
Ninguna de estas capacidades es inusual. Su utilidad es precisamente la razón por la que la combinación aparece en tantos diseños de agentes.
Un agente de investigación necesita fuentes externas y contexto interno. Un agente de programación puede leer un repositorio privado, consultar documentación pública y enviar una rama. Un asistente de correo electrónico lee mensajes no confiables, busca correspondencia privada y envía respuestas.
Eliminar permanentemente cualquier capacidad puede hacer que el agente sea mucho menos útil. Las solicitudes constantes de aprobación crean un problema distinto, porque los usuarios pueden acostumbrarse a aceptar peticiones rutinarias.
El enfoque de Databricks de inocente hasta que se combine ofrece otra opción. Permitir que las operaciones de bajo riesgo avancen, pero escalar cuando el estado de la sesión complete una combinación prohibida.
Esto traslada el límite de seguridad del conector individual al flujo de trabajo. Un navegador no es simplemente confiable o no confiable. Su relevancia depende de si la misma sesión también contiene información sensible y una vía de salida.
Este modelo se asemeja al control del flujo de información, en el que un sistema rastrea cómo se desplazan los datos entre niveles de confianza. Una vez que la información confidencial entra en un contexto, las escrituras posteriores hacia un destino menos protegido reciben un tratamiento más estricto.
El catálogo de políticas publicado por Omnigent ya incluye un control relacionado para Google Drive. Una vez que una sesión lee un archivo confidencial declarado, la política puede impedir escrituras fuera del conjunto confidencial.
El catálogo también incluye una política de puntuación de riesgo. Acumula puntos a partir de llamadas a herramientas y etiquetas de datos sensibles, y luego escala las herramientas protegidas tras un umbral configurado.
Estos ejemplos muestran por qué el estado es central. Una solicitud de escritura no cambia la forma de su API después de que el agente lee un documento sensible. Su significado cambia debido al historial de la sesión.
El mismo principio se aplica a la trifecta letal. La política busca una composición peligrosa, no una operación universalmente prohibida.
Esta distinción debería interesar más a los equipos de plataforma que otro filtro de prompts. Los filtros intentan decidir si un texto parece malicioso. La aplicación contextual todavía puede bloquear una acción insegura cuando el modelo o el filtro no logra identificar la inyección.
Los permisos estáticos pierden la secuencia
Una lista de permitidos estática puede describir las capacidades disponibles, pero no puede explicar cómo llegó el agente a una acción.
Supongamos que un desarrollador autoriza a un agente a leer un repositorio privado, navegar por documentación y abrir solicitudes de extracción. Cada permiso respalda un flujo de trabajo de programación normal.
Luego, un atacante coloca una instrucción dentro de una incidencia, un documento de dependencia o una página web recuperada. La instrucción le dice al agente que recopile un secreto y lo incluya en la descripción de una solicitud de extracción pública.
La lectura del repositorio está permitida. La recuperación web está permitida. Abrir una solicitud de extracción está permitido. Un control que evalúa cada solicitud de forma independiente puede aprobar toda la cadena.
Un filtro de contenido podría detectar la instrucción. También podría pasar por alto una solicitud indirecta, datos codificados, un idioma desconocido o una carga diseñada para el modelo objetivo.
La investigación respalda la cautela ante la dependencia exclusiva del comportamiento del modelo. El benchmark WASP probó ataques realistas de inyección de prompts contra sistemas de agentes web que usaban varios modelos y andamiajes.
Sus investigadores descubrieron que los agentes comenzaron a ejecutar instrucciones adversarias entre el 16 % y el 86 % de las veces en las configuraciones probadas. El éxito del atacante de extremo a extremo fue menor, entre cero y el 17 %.
Esa brecha es alentadora, pero no tranquilizadora. Los agentes actuales a menudo fallan antes de completar un ataque complicado, pero mejorar la fiabilidad de los agentes también puede facilitar la finalización de flujos de trabajo maliciosos.
Un sistema no debería confiar en que un agente se confunda en el momento adecuado. Necesita un control que siga siendo eficaz a medida que los modelos mejoran en la ejecución de varios pasos.
Los permisos estáticos también tienen dificultades con los ataques diferidos. La instrucción inyectada puede no desencadenar una acción saliente inmediata. Puede influir en un plan posterior, una tarea delegada, un archivo generado o una llamada a una herramienta.
Una política consciente de la sesión puede conservar hechos relevantes para la seguridad durante ese retraso. No necesita que cada evento sospechoso esté junto a la acción final en el contexto activo del modelo.
Esa persistencia aborda una debilidad práctica de los agentes de ejecución prolongada. El historial de conversación puede comprimirse, resumirse o dividirse entre trabajadores. Un modelo podría olvidar una restricción anterior incluso mientras sus herramientas y credenciales siguen disponibles.
Por ello, el estado de las políticas debe vivir fuera de la ventana de texto. La capa de aplicación necesita su propio registro duradero de lecturas sensibles, entradas no confiables, destinos, aprobaciones y cambios de riesgo.
Esta arquitectura también reduce la dependencia del autoinforme del agente. Preguntar al modelo si encontró contenido no confiable es más débil que registrar qué conector suministró ese contenido.
Las señales más sólidas provienen de la infraestructura. Un sistema documental conoce la clasificación de un archivo. Una puerta de enlace de red conoce el destino. Una capa de identidad conoce al usuario y al espacio de trabajo. Un intermediario de herramientas sabe qué operación se solicitó.
Omnigent puede combinar esas señales porque envuelve el entorno de ejecución. El agente propone una acción, pero la política decide si esa acción sigue siendo aceptable bajo el contexto registrado.
Este es el punto de presión para las plataformas de agentes competidoras. Las aprobaciones a nivel de herramienta son más fáciles de explicar e implementar. Se vuelven menos creíbles cuando los agentes ejecutan sesiones más largas a través de más conectores.
Los proveedores tendrán que demostrar si sus controles siguen los datos y las transiciones de confianza entre herramientas. Una larga lista de permisos ya no responde a la pregunta central de seguridad.
Las políticas contextuales rompen la cadena antes de que salgan los datos
El punto de control útil es la transición que completa la ruta de ataque, normalmente una lectura sensible o una acción saliente.
Una política contextual comienza con eventos observables. Estos pueden incluir una invocación de herramienta, un resultado de herramienta, una etiqueta de datos, un destino, una solicitud al modelo o una aprobación del usuario.
La política almacena hechos seleccionados en el estado de la sesión. Puede registrar que el agente consumió contenido no confiable, accedió a un objeto confidencial o intentó comunicarse fuera de un límite aprobado.
Los eventos posteriores se evalúan frente a ese estado. Si la siguiente operación completa una combinación prohibida, la política puede exigir aprobación o denegar la solicitud.
El orden puede variar. Un agente podría leer datos privados antes de visitar una página no confiable. Podría encontrar primero el contenido inyectado y luego solicitar acceso a un archivo interno.
Una implementación sólida debe detectar ambas rutas. El peligro surge cuando las capacidades se conectan, no de un orden fijo.
La aplicación de controles también puede ocurrir en más de un punto. Una política podría bloquear la lectura sensible después de que contenido no confiable entre en la sesión. Otro diseño podría permitir el análisis, pero impedir la posterior comunicación externa.
Bloquear la salida de datos suele preservar más utilidad local. El agente puede seguir leyendo y redactando sin obtener una vía para exponer información. Sin embargo, los controles de salida deben cubrir más que las funciones evidentes de envío.
Un enlace generado puede codificar datos. Una solicitud de imagen remota puede transmitir parámetros de consulta. Un push de control de versiones, un comentario en una incidencia, una llamada de analítica o una escritura en un documento compartido pueden cruzar el límite de confianza.
El contexto del destino también importa. Enviar un resumen a un canal interno aprobado es distinto de publicarlo en un repositorio público. Tratar todas las escrituras por igual crearía interrupciones innecesarias.
La aprobación humana es valiosa cuando el contexto y el destino están claros. Un aviso útil debería explicar que la sesión leyó datos confidenciales, posteriormente consumió contenido no confiable y ahora desea contactar con un endpoint externo concreto.
Un mensaje genérico de “permitir esta herramienta” oculta el motivo de la escalada. Fomenta la fatiga de aprobación porque el revisor debe reconstruir manualmente el flujo de trabajo.
La denegación estricta encaja con combinaciones que una organización nunca acepta. Por ejemplo, una política puede impedir que cualquier sesión expuesta a contenido público envíe información de un conjunto de datos restringido fuera de su compartimento.
El motor de políticas debe fallar de forma segura cuando falte el contexto requerido. Una etiqueta de datos ausente, una herramienta no compatible o una ruta de red no observada pueden crear un punto ciego.
El enfoque más amplio de Omnigent combina políticas con sandboxing. Un sandbox restringe el acceso al sistema de archivos y a la red en el límite del sistema operativo, reduciendo lo que un agente puede alcanzar incluso si el modelo lo solicita.
Estas capas cumplen propósitos distintos. El sandbox limita la capacidad bruta. La política contextual ajusta los permisos según el estado acumulado de la sesión.
Ninguna sustituye los controles ordinarios de identidad, la autorización de conectores, el registro ni la prevención de pérdida de datos. El anuncio resulta más útil cuando se interpreta como una capa de aplicación dentro de ese conjunto.
El informe sobre seguridad agéntica de OWASP identifica la inyección de prompts como una técnica de ataque principal contra los sistemas de IA. Su mensaje más amplio es que la seguridad de los agentes requiere controles sobre la ejecución, las herramientas, la identidad y el movimiento de datos.
Eso respalda la dirección arquitectónica de Databricks. Un modelo probabilístico puede sugerir una acción, pero un límite determinista debe decidir si la acción está permitida.
Lo que la política de Databricks no resuelve
La aplicación contextual de controles estrecha la ruta de ataque, pero su fiabilidad depende de una visibilidad completa y una clasificación confiable.
La primera cuestión sin resolver es la cobertura. Una política no puede bloquear un canal que no observa.
Un agente puede comunicarse mediante un conector, un comando de shell, una solicitud del navegador, un recurso incrustado o un artefacto generado. Toda vía capaz de mover datos fuera del límite debe estar representada en el modelo de políticas o restringida en otro lugar.
La segunda cuestión es la clasificación. El sistema necesita saber qué contenido no es confiable y qué datos son sensibles.
Las reglas simples pueden clasificar las páginas web públicas como no confiables y los documentos con nombre como confidenciales. Los entornos empresariales contienen casos más difíciles, como unidades compartidas, cuentas de contratistas, texto copiado, archivos generados y datos reunidos a partir de varias fuentes de baja sensibilidad.
Los falsos negativos dejan sin detectar la combinación peligrosa. Los falsos positivos interrumpen el trabajo ordinario y pueden entrenar a los usuarios para aprobar advertencias sin revisarlas.
La tercera cuestión es el alcance del estado. Una sesión es una unidad conveniente, pero la información puede moverse entre sesiones mediante archivos, almacenes de memoria, cachés, subagentes y resúmenes copiados.
Si un trabajador lee datos confidenciales y otro envía el resultado, el seguimiento por sesión puede pasar por alto el flujo combinado. Los sistemas multiagente necesitan reglas de propagación que preserven las etiquetas relevantes entre delegaciones.
La cuarta cuestión es la integridad de las políticas. La capa de aplicación, la configuración y el flujo de eventos se convierten en infraestructura crítica para la seguridad. Los atacantes pueden apuntar a lagunas en las políticas, metadatos de herramientas malformados, destinos ambiguos o comportamientos de fallo abierto.
Los equipos deberían probar el límite real de las políticas, no solo el modelo. Las evaluaciones adversariales deben incluir rutas alternativas de salida, acciones diferidas, transferencias entre agentes y metadatos incompletos.
La quinta cuestión es la usabilidad. Un control que solicita aprobación con demasiada frecuencia puede reproducir la debilidad que pretendía resolver.
La escalada basada en riesgo necesita umbrales cuidadosamente elegidos y avisos informativos. Los equipos de seguridad deberían medir la frecuencia de aprobación, la precisión de las denegaciones, las tasas de anulación y los motivos por los que los usuarios aceptan excepciones.
La beta gestionada de Omnigent introduce otra limitación práctica. Databricks documenta actualmente soporte para controladores integrados, no para código de políticas personalizado arbitrario, en el entorno gestionado.
Las organizaciones con clasificaciones especializadas o conectores propietarios deberían verificar si las políticas disponibles exponen suficiente contexto. La flexibilidad del código abierto no se traduce automáticamente en paridad con el servicio gestionado.
Tampoco hay base todavía para tratar una demostración como validación universal. El artículo de Databricks explica un patrón de seguridad y un enfoque de implementación. No establece que cada configuración de Omnigent bloquee todas las técnicas de inyección de prompts.
La afirmación correcta es más limitada. La aplicación de controles con conciencia de sesión puede romper una ruta de la tríada letal incluso cuando cada herramienta individual sigue siendo legítima.
Eso sigue siendo significativo. La arquitectura de seguridad suele tener éxito al eliminar una condición necesaria de un ataque, no al enseñar a la aplicación a reconocer cada mensaje del atacante.
Los despliegues más sólidos combinarán la política contextual con credenciales restringidas, listas de destinos permitidos, sandboxing, registros de auditoría y pruebas independientes. También tratarán las definiciones de políticas como código de seguridad versionado.
Tres señales mostrarán si el modelo se sostiene
La siguiente prueba es si la política contextual se convierte en infraestructura medible en lugar de una demostración persuasiva.
La primera señal es una cobertura más amplia entre herramientas y arneses de agentes. Databricks debe demostrar que las etiquetas de seguridad y el estado de sesión sobreviven a flujos de trabajo habituales que involucren navegadores, repositorios de código, sistemas de documentos, shells y agentes delegados.
El soporte en una lista de funciones no basta. Los equipos necesitan pruebas de que las acciones equivalentes reciben una aplicación de controles equivalente en distintos arneses e implementaciones de conectores.
Una cobertura consistente reforzaría el argumento a favor de un metaarnés compartido. Las diferencias materiales entre entornos de ejecución debilitarían la promesa de una capa de gobernanza única para los agentes.
La segunda señal es la evaluación adversarial. Omnigent necesita pruebas repetibles que intenten exfiltración diferida, salida indirecta, transferencia entre sesiones y manipulación de metadatos.
Los resultados útiles deberían separar detección, aprobación, denegación y movimiento exitoso de datos. También deberían informar sobre la finalización de tareas benignas, porque una política que bloquea todos los flujos de trabajo es segura, pero inutilizable.
Los fixtures de prueba públicos permitirían a los equipos de seguridad reproducir los resultados frente a su propia configuración. Una evaluación independiente tendría más peso que un escenario seleccionado por el proveedor.
La tercera señal es la adopción operativa dentro de entornos gestionados de Databricks. Hay que observar una ampliación del soporte de políticas, telemetría más clara, controles de administración e integraciones documentadas con clasificaciones empresariales de datos.
La adopción debería producir resultados medibles. Los equipos necesitan saber con qué frecuencia se activan las políticas, qué combinaciones de capacidades provocan la escalada y si los revisores revocan o aprueban la decisión.
Estas señales importan porque el problema de seguridad subyacente crecerá con la utilidad de los agentes. Los agentes mejores completarán tareas más largas, usarán más herramientas y cruzarán más límites de confianza sin supervisión constante.
El enfoque de Databricks, inocente hasta que se combina, ofrece un principio de diseño creíble: permitir componentes útiles mientras se bloquea la composición peligrosa. Desplaza la atención de si un modelo comprende un ataque a si el sistema circundante permite que el ataque termine.
Los desarrolladores deberían identificar qué sesiones pueden acceder a datos privados, ingerir contenido controlado por atacantes y comunicarse externamente. Los compradores empresariales deberían preguntar si una plataforma rastrea esas condiciones a través del tiempo, las herramientas y los trabajadores delegados.
Si las tres siguen disponibles sin aplicación contextual de controles, una pantalla de aprobación refinada no resuelve el problema. El siguiente paso práctico es identificar dónde entra la tercera capacidad en cada flujo de trabajo y luego colocar una política comprobable en ese límite.
