El permiso de Databricks no es propósito: Omnigent antepone la intención a la acción del agente

Databricks ha introducido un nuevo límite de permisos para Omnigent, aunque el agente ya contaba con credenciales válidas para todas las herramientas de su prueba. El control pregunta por qué se realiza una acción, no solo si el agente puede llevarla a cabo. Esta distinción convierte databricks permission de una comprobación de identidad en una restricción específica de la tarea.

El lanzamiento del 23 de julio presenta la autorización basada en intención como una defensa contra la inyección indirecta de prompts. Este ataque oculta instrucciones dentro del contenido que lee un agente, como un correo electrónico, documento, ticket de soporte o campo de base de datos. Omnigent vincula cada sesión a un propósito aprobado por una persona y verifica cada llamada a herramientas frente a ese propósito.

Este enfoque cuestiona el modelo predeterminado de identidad primero que sustenta la mayoría de los sistemas empresariales de acceso. El control de acceso basado en roles puede confirmar que un agente puede conceder acceso a una base de datos. No puede determinar si conceder ese acceso corresponde a una revisión de calidad de datos. La diferencia entre capacidad y propósito se está convirtiendo ahora en un límite operativo de seguridad.

El permiso de Databricks ahora verifica la tarea, no solo la identidad

El cambio inmediato es sencillo: Omnigent evalúa si cada llamada a herramientas propuesta cumple el propósito declarado de la sesión actual.

La autorización tradicional comienza con la identidad. Un usuario, cuenta de servicio o agente recibe permiso para interactuar con recursos específicos. Después, las aplicaciones aceptan o rechazan operaciones de acuerdo con roles, ámbitos, políticas y credenciales.

Este modelo presupone que el actor autenticado representa a una persona que toma decisiones de forma relativamente estable. Un humano lee información, la interpreta y decide qué botón autorizado pulsar. La capa de autorización rara vez necesita comprender por qué la persona lo pulsó.

Un agente de IA funciona de otra forma. Lee datos y decide qué hacer dentro del mismo ciclo automatizado. El contenido recopilado desde fuera del sistema puede influir tanto en su razonamiento como en su selección de herramientas privilegiadas.

Según el anuncio de autorización por intención, Omnigent aborda esa diferencia combinando identidad e intención. La identidad define el conjunto amplio de operaciones disponibles para el agente. La intención reduce ese conjunto para una tarea o sesión.

El mecanismo produce tres posibles decisiones antes de una llamada a herramientas:

• ALLOW: La acción propuesta encaja claramente con el propósito aprobado.

• ASK: La acción se relaciona con el propósito, pero requiere consentimiento humano.

• DENY: La acción queda fuera del propósito declarado y no puede continuar.

Estos resultados importan porque una credencial válida ya no resuelve por sí sola la decisión de autorización. Un agente puede disponer de una herramienta y seguir sin poder utilizarla durante una tarea no relacionada.

Omnigent es un meta-harness de código abierto, lo que significa que proporciona una capa compartida de orquestación y políticas alrededor de distintos entornos de ejecución de agentes. Su repositorio de código abierto indica compatibilidad con Claude Code, Codex, Cursor, OpenCode, Hermes, Pi y agentes personalizados.

Este posicionamiento amplía la política más allá de una salvaguarda para un solo modelo. La comprobación de intención se sitúa alrededor de la actividad de herramientas del agente, donde puede gobernar diferentes sistemas de razonamiento mediante una capa común.

El lanzamiento también llega con una limitación importante. Omnigent sigue en fase alfa, por lo que la demostración debe interpretarse como una propuesta de diseño y una implementación funcional. No constituye evidencia de fiabilidad a escala de producción en todos los modelos, herramientas y flujos de trabajo empresariales.

Aun así, el punto arquitectónico es concreto. Una decisión de autorización puede incorporar la tarea actual sin sustituir los controles de identidad existentes. Para los equipos de seguridad, esto crea un punto de control adicional entre la decisión de un modelo y una acción relevante.

El nuevo control también complementa las demás políticas contextuales de Omnigent. Esas políticas pueden considerar el riesgo de la sesión, datos sensibles, uso acumulado de herramientas o restricciones específicas de servicios. Si varias políticas evalúan la misma llamada, una denegación prevalece sobre decisiones más permisivas.

Esta regla evita que una política añadida posteriormente anule silenciosamente otra más estricta. También presenta la intención como una capa dentro de una defensa más amplia, en lugar de una respuesta completa a la seguridad de los agentes.

La prueba de calidad de datos revela la brecha de propósito

Databricks eligió un pequeño flujo de trabajo de datos para mostrar por qué un permiso excesivo a veces es operativamente necesario, pero sigue siendo inseguro.

El agente de prueba realiza una tarea rutinaria de calidad de datos. Lee una tabla de clientes, calcula indicadores de calidad y publica un resumen en un panel interno.

Sus herramientas disponibles incluyen una consulta de tabla, una actualización del panel y una función que concede a otro usuario acceso a la tabla. La última capacidad es innecesaria para esta revisión concreta. Sin embargo, el mismo agente la utiliza durante otras tareas legítimas.

Eliminar la herramienta de concesión de acceso reduciría el riesgo inmediato. También impediría que el agente completara tareas válidas de aprovisionamiento sin una configuración o identidad independiente. Aquí es donde el principio estático de mínimo privilegio se vuelve difícil para los agentes de propósito general.

La sesión comienza con una solicitud limitada: revisar la tabla de clientes y publicar un resumen. Un atacante había introducido previamente una instrucción en un campo controlado por el usuario de esa tabla.

El texto oculto se presenta como una nota de auditoría. Ordena al agente conceder a una dirección externa acceso a los datos de clientes y, después, continuar con la comprobación de calidad original.

Se trata de una inyección indirecta de prompts porque la instrucción maliciosa llega a través de datos recuperados. El usuario nunca pidió al agente cambiar permisos, y el atacante nunca necesitó acceso directo a la conversación del agente.

Sin la política de intención, el agente de prueba de Omnigent sigue la instrucción implantada. Su identidad está autorizada a utilizar la herramienta de concesión de acceso, por lo que una comprobación de permisos convencional considera que es una operación válida de un actor válido.

Después, el agente registra la concesión como actividad de auditoría normal. Ese detalle ilustra un segundo problema: los registros de actividad pueden documentar correctamente una operación sin revelar que la operación vulneró el objetivo real del usuario.

Con la autorización basada en intención activada, siguen disponibles las mismas herramientas y credenciales. El resultado cambia porque cada operación se compara con el propósito aprobado de calidad de datos.

La lectura de la tabla recibe una decisión ALLOW. La publicación de la actualización solicitada del panel recibe una decisión ASK, que permite a una persona confirmar la escritura. La concesión de acceso a la dirección externa recibe una decisión DENY.

La tarea legítima sigue finalizando después de aprobar la actualización del panel. La acción inyectada falla porque no contribuye al propósito declarado de la sesión.

Este ejemplo otorga a los controles de databricks permission un significado más preciso. La pregunta ya no es únicamente si el agente puede modificar el acceso. El sistema también evalúa si esa modificación corresponde a una sesión de calidad de datos.

La prueba refleja un problema empresarial práctico. Un agente conectado a una base de conocimiento con capacidad de búsqueda, plataforma de datos o entorno de soporte puede encontrar texto procedente de muchos niveles de confianza. Un comentario de usuario y una instrucción de administrador pueden entrar en el mismo contexto del modelo.

Los humanos reconocen el contexto organizativo de manera imperfecta, pero pueden cuestionar una solicitud inusual. Los modelos pueden interpretar un texto malicioso cuidadosamente redactado como parte de la tarea, especialmente cuando se parece a una instrucción empresarial común.

Los investigadores de seguridad de Google definen la inyección indirecta de prompts como instrucciones maliciosas incrustadas en contenido que procesa un sistema de IA. Su reciente análisis de amenazas web encontró tanto intentos maliciosos como numerosos textos inocuos que se asemejan a patrones de inyección.

Esta mezcla complica el filtrado de contenido. Un detector que busque frases como “ignore previous instructions” encontrará artículos de investigación, tutoriales de seguridad y discusiones inofensivas. Un ataque sofisticado puede usar lenguaje empresarial sin marcadores maliciosos evidentes.

La autorización basada en intención aborda el problema desde el lado de la acción. No necesita demostrar que un campo de tabla es hostil antes de bloquear un cambio de permisos no relacionado. Pregunta si la llamada a herramientas resultante respalda la tarea.

Esa es la inversión central de la demostración de Databricks. La operación peligrosa no parece no autorizada para el sistema de identidad. Se vuelve no autorizada solo cuando el propósito entra en la decisión.

Por qué el acceso basado en identidad deja a los agentes sobreexpuestos

La principal presión recae sobre los sistemas de identidad y acceso que tratan el alcance de una credencial como el límite final para el software autónomo.

El control de acceso basado en roles sigue siendo esencial. Limita a qué recursos puede acceder una identidad y qué operaciones puede solicitar. Los controles basados en intención no pueden compensar de forma segura que un agente tenga acceso de administrador a toda una organización.

Sin embargo, los roles tienden a permanecer estables mientras las tareas de los agentes cambian rápidamente. Un agente de programación puede revisar un repositorio, crear una rama, desplegar un servicio o modificar una incidencia durante distintas sesiones. Cada tarea requiere un subconjunto diferente de las mismas capacidades disponibles.

Crear una identidad para cada tarea posible generaría una gran carga de aprovisionamiento. Otorgar amplios ámbitos a una identidad reutilizable crea un problema de autoridad ambiental, donde las credenciales siguen disponibles más allá de su propósito inmediato.

Las credenciales de corta duración y alcance limitado pueden reducir esta exposición. Funcionan mejor cuando los sistemas pueden predecir los recursos y acciones exactos necesarios antes de la ejecución. Los flujos de trabajo abiertos de los agentes suelen descubrir esos requisitos mientras trabajan.

El modelo de Omnigent añade una restricción a nivel de sesión sin requerir una identidad nueva para cada conversación. Una persona declara lo que se supone que el agente debe lograr, y después la política evalúa las acciones propuestas frente a esa declaración.

Para los agentes autónomos, Databricks afirma que la intención puede fijarse en la especificación del agente durante el diseño. El agente en ejecución no puede ampliarla ni eliminarla.

Los agentes interactivos manejan la decisión de otra manera. El agente redacta una política a partir de la descripción del usuario en lenguaje natural, pero una persona la aprueba al inicio de la sesión. La política no puede cambiar en segundo plano durante esa sesión.

Este paso de aprobación humana importa porque la inferencia de intención crea su propia vulnerabilidad. Si el modelo pudiera redefinir silenciosamente el propósito después de leer contenido inyectado, un atacante podría persuadirlo para autorizar la acción no deseada.

Omnigent también niega al agente en ejecución herramientas para eliminar, editar o desactivar su intención. Añadir otra política requiere aprobación humana, y una incorporación permisiva no puede anular una denegación existente.

Estos controles crean resistencia a la manipulación alrededor de la configuración de políticas. No hacen que la evaluación de intención subyacente sea infalible.

La documentación de la política integrada indica que su control intent_based_authorization registra el primer mensaje del usuario como intención de la sesión. Después pregunta antes de llamadas a herramientas que no tengan una conexión plausible con esa intención. La documentación también señala que la política requiere una configuración de LLM y falla de forma abierta si no cuenta con una.

Ese último comportamiento merece atención. Un control de seguridad que se vuelve permisivo cuando su evaluador no está disponible crea una condición de despliegue que los equipos deben probar y supervisar. Los entornos de producción generalmente necesitan fallos visibles, validación de configuración y alertas cuando un componente de política requerido deja de estar disponible.

El uso de un evaluador LLM crea otra disyuntiva. El razonamiento en lenguaje natural puede comprender relaciones entre tareas que las reglas estáticas no detectan. También puede producir decisiones incoherentes cuando cambian los prompts, los modelos o el contexto circundante.

Esta tensión explica por qué Databricks presenta la intención como parte de una seguridad de agentes por capas. Una política puede detener una concesión de acceso ajena a la tarea mientras otro control limita el riesgo acumulado. Reglas independientes de prevención de pérdida de datos pueden gobernar qué información fluye a través de una llamada por lo demás permitida.

NIST también ha identificado la autorización como un problema sin resolver para los agentes. Su propuesta sobre identidad de agentes de febrero de 2026 pregunta cómo deberían las organizaciones aplicar controles de identidad, autorización, auditoría y no repudio al software autónomo.

La propuesta incluye específicamente controles para prevenir y mitigar la inyección de prompts. Ese alcance muestra por qué la identidad y el propósito no pueden seguir siendo debates separados.

Un agente autenticado aún puede tomar una decisión perjudicial. Una acción alineada con un propósito aún puede exponer datos sensibles si sus argumentos o destino no son seguros. Los controles eficaces deben considerar conjuntamente la identidad, la tarea, los datos, la acción y la consecuencia.

Para los compradores empresariales, la respuesta obligada es arquitectónica. Las revisiones de seguridad ya no pueden terminar con una lista de ámbitos de OAuth o roles de cuentas de servicio. Los equipos deben documentar cómo cada acción de alto impacto sigue conectada a un objetivo aprobado por el usuario durante la ejecución.

La autorización basada en intención añade criterio y nuevos modos de fallo

Omnigent reduce una brecha de autorización al situar el criterio asistido por modelos directamente dentro de la ruta de aplicación.

Ese diseño ofrece flexibilidad, pero también crea incertidumbre. «Plausiblemente conectado con la tarea» no es una propiedad completamente determinista.

Consideremos un agente al que se le pide investigar una interrupción de producción. Leer registros encaja claramente con la tarea. Reiniciar un servicio podría encajar después de que el agente identifique un fallo. Rotar credenciales podría ser necesario si la evidencia indica una vulneración.

Una política estrecha podría bloquear las acciones necesarias para la recuperación. Una política amplia podría permitir a un atacante presentar un cambio de credenciales no relacionado como respuesta a un incidente. La aprobación humana puede resolver parte de la ambigüedad, pero las solicitudes frecuentes pueden ralentizar el trabajo y fomentar el consentimiento automático.

Por tanto, el modelo ALLOW, ASK y DENY depende de una calibración cuidadosa. ASK es particularmente importante porque ofrece a operaciones inciertas pero legítimas una vía para avanzar sin conceder autonomía silenciosa.

Demasiadas decisiones ASK generan fatiga de aprobación. Los operadores pueden aprobar solicitudes sin examinar el motivo, el destino o los datos afectados. Muy pocas decisiones ASK desplazan las operaciones ambiguas hacia el permiso automático o la denegación innecesaria.

La política también juzga las llamadas a herramientas, no todas las consecuencias de una llamada permitida. Databricks señala explícitamente que la intención restringe qué acciones se ejecutan, en lugar de qué viaja a través de esas acciones.

Una actualización aprobada de un panel podría seguir incluyendo datos confidenciales. Una respuesta de correo electrónico permitida podría dirigirse al destinatario equivocado. Una consulta legítima a una base de datos podría devolver más registros de los que la tarea requiere.

Por tanto, la autorización basada en intención debe funcionar junto con la validación de argumentos, la prevención de pérdida de datos, los controles de destino, los límites de tasa y los sistemas de auditoría. Su valor proviene de añadir propósito a la autorización, no de sustituir esos controles.

OpenAI describe un modelo relacionado de fuente y sumidero en su análisis de seguridad de agentes. Un resultado peligroso suele requerir tanto contenido controlado por un atacante como una capacidad que se vuelve perjudicial en el contexto equivocado.

Ese enfoque respalda el énfasis de Omnigent en restringir la acción. También resalta por qué ningún clasificador único puede resolver el problema. Los sistemas deben reducir el impacto de la manipulación incluso cuando no detectan la entrada maliciosa.

La investigación independiente apunta en la misma dirección. El artículo Task Shield de ACL 2025 evalúa si cada instrucción y llamada a herramienta contribuye a un objetivo especificado por el usuario.

En el benchmark AgentDojo, los investigadores informaron de una tasa de éxito de ataque del 2,07 % y una utilidad de tarea del 69,79 % con GPT-4o. Estos resultados se aplican a ese benchmark y configuración, no a la implementación de Omnigent.

La cifra de utilidad expone la disyuntiva detrás de las defensas de alineación con la tarea. Un sistema puede bloquear ataques y, al mismo tiempo, impedir trabajo legítimo. La seguridad mejora solo cuando la política preserva suficiente finalización de tareas para seguir siendo utilizable.

Databricks no ha publicado resultados de benchmark comparables para su nuevo control. La demostración muestra un campo inyectado, un agente, tres herramientas y un propósito declarado. No establece un rendimiento general en sesiones largas o tareas empresariales ambiguas.

Tampoco hay todavía evidencia pública sobre aprobaciones erróneas, denegaciones erróneas, latencia del evaluador o comportamiento de la política tras actualizaciones del modelo. Esas mediciones determinarán si el enfoque avanza más allá de ejemplos persuasivos.

Los atacantes también se adaptarán. Pueden elaborar instrucciones inyectadas que parezcan conectadas con la tarea declarada. Una instrucción podría afirmar que conceder acceso es necesario para verificar la misma tabla que se está revisando.

La demostración publicada ya utiliza esta estrategia al describir al destinatario externo como auditor. La política sigue bloqueando la concesión porque la intención aprobada se mantiene limitada, pero las tareas más complejas producirán límites menos evidentes.

Una instrucción maliciosa también podría dirigirse a los argumentos dentro de una herramienta permitida. Si la sesión permite actualizaciones de paneles, un atacante podría intentar insertar campos confidenciales en el cuerpo del panel. La alineación de propósito a nivel de herramienta por sí sola no detectaría necesariamente esa variante.

Por tanto, los equipos que evalúan controles de permisos de Databricks deberían probar las decisiones de política en varios niveles. Necesitan solicitudes ordinarias, solicitudes ambiguas, contenido inyectado, justificaciones empresariales engañosas y argumentos maliciosos dentro de operaciones permitidas.

También deberían registrar por qué se produjo cada decisión. Un equipo de seguridad no puede investigar una aplicación incoherente si los registros contienen solo ALLOW, ASK o DENY sin la intención pertinente y la acción propuesta.

La comparación más útil no es el control de intención frente a la seguridad perfecta. Es el control de intención frente a la autorización basada únicamente en identidad, dentro de un sistema por capas.

Bajo esa comparación, Omnigent cierra una brecha real. La pregunta restante es si los equipos pueden definir el propósito con suficiente precisión para obtener protección sin convertir cada acción útil del agente en una revisión manual.

Tres señales mostrarán si el modelo de Omnigent se sostiene

La siguiente fase debe juzgarse por la calidad medible de la aplicación, no por la claridad de la demostración inicial.

La primera señal es una suite de evaluación reproducible. Omnigent necesita pruebas que abarquen diferentes modelos, entornos de prueba, herramientas y estrategias de inyección indirecta.

Los resultados útiles separarían el éxito de los ataques, la finalización de tareas legítimas, las aprobaciones erróneas, las denegaciones erróneas y las tasas de escalamiento a humanos. También deberían mostrar si pequeños cambios en la redacción producen decisiones materialmente diferentes.

Un rendimiento sólido en pruebas adversariales reforzaría el argumento de Databricks de que el propósito puede convertirse en una entrada de autorización fiable. Una alta variación entre modelos o prompts debilitaría el argumento a favor de las comprobaciones de intención asistidas por modelos como límite de aplicación.

La segunda señal es un comportamiento de fallo seguro para el despliegue. La documentación de Omnigent dice que la política integrada falla en modo abierto cuando no hay configuración LLM disponible.

Los usuarios deberían vigilar la validación de inicio, las alertas administrativas, las opciones de fallo cerrado y registros de auditoría claros cuando el evaluador no pueda ejecutarse. Una política contextual ofrece poca protección si la deriva de configuración puede eliminarla silenciosamente.

Una gestión visible de las interrupciones del evaluador reforzaría el diseño. Un comportamiento permisivo continuado sin advertencias destacadas dejaría una seria brecha operativa.

La tercera señal es la adopción fuera de los ejemplos de los autores. Los equipos reales necesitan publicar políticas para programación, soporte, operaciones de datos, correo electrónico, calendarios y delegación multiagente.

Esos ejemplos deberían revelar cómo las organizaciones definen la intención para asignaciones que evolucionan legítimamente. También deberían mostrar con qué frecuencia los usuarios reciben solicitudes ASK y si esas solicitudes mejoran las decisiones.

Un uso más amplio pondría a prueba la promesa central del diseño: un agente puede conservar capacidades útiles mientras ejerce solo el subconjunto necesario para la tarea actual. Evasiones repetidas de políticas o una fatiga de aprobación intolerable debilitarían esa promesa.

Por eso el lanzamiento de Omnigent importa más allá de un único framework de código abierto. Los desarrolladores de agentes están creando sistemas que leen información no confiable y actúan mediante credenciales empresariales válidas. El riesgo resultante se sitúa entre el control de acceso convencional y la seguridad de los modelos.

Los permisos de Databricks se están convirtiendo en una decisión de dos partes: ¿puede actuar esta identidad y esta acción sirve al propósito aprobado?

Esa segunda pregunta no eliminará la inyección de prompts. Crea un lugar para detener una instrucción inyectada después de que influya en el modelo, pero antes de que llegue a una herramienta con consecuencias.

Los desarrolladores deberían comenzar identificando acciones cuya autorización cambia con el contexto de la tarea. Los equipos de seguridad pueden entonces probar si las políticas de intención deniegan operaciones no relacionadas, escalan las ambiguas y preservan el trabajo legítimo.

Los compradores empresariales deberían pedir a los proveedores evidencia sobre esos tres resultados. Un control que bloquea todo no es una autorización útil. Un control que preserva todos los flujos de trabajo mientras no detecta solicitudes adversariales no es una protección significativa.

La pregunta práctica ahora es ineludible: si un agente de IA tiene permiso para realizar una acción, ¿qué evidencia aplicada de forma independiente demuestra que la acción sirve al propósito actual del usuario?