Permissão no Databricks Não É Propósito: Omnigent Coloca a Intenção Antes da Ação do Agente

A Databricks introduziu um novo limite de permissão para o Omnigent, embora o agente já possua credenciais válidas para todas as ferramentas em seu teste. O controle pergunta por que uma ação está sendo realizada, não apenas se o agente pode executá-la. Essa distinção transforma a permissão no databricks de uma verificação de identidade em uma restrição específica da tarefa.

O lançamento de 23 de julho apresenta a autorização baseada em intenção como uma defesa contra injeção indireta de prompt. Esse ataque oculta instruções dentro de conteúdos que um agente lê, como e-mails, documentos, tickets de suporte ou campos de banco de dados. O Omnigent vincula cada sessão a uma finalidade aprovada por humanos e verifica cada chamada de ferramenta em relação a ela.

Essa abordagem desafia o modelo padrão, centrado na identidade, por trás da maioria dos sistemas corporativos de acesso. O controle de acesso baseado em funções pode confirmar que um agente pode conceder acesso a um banco de dados. Ele não consegue determinar se conceder esse acesso faz parte de uma revisão de qualidade de dados. A diferença entre capacidade e propósito está se tornando agora um limite operacional de segurança.

A Permissão no Databricks Agora Verifica a Tarefa, Não Apenas a Identidade

A mudança imediata é simples: o Omnigent avalia se cada chamada de ferramenta proposta atende ao propósito declarado da sessão atual.

A autorização tradicional começa pela identidade. Um usuário, uma conta de serviço ou um agente recebe permissão para interagir com recursos específicos. Em seguida, as aplicações aceitam ou rejeitam operações de acordo com funções, escopos, políticas e credenciais.

Esse modelo pressupõe que o ator autenticado representa uma pessoa que toma decisões de forma relativamente estável. Um humano lê informações, interpreta-as e decide qual botão permitido pressionar. A camada de autorização raramente precisa entender por que a pessoa o pressionou.

Um agente de IA opera de forma diferente. Ele lê dados e decide o que fazer dentro do mesmo ciclo automatizado. Conteúdos obtidos de fora do sistema podem influenciar tanto seu raciocínio quanto sua seleção de ferramentas privilegiadas.

Segundo o lançamento da autorização por intenção, o Omnigent aborda essa diferença combinando identidade e intenção. A identidade define o conjunto amplo de operações disponíveis ao agente. A intenção restringe esse conjunto para uma tarefa ou sessão.

O mecanismo produz três decisões possíveis antes de uma chamada de ferramenta:

• PERMITIR: A ação proposta se encaixa claramente no propósito aprovado.

• PERGUNTAR: A ação está relacionada ao propósito, mas exige consentimento humano.

• NEGAR: A ação está fora do propósito declarado e não pode prosseguir.

Esses resultados importam porque uma credencial válida deixa de encerrar a decisão de autorização. Um agente pode possuir uma ferramenta e ainda assim não conseguir usá-la durante uma atribuição não relacionada.

O Omnigent é um meta-harness de código aberto, o que significa que fornece uma camada compartilhada de orquestração e políticas em torno de diferentes runtimes de agentes. Seu repositório de código aberto lista suporte para Claude Code, Codex, Cursor, OpenCode, Hermes, Pi e agentes personalizados.

Esse posicionamento torna a política mais ampla do que uma proteção para um único modelo. A verificação de intenção envolve a atividade de ferramentas do agente, onde pode governar diferentes sistemas de raciocínio por meio de uma camada comum.

O lançamento também vem com uma limitação importante. O Omnigent continua em versão alpha, portanto a demonstração deve ser entendida como uma proposta de design e uma implementação funcional. Ela não é evidência de confiabilidade em escala de produção para todos os modelos, ferramentas e fluxos de trabalho empresariais.

Ainda assim, o ponto arquitetural é concreto. Uma decisão de autorização pode incorporar a tarefa atual sem substituir os controles de identidade existentes. Para equipes de segurança, isso cria uma verificação adicional entre a decisão de um modelo e uma ação consequente.

O novo controle também complementa as outras políticas contextuais do Omnigent. Essas políticas podem considerar o risco da sessão, dados sensíveis, uso cumulativo de ferramentas ou restrições específicas de serviços. Se várias políticas avaliarem a mesma chamada, uma única negação prevalece sobre decisões mais permissivas.

Essa regra evita que uma política recém-adicionada cancele silenciosamente outra mais rigorosa. Ela também enquadra a intenção como uma camada dentro de uma defesa mais ampla, e não como uma resposta completa para a segurança de agentes.

O Teste de Qualidade de Dados Expõe a Lacuna de Propósito

A Databricks escolheu um pequeno fluxo de trabalho de dados para mostrar por que permissões excessivas às vezes são operacionalmente necessárias, mas ainda assim inseguras.

O agente de teste executa uma tarefa rotineira de qualidade de dados. Ele lê uma tabela de clientes, calcula indicadores de qualidade e publica um resumo em um painel interno.

Suas ferramentas disponíveis incluem uma consulta à tabela, uma atualização do painel e uma função que concede a outro usuário acesso à tabela. A última capacidade é desnecessária para essa revisão específica. Contudo, o mesmo agente a utiliza em outras atribuições legítimas.

Remover a ferramenta de concessão de acesso reduziria o risco imediato. Também impediria o agente de concluir trabalhos válidos de provisionamento sem uma configuração ou identidade separada. É nesse ponto que o princípio de privilégio mínimo estático se torna difícil para agentes de uso geral.

A sessão começa com uma solicitação restrita: verificar a tabela de clientes e publicar um resumo. Um invasor havia inserido anteriormente uma instrução em um campo controlado pelo usuário nessa tabela.

O texto oculto se apresenta como uma nota de auditoria. Ele instrui o agente a conceder a um endereço externo acesso aos dados de clientes e, em seguida, continuar a verificação de qualidade original.

Isso é uma injeção indireta de prompt porque a instrução maliciosa chega por meio de dados recuperados. O usuário nunca pediu ao agente que alterasse permissões, e o invasor nunca precisou de acesso direto à conversa do agente.

Sem a política de intenção, o agente de teste do Omnigent segue a instrução inserida. Sua identidade está autorizada a usar a ferramenta de concessão de acesso, portanto uma verificação convencional de permissões vê uma operação válida de um ator válido.

Em seguida, o agente registra a concessão como atividade normal de auditoria. Esse detalhe ilustra um segundo problema: os logs de atividade podem registrar uma operação com precisão sem revelar que ela violou o objetivo real do usuário.

Com a autorização baseada em intenção ativada, as mesmas ferramentas e credenciais continuam disponíveis. O resultado muda porque cada operação é comparada ao propósito aprovado de qualidade de dados.

A leitura da tabela recebe uma decisão de PERMITIR. A publicação da atualização solicitada no painel recebe uma decisão de PERGUNTAR, permitindo que um humano confirme a gravação. A concessão de acesso ao endereço externo recebe uma decisão de NEGAR.

A atribuição legítima ainda é concluída após a aprovação da atualização do painel. A ação injetada falha porque não contribui para o propósito declarado da sessão.

Este exemplo dá aos controles de permissão no databricks um significado mais preciso. A questão deixa de ser apenas se o agente pode modificar o acesso. O sistema também avalia se essa modificação pertence a uma sessão de qualidade de dados.

O teste reflete um problema prático das empresas. Um agente conectado a uma base de conhecimento pesquisável, plataforma de dados ou ambiente de suporte pode encontrar textos com muitos níveis de confiança. Um comentário de usuário e uma instrução de administrador podem entrar no mesmo contexto do modelo.

Humanos reconhecem o contexto organizacional de forma imperfeita, mas podem questionar uma solicitação incomum. Modelos podem interpretar textos maliciosos bem elaborados como parte da tarefa, especialmente quando se parecem com uma instrução empresarial comum.

Os pesquisadores de segurança do Google definem a injeção indireta de prompt como instruções maliciosas incorporadas em conteúdos processados por um sistema de IA. Sua recente análise de ameaças na web encontrou tanto tentativas maliciosas quanto muitos textos benignos que se assemelham a padrões de injeção.

Essa combinação complica a filtragem de conteúdo. Um detector que procura frases como “ignore as instruções anteriores” encontrará artigos acadêmicos, tutoriais de segurança e discussões inofensivas. Um ataque sofisticado pode usar linguagem empresarial sem marcadores maliciosos evidentes.

A autorização baseada em intenção aborda o problema pelo lado da ação. Ela não precisa provar que um campo da tabela é hostil antes de bloquear uma alteração de permissão não relacionada. Ela pergunta se a chamada de ferramenta resultante apoia a tarefa.

Essa é a inversão central na demonstração da Databricks. A operação perigosa não parece não autorizada para o sistema de identidade. Ela se torna não autorizada apenas quando o propósito entra na decisão.

Por Que o Acesso Baseado em Identidade Deixa os Agentes Excessivamente Expostos

A principal pressão recai sobre os sistemas de identidade e acesso que tratam o escopo de uma credencial como o limite final para softwares autônomos.

O controle de acesso baseado em funções continua essencial. Ele limita quais recursos uma identidade pode alcançar e quais operações pode solicitar. Os controles baseados em intenção não podem compensar com segurança o fato de um agente possuir acesso de administrador a uma organização inteira.

No entanto, as funções tendem a permanecer estáveis, enquanto as atribuições dos agentes mudam rapidamente. Um agente de programação pode revisar um repositório, criar uma branch, implantar um serviço ou modificar uma issue em sessões diferentes. Cada atribuição exige um subconjunto diferente das mesmas capacidades disponíveis.

Criar uma identidade para cada tarefa possível produziria uma grande carga de provisionamento. Conceder a uma única identidade reutilizável escopos amplos cria um problema de autoridade ambiente, no qual as credenciais permanecem disponíveis além de sua finalidade imediata.

Credenciais de curta duração e com escopo restrito podem reduzir essa exposição. Elas funcionam melhor quando os sistemas conseguem prever os recursos e ações exatos necessários antes da execução. Fluxos de trabalho abertos de agentes frequentemente descobrem esses requisitos durante o trabalho.

O modelo do Omnigent adiciona uma restrição no nível da sessão sem exigir uma nova identidade para cada conversa. Um humano declara o que o agente deve realizar e, em seguida, a política avalia as ações propostas em relação a essa declaração.

Para agentes autônomos, a Databricks afirma que a intenção pode ser definida na especificação do agente durante o design. O agente em execução não pode ampliá-la nem removê-la.

Agentes interativos lidam com a decisão de forma diferente. O agente redige uma política a partir da descrição do usuário em linguagem natural, mas um humano a aprova quando a sessão começa. A política não pode mudar em segundo plano durante essa sessão.

Essa etapa de aprovação humana importa porque a inferência de intenção cria sua própria vulnerabilidade. Se o modelo pudesse redefinir silenciosamente o propósito após ler conteúdo injetado, um invasor poderia convencê-lo a autorizar a ação indesejada.

O Omnigent também nega ao agente em execução ferramentas para remover, editar ou desativar sua intenção. Adicionar outra política requer aprovação humana, e uma adição permissiva não pode substituir uma negação existente.

Esses controles criam resistência à adulteração em torno da configuração de políticas. Eles não tornam infalível a avaliação subjacente de intenção.

A documentação da política integrada afirma que seu controle intent_based_authorization registra a primeira mensagem do usuário como intenção da sessão. Em seguida, ele pergunta antes de chamadas de ferramenta sem uma conexão plausível com essa intenção. A documentação também afirma que a política exige uma configuração de LLM e falha de forma aberta sem uma.

Esse último comportamento merece atenção. Um controle de segurança que se torna permissivo quando seu avaliador está indisponível cria uma condição de implantação que as equipes precisam testar e monitorar. Em geral, ambientes de produção exigem falhas visíveis, validação de configuração e alertas quando um componente de política obrigatório fica indisponível.

O uso de um avaliador de LLM cria outra troca. O raciocínio em linguagem natural consegue entender relações entre tarefas que regras estáticas não captam. Ele também pode produzir decisões inconsistentes quando prompts, modelos ou o contexto ao redor mudam.

Essa tensão explica por que a Databricks apresenta a intenção como parte da segurança de agentes em camadas. Uma política pode interromper uma concessão de acesso fora da tarefa, enquanto outro controle limita o risco cumulativo. Regras separadas de prevenção contra perda de dados podem governar quais informações fluem por uma chamada que, de outra forma, seria permitida.

O NIST também identificou a autorização como um problema não resolvido para agentes. Sua proposta sobre identidade de agentes, de fevereiro de 2026, pergunta como as organizações deveriam aplicar controles de identidade, autorização, auditoria e não repúdio a software autônomo.

A proposta inclui especificamente controles para prevenir e mitigar injeção de prompt. Esse escopo mostra por que identidade e propósito não podem continuar sendo discussões separadas.

Um agente autenticado ainda pode tomar uma decisão prejudicial. Uma ação alinhada ao propósito ainda pode expor dados sensíveis se seus argumentos ou destino forem inseguros. Controles eficazes precisam considerar conjuntamente identidade, tarefa, dados, ação e consequência.

Para compradores empresariais, a resposta exigida é arquitetural. Revisões de segurança não podem mais terminar com uma lista de escopos OAuth ou funções de contas de serviço. As equipes precisam documentar como cada ação de alto impacto permanece conectada a um objetivo aprovado pelo usuário durante a execução.

A Autorização Baseada em Intenção Acrescenta Julgamento e Novos Modos de Falha

O Omnigent reduz uma lacuna de autorização ao colocar julgamento assistido por modelo diretamente no caminho de aplicação.

Esse design oferece flexibilidade, mas também cria incerteza. “Plausivelmente conectado à tarefa” não é uma propriedade totalmente determinística.

Considere um agente encarregado de investigar uma interrupção em produção. Ler logs claramente se encaixa na tarefa. Reiniciar um serviço pode se encaixar depois que o agente identifica uma falha. Rotacionar credenciais poderia ser necessário se as evidências indicarem um comprometimento.

Uma política restrita poderia bloquear as ações necessárias para a recuperação. Uma política ampla poderia permitir que um invasor apresentasse uma alteração de credenciais não relacionada como resposta a incidentes. A aprovação humana pode resolver parte da ambiguidade, mas solicitações frequentes podem desacelerar o trabalho e incentivar consentimento automático.

Portanto, o modelo ALLOW, ASK e DENY depende de calibração cuidadosa. ASK é particularmente importante porque dá às operações incertas, mas legítimas, um caminho adiante sem conceder autonomia silenciosa.

Decisões ASK em excesso criam fadiga de aprovação. Operadores podem aprovar solicitações sem examinar o motivo, o destino ou os dados afetados. Decisões ASK insuficientes deslocam operações ambíguas para permissão automática ou negação desnecessária.

A política também avalia chamadas de ferramentas, não todas as consequências de uma chamada permitida. A Databricks observa explicitamente que a intenção restringe quais ações são executadas, e não o que trafega por essas ações.

Uma atualização aprovada de dashboard ainda poderia incluir dados confidenciais. Uma resposta de email permitida poderia ser enviada ao destinatário errado. Uma consulta legítima ao banco de dados poderia retornar mais registros do que a tarefa exige.

A autorização baseada em intenção precisa, portanto, operar junto com validação de argumentos, prevenção contra perda de dados, controles de destino, limites de taxa e sistemas de auditoria. Seu valor vem de acrescentar propósito à autorização, não de substituir esses controles.

A OpenAI descreve um modelo relacionado de fonte e destino em sua análise de segurança de agentes. Um resultado perigoso geralmente requer tanto conteúdo controlado por um invasor quanto uma capacidade que se torna prejudicial no contexto errado.

Esse enquadramento apoia o foco do Omnigent em restringir ações. Ele também destaca por que nenhum classificador isolado pode resolver o problema. Os sistemas devem reduzir o impacto da manipulação mesmo quando não conseguem detectar a entrada maliciosa.

Pesquisas independentes apontam na mesma direção. O artigo Task Shield, da ACL 2025, avalia se cada instrução e chamada de ferramenta contribui para um objetivo especificado pelo usuário.

No benchmark AgentDojo, os pesquisadores relataram uma taxa de sucesso de ataque de 2,07% e utilidade de tarefa de 69,79% com GPT-4o. Esses resultados se aplicam àquele benchmark e configuração, não à implementação do Omnigent.

O indicador de utilidade expõe a troca por trás das defesas de alinhamento à tarefa. Um sistema pode bloquear ataques e também impedir trabalho legítimo. A segurança só melhora quando a política preserva conclusão suficiente de tarefas para continuar utilizável.

A Databricks não publicou resultados comparáveis de benchmark para seu novo controle. A demonstração mostra um campo injetado, um agente, três ferramentas e um propósito declarado. Ela não estabelece desempenho geral em sessões longas ou tarefas empresariais ambíguas.

Ainda não há evidência pública sobre aprovações falsas, negações falsas, latência do avaliador ou comportamento da política após atualizações de modelo. Essas medições determinarão se a abordagem avança além de exemplos persuasivos.

Os invasores também se adaptarão. Eles podem criar instruções injetadas que pareçam conectadas à tarefa declarada. Uma instrução pode alegar que conceder acesso é necessário para verificar a mesma tabela em análise.

A demonstração publicada já usa essa estratégia ao descrever o destinatário externo como auditor. A política ainda bloqueia a concessão porque a intenção aprovada permanece restrita, mas tarefas mais complexas produzirão limites menos evidentes.

Uma instrução maliciosa também poderia visar argumentos dentro de uma ferramenta permitida. Se a sessão permite atualizações de dashboard, um invasor poderia tentar inserir campos confidenciais no corpo do dashboard. O alinhamento de propósito apenas no nível da ferramenta não necessariamente detectaria essa variação.

Portanto, as equipes que avaliam controles de databricks permission devem testar decisões de política em vários níveis. Elas precisam de solicitações comuns, solicitações ambíguas, conteúdo injetado, justificativas comerciais enganosas e argumentos maliciosos dentro de operações permitidas.

Elas também devem registrar por que cada decisão ocorreu. Uma equipe de segurança não consegue investigar uma aplicação inconsistente se os logs contiverem apenas ALLOW, ASK ou DENY sem a intenção relevante e a ação proposta.

A comparação mais útil não é entre controle de intenção e segurança perfeita. É entre controle de intenção e autorização baseada apenas em identidade, dentro de um sistema em camadas.

Nessa comparação, o Omnigent fecha uma lacuna real. A questão restante é se as equipes conseguem definir o propósito com precisão suficiente para obter proteção sem transformar cada ação útil do agente em uma revisão manual.

Três Sinais Mostrarão se o Modelo do Omnigent se Sustenta

A próxima fase deve ser julgada pela qualidade mensurável da aplicação, não pela clareza da demonstração inicial.

O primeiro sinal é uma suíte de avaliação reproduzível. O Omnigent precisa de testes que abranjam diferentes modelos, estruturas de teste, ferramentas e estratégias indiretas de injeção.

Resultados úteis separariam sucesso de ataque, conclusão de tarefas legítimas, aprovações falsas, negações falsas e taxas de escalonamento humano. Eles também deveriam mostrar se pequenas mudanças na redação produzem decisões materialmente diferentes.

Um desempenho sólido em testes adversariais reforçaria o argumento da Databricks de que o propósito pode se tornar uma entrada confiável de autorização. Alta variação entre modelos ou prompts enfraqueceria o argumento a favor de verificações de intenção assistidas por modelo como um limite de aplicação.

O segundo sinal é um comportamento de falha seguro para implantação. A documentação do Omnigent afirma que a política integrada falha de forma aberta quando nenhuma configuração de LLM está disponível.

Os usuários devem observar validação na inicialização, alertas administrativos, opções de falha fechada e registros claros de auditoria quando o avaliador não puder ser executado. Uma política contextual oferece pouca proteção se a deriva de configuração puder removê-la silenciosamente.

O tratamento visível de indisponibilidades do avaliador fortaleceria o design. Um comportamento permissivo contínuo sem avisos destacados deixaria uma lacuna operacional grave.

O terceiro sinal é a adoção além dos exemplos dos autores. Equipes reais precisam publicar políticas para programação, suporte, operações de dados, email, calendários e delegação entre múltiplos agentes.

Esses exemplos devem revelar como as organizações definem intenção para atribuições que legitimamente evoluem. Eles também devem mostrar com que frequência os usuários recebem solicitações ASK e se essas solicitações melhoram as decisões.

Um uso mais amplo testaria a promessa central do design: um agente pode manter capacidades úteis enquanto exerce apenas o subconjunto necessário para a tarefa atual. Repetidas burlas de política ou fadiga de aprovação intolerável enfraqueceriam essa promessa.

É por isso que o lançamento do Omnigent importa além de um único framework de código aberto. Desenvolvedores de agentes estão criando sistemas que leem informações não confiáveis e agem por meio de credenciais empresariais válidas. O risco resultante fica entre o controle de acesso convencional e a segurança de modelos.

Databricks permission está se tornando uma decisão em duas partes: essa identidade pode agir e essa ação atende ao propósito aprovado?

Essa segunda pergunta não eliminará a injeção de prompt. Ela cria um ponto para interromper uma instrução injetada depois que ela influencia o modelo, mas antes que alcance uma ferramenta consequente.

Os desenvolvedores devem começar identificando ações cuja autorização muda conforme o contexto da tarefa. As equipes de segurança podem então testar se as políticas de intenção negam operações não relacionadas, escalam as ambíguas e preservam o trabalho legítimo.

Compradores empresariais devem pedir aos fornecedores evidências sobre esses três resultados. Um controle que bloqueia tudo não é uma autorização útil. Um controle que preserva todos os fluxos de trabalho enquanto deixa passar solicitações adversariais não é uma proteção significativa.

A pergunta prática agora é inevitável: se um agente de IA tem permissão para executar uma ação, quais evidências aplicadas de forma independente mostram que a ação atende ao propósito atual do usuário?