Databricks publicó una demostración de Omnigent centrada en un tipo de prompt injection indirecto que no intenta extraer información en una única instrucción visible. El caso divide la filtración en pasos que, considerados por separado, parecen inocuos. La propuesta expuesta consiste en conservar contexto de sesión y aplicar políticas que evalúan el riesgo acumulado antes de permitir una acción posterior.
✦ La demostración se centra en el riesgo que aparece al evaluar una secuencia completa.
El problema: instrucciones que parecen normales por separado
La inyección indirecta de prompts ocurre cuando un sistema que usa herramientas o consulta contenido externo recibe instrucciones incrustadas en ese contenido. En la demostración publicada por Databricks, el ataque no busca una exfiltración inmediata: reparte su objetivo entre varias interacciones. Cada solicitud individual puede parecer compatible con una tarea habitual del agente, pero la secuencia completa revela una intención distinta.
Este patrón es relevante porque una revisión aislada de cada mensaje puede perder la relación entre acciones sucesivas. Una lectura, una transformación o una preparación de datos pueden no ser suficientes para activar una alerta si se analizan sin historial. La cuestión planteada por el artículo es cómo conservar señales de riesgo a medida que avanza una sesión, sin tratar cada paso como un evento desconectado.
Databricks denomina a este escenario una forma de ataque de combustión lenta. La expresión describe la acumulación gradual de condiciones para una filtración, no una afirmación sobre todos los ataques de prompt injection. El ejemplo debe entenderse como el caso diseñado y mostrado por la empresa para explicar el comportamiento de sus políticas contextuales.
Cómo funciona la demostración de políticas contextuales
Según el artículo, Omnigent mantiene contexto de sesión y usa ese contexto al aplicar políticas. En la demostración, cada lectura añade 30 puntos a un puntaje de riesgo. El envío posterior se bloquea cuando el puntaje alcanza el umbral de 50. Así, una primera lectura no alcanza el límite por sí sola, mientras que la acumulación de lecturas puede cambiar la decisión sobre una acción de salida.
El detalle importante no es solo el número utilizado en el ejemplo, sino el orden de evaluación que ilustra. El sistema puede asociar acciones previas de una sesión con una operación que, vista de manera aislada, no necesariamente comunica todo el riesgo. La demostración presenta una política que toma una decisión a partir de esa trayectoria contextual y no únicamente del texto de un prompt final.
Databricks también señala que el agente no tiene una herramienta para desactivar la política. Además, al combinar políticas, una denegación prevalece. Estas condiciones delimitan el ejemplo: la política opera como un control que el agente no puede revocar mediante una herramienta disponible y una decisión denegatoria conserva prioridad al producirse la combinación indicada.
Implicaciones para el diseño de agentes
La demostración apunta a decisiones de arquitectura más que a una conclusión definitiva sobre seguridad. El valor del caso está en hacer visible que el riesgo puede surgir de una secuencia, no solo de una instrucción individual.
- El historial relevante de una sesión debe poder influir en las decisiones sobre acciones sensibles, especialmente cuando el agente procesa contenido no confiable.
- Los umbrales de riesgo necesitan una justificación verificable: el valor de 30 por lectura y el límite de 50 son parámetros del ejemplo de Databricks, no valores universales.
- Las políticas necesitan una precedencia clara y mecanismos que impidan que el propio agente las desactive mediante las herramientas a su alcance.
✦ Los valores corresponden al escenario mostrado por Databricks.
Qué se puede concluir y qué no
La publicación muestra un enfoque para representar y usar riesgo acumulado dentro de una sesión de agente. Es una explicación concreta de cómo una política contextual podría bloquear una secuencia de pasos aparentemente benignos antes de una acción de envío. Para equipos que diseñan agentes con acceso a contenido, herramientas o canales de salida, el ejemplo ayuda a formular preguntas sobre estado de sesión, umbrales y precedencia entre controles.
Sin embargo, no es una evaluación independiente. Los escenarios, los puntajes y el resultado de bloqueo pertenecen a una demostración publicada por Databricks. El material disponible no permite concluir una eficacia general frente a toda clase de ataques indirectos, ni establecer comparaciones con otros controles, configuraciones, modelos o entornos operativos.
Omnigent es presentado por Databricks como open source en alpha. Esa descripción define el estado comunicado por la empresa y no equivale a una afirmación sobre disponibilidad empresarial, madurez para producción o cobertura de soporte. Cualquier adopción o análisis técnico posterior requeriría revisar el código, la documentación, el modelo de amenazas y las condiciones de uso vigentes.
✦ Estas reglas describen el comportamiento expuesto en la publicación de la empresa.
Preguntas Frecuentes
✦ ¿Qué es lo que Databricks demostró?
Mostró un escenario de inyección indirecta dividido en pasos aparentemente inocuos y el uso de contexto de sesión en Omnigent. En ese escenario, cada lectura suma 30 puntos de riesgo y un envío se bloquea al alcanzar el umbral de 50.
✦ ¿La demostración prueba que Omnigent bloquea cualquier prompt injection?
No. Es una demostración publicada por la empresa, no una evaluación independiente. Los hechos confirmados describen el comportamiento del caso presentado, pero no permiten afirmar eficacia generalizada frente a todos los ataques, modelos, herramientas o configuraciones.
✦ ¿Qué estado tiene Omnigent según la publicación?
Databricks lo presenta como open source en alpha. Con la información indicada no corresponde inferir disponibilidad empresarial, soporte comercial, preparación para producción ni resultados fuera del escenario demostrado.
El caso de Databricks pone el foco en una limitación sencilla de describir y difícil de resolver: una acción puede parecer aceptable hasta que se observa junto con las anteriores. La demostración de Omnigent ofrece un ejemplo de políticas que conservan esa memoria, con un bloqueo basado en riesgo acumulado. Sus resultados deben leerse dentro de los límites del escenario publicado por la empresa.
Fuente original: Databricks Blog
