Databricks inocente até que uma política combinada bloqueie o risco do agente no ponto de combinação
A Databricks publicou um novo padrão de segurança do Omnigent que bloqueia um agente somente depois que três capacidades, individualmente comuns, formam uma cadeia perigosa. A abordagem da Databricks de inocente até que combinado mira o momento em que dados privados, conteúdo não confiável e comunicação externa se tornam disponíveis em uma mesma sessão.
Essa combinação é conhecida como tríade letal. Um agente pode ler com segurança um arquivo interno, analisar uma página pública ou enviar uma mensagem quando cada ação ocorre isoladamente. Reúna as três capacidades em um único caminho de execução, e uma instrução injetada poderá transformar um acesso legítimo em roubo de dados.
A mudança importante não é mais um alerta sobre injeção de prompt. A Databricks está deslocando a decisão de aplicação das regras para fora do modelo e para o Omnigent, seu meta-harness de código aberto para executar e governar agentes. A camada de políticas registra o que uma sessão encontrou e, depois, altera a forma como trata ações posteriores.
Permissões estáticas perguntam se um agente pode chamar uma ferramenta. Políticas contextuais também perguntam o que aconteceu antes dessa chamada. Essa diferença pressiona equipes que usam acesso amplo e persistente a ferramentas por meio de agentes de programação, agentes de navegador e integrações com o Model Context Protocol.
O que a Databricks mudou no Omnigent
A Databricks está tratando o histórico de um agente como parte de seu conjunto efetivo de permissões.
O estudo de caso de segurança da empresa amplia uma série de posts sobre políticas contextuais no Omnigent. Exemplos anteriores se concentravam no estado da sessão, em ataques de longo prazo e na autorização vinculada à intenção original do usuário.
O exemplo mais recente aplica esse modelo à tríade letal. O pesquisador de segurança Simon Willison definiu o padrão em junho de 2025 como acesso a dados privados, exposição a conteúdo não confiável e um canal de comunicação externo. Seu modelo de ameaça alerta que a combinação dos três dá às instruções injetadas um caminho para roubar informações.
O Omnigent fica acima de um harness de agentes, que é o ambiente de execução que gerencia o modelo, as ferramentas e o ciclo de execução. O projeto oferece suporte a ambientes estabelecidos de agentes de programação e a agentes personalizados, permitindo que uma camada comum de políticas observe suas atividades.
Essa posição importa porque a política não precisa que o modelo subjacente reconheça cada frase maliciosa. Ela pode governar o uso de ferramentas com base em fatos registrados durante a sessão.
Considere um agente encarregado de revisar um documento interno de produto. Ler esse documento é esperado. Enviar um resumo aprovado para um canal da empresa também pode ser esperado.
Agora, suponha que o agente visite uma issue pública, página da web ou repositório que contenha instruções ocultas. Uma solicitação de saída posterior passa a ter um significado de segurança diferente, porque a sessão atravessou outra fronteira de confiança.
Uma allowlist convencional vê as mesmas ferramentas aprovadas durante todo o fluxo de trabalho. Uma política contextual vê uma sequência cujo risco mudou ao longo do tempo.
As políticas do Omnigent podem retornar uma decisão de allow, ask ou deny. Allow permite a ação, ask a encaminha a uma pessoa e deny a bloqueia. Portanto, a resposta pode se tornar mais restritiva à medida que a sessão acumula acessos sensíveis ou eventos arriscados.
Esse modelo de aplicação não exige que toda fonte, ferramenta ou ação seja perigosa por si só. Em vez disso, a política observa combinações que criam um caminho inseguro para os dados.
A Databricks também está oferecendo o Omnigent como uma beta gerenciada conectada à identidade do workspace e aos serviços de modelos. Sua implantação gerenciada atualmente oferece suporte a handlers integrados de políticas contextuais, enquanto funções arbitrárias de políticas personalizadas continuam indisponíveis nesse ambiente.
Essa limitação separa o design de código aberto do produto gerenciado. As equipes que avaliam o anúncio precisam distinguir um padrão de política demonstrado dos controles disponíveis na implantação que escolherem.
Ainda assim, a mudança central é clara. A autorização de agentes está se tornando dependente da sessão, em vez de fixa no login ou no registro da ferramenta.
Por que o conceito de Databricks inocente até que combinado altera a fronteira de segurança
O objeto arriscado já não é uma única chamada de ferramenta; é o caminho que conecta várias chamadas permitidas.
O controle de acesso tradicional avalia identidades, recursos e ações. Uma conta de serviço pode ler um banco de dados, gravar em um bucket ou chamar uma API. Essas regras continuam necessárias porque os agentes ainda operam por meio de credenciais comuns.
Elas não bastam quando linguagem não confiável influencia a forma como essas credenciais são usadas. Um invasor talvez nunca precise roubar um token ou explorar código de aplicação. Basta que conteúdo malicioso alcance um modelo capaz de acessar dados e agir externamente.
O primeiro elemento são os dados privados. Essa categoria inclui documentos internos, código-fonte, credenciais, registros de clientes, e-mails, resultados de bancos de dados e qualquer informação fora da autorização do invasor.
O segundo elemento é o conteúdo não confiável. Uma página da web, ticket de suporte, pull request, e-mail, arquivo compartilhado, resposta de ferramenta ou imagem pode conter instruções controladas por alguém fora da fronteira de confiança do agente.
O terceiro elemento é a comunicação externa. E-mails e solicitações HTTP são exemplos óbvios, mas a categoria é mais ampla. Publicar um comentário, enviar código, carregar um recurso remoto ou gravar em um sistema compartilhado pode criar um canal de saída.
Nenhuma dessas capacidades é incomum. Sua utilidade é justamente o motivo pelo qual a combinação aparece em tantos designs de agentes.
Um agente de pesquisa precisa de fontes externas e contexto interno. Um agente de programação pode ler um repositório privado, consultar documentação pública e enviar uma branch. Um assistente de e-mail lê mensagens não confiáveis, pesquisa correspondências privadas e envia respostas.
Remover permanentemente qualquer capacidade pode tornar o agente consideravelmente menos útil. Solicitações constantes de aprovação criam outro problema, porque os usuários podem se acostumar a aceitar pedidos rotineiros.
O enquadramento da Databricks de inocente até que combinado oferece outra opção. Permita que operações de baixo risco prossigam, mas escale quando o estado da sessão completar uma combinação proibida.
Isso desloca a fronteira de segurança do conector individual para o fluxo de trabalho. Um navegador não é simplesmente confiável ou não confiável. Sua relevância depende de a mesma sessão também conter informações sensíveis e uma rota de saída.
Esse modelo se assemelha ao controle de fluxo de informações, no qual um sistema rastreia como os dados se movem entre níveis de confiança. Quando informações confidenciais entram em um contexto, gravações posteriores em um destino menos protegido recebem tratamento mais rigoroso.
O catálogo de políticas publicado pelo Omnigent já inclui um controle relacionado ao Google Drive. Depois que uma sessão lê um arquivo declarado confidencial, a política pode impedir gravações fora do conjunto confidencial.
O catálogo também inclui uma política de pontuação de risco. Ela acumula pontos de chamadas de ferramentas e rótulos de dados sensíveis e, depois, escala as ferramentas protegidas após um limite configurado.
Esses exemplos mostram por que o estado é central. Uma solicitação de gravação não muda sua forma de API depois que o agente lê um documento sensível. Seu significado muda em razão do histórico da sessão.
O mesmo princípio se aplica à tríade letal. A política procura uma composição perigosa, não uma operação universalmente proibida.
Essa distinção deveria interessar mais às equipes de plataforma do que outro filtro de prompts. Filtros tentam decidir se o texto parece malicioso. A aplicação contextual ainda pode bloquear uma ação insegura quando o modelo ou o filtro deixa de identificar a injeção.
Permissões estáticas perdem a sequência
Uma allowlist estática pode descrever as capacidades disponíveis, mas não consegue explicar como o agente chegou a uma ação.
Suponha que um desenvolvedor autorize um agente a ler um repositório privado, navegar pela documentação e abrir pull requests. Cada permissão dá suporte a um fluxo de trabalho normal de programação.
Em seguida, um invasor insere uma instrução em uma issue, documento de dependência ou página da web recuperada. A instrução diz ao agente para coletar um segredo e incluí-lo na descrição de um pull request público.
A leitura do repositório é permitida. A recuperação da web é permitida. Abrir um pull request é permitido. Um controle que avalia cada solicitação de forma independente pode aprovar toda a cadeia.
Um filtro de conteúdo pode detectar a instrução. Ele também pode deixar passar uma solicitação indireta, dados codificados, um idioma incomum ou uma carga projetada para contornar o modelo-alvo.
Pesquisas sustentam a cautela quanto a depender apenas do comportamento do modelo. O benchmark WASP testou ataques realistas de injeção de prompt contra sistemas de agentes web usando vários modelos e scaffolds.
Os pesquisadores descobriram que os agentes começaram a executar instruções adversariais entre 16% e 86% das vezes nas configurações testadas. O sucesso do invasor de ponta a ponta foi menor, variando de zero a 17%.
Essa diferença é encorajadora, mas não tranquilizadora. Os agentes atuais frequentemente falham antes de concluir um ataque complicado, mas melhorar a confiabilidade dos agentes também pode facilitar a conclusão de fluxos de trabalho maliciosos.
Um sistema não deveria contar com o fato de um agente se confundir no momento certo. Ele precisa de um controle que continue eficaz à medida que os modelos melhoram na execução de múltiplas etapas.
Permissões estáticas também têm dificuldade com ataques retardados. A instrução injetada talvez não provoque uma ação de saída imediata. Ela pode influenciar um plano posterior, uma tarefa delegada, um arquivo gerado ou uma chamada de ferramenta.
Uma política ciente da sessão pode reter fatos relevantes para a segurança durante esse intervalo. Ela não precisa que cada evento suspeito esteja ao lado da ação final no contexto ativo do modelo.
Essa persistência aborda uma fragilidade prática em agentes de longa duração. O histórico de conversa pode ser comprimido, resumido ou dividido entre workers. Um modelo pode esquecer uma restrição anterior mesmo enquanto suas ferramentas e credenciais permanecem disponíveis.
O estado da política deve, portanto, existir fora da janela de texto. A camada de aplicação precisa de seu próprio registro durável de leituras sensíveis, entradas não confiáveis, destinos, aprovações e mudanças de risco.
Essa arquitetura também reduz a dependência do autorrelato do agente. Perguntar ao modelo se ele encontrou conteúdo não confiável é mais fraco do que registrar qual conector forneceu o conteúdo.
Os sinais mais fortes vêm da infraestrutura. Um sistema de documentos conhece a classificação de um arquivo. Um gateway de rede conhece o destino. Uma camada de identidade conhece o usuário e o workspace. Um broker de ferramentas sabe qual operação foi solicitada.
O Omnigent pode combinar esses sinais porque envolve o ambiente de execução. O agente propõe uma ação, mas a política decide se essa ação continua aceitável sob o contexto registrado.
Esse é o ponto de pressão para plataformas concorrentes de agentes. Aprovações no nível da ferramenta são mais fáceis de explicar e implementar. Elas se tornam menos convincentes quando os agentes executam sessões mais longas em mais conectores.
Os fornecedores precisarão mostrar se seus controles acompanham dados e transições de confiança entre ferramentas. Uma longa lista de permissões já não responde à questão central de segurança.
Políticas contextuais interrompem a cadeia antes que os dados saiam
O ponto de controle útil é a transição que completa o caminho de ataque, geralmente uma leitura sensível ou uma ação de saída.
Uma política contextual começa com eventos observáveis. Eles podem incluir uma invocação de ferramenta, um resultado de ferramenta, um rótulo de dados, um destino, uma solicitação ao modelo ou uma aprovação do usuário.
A política armazena fatos selecionados no estado da sessão. Ela pode registrar que o agente consumiu conteúdo não confiável, acessou um objeto confidencial ou tentou se comunicar fora de um limite aprovado.
Eventos posteriores são avaliados em relação a esse estado. Se a próxima operação completar uma combinação proibida, a política poderá exigir aprovação ou negar a solicitação.
A ordem pode variar. Um agente pode ler dados privados antes de visitar uma página não confiável. Pode encontrar primeiro o conteúdo injetado e, depois, solicitar acesso a um arquivo interno.
Uma implementação robusta deve detectar ambos os caminhos. O perigo surge quando as capacidades se conectam, e não de uma ordem fixa.
A aplicação também pode ocorrer em mais de um ponto. Uma política pode bloquear a leitura sensível depois que conteúdo não confiável entra na sessão. Outro projeto pode permitir a análise, mas impedir a comunicação externa subsequente.
Bloquear a saída de dados frequentemente preserva mais utilidade local. O agente pode continuar lendo e redigindo sem ganhar uma via para expor informações. No entanto, os controles de saída devem abranger mais do que funções óbvias de envio.
Um link gerado pode codificar dados. Uma solicitação de imagem remota pode transmitir parâmetros de consulta. Um push de controle de versão, comentário em issue, chamada de analytics ou gravação em documento compartilhado pode cruzar o limite de confiança.
O contexto do destino também importa. Enviar um resumo para um canal interno aprovado é diferente de publicá-lo em um repositório público. Tratar todas as gravações da mesma forma criaria interrupções desnecessárias.
A aprovação humana é valiosa quando o contexto e o destino estão claros. Um aviso útil deve explicar que a sessão leu dados confidenciais, depois consumiu conteúdo não confiável e agora quer contatar um endpoint externo específico.
Uma mensagem genérica de “permitir esta ferramenta” oculta o motivo da escalada. Ela incentiva a fadiga de aprovação, pois o revisor precisa reconstruir manualmente o fluxo de trabalho.
A negação rígida se aplica a combinações que uma organização nunca aceita. Por exemplo, uma política pode impedir que qualquer sessão exposta a conteúdo público envie informações de um conjunto de dados restrito para fora de seu compartimento.
O mecanismo de políticas deve falhar de forma segura quando falta o contexto necessário. Um rótulo de dados ausente, uma ferramenta sem suporte ou um caminho de rede não observado podem criar um ponto cego.
A abordagem mais ampla da Omnigent combina políticas com sandboxing. Um sandbox restringe o acesso ao sistema de arquivos e à rede no limite do sistema operacional, reduzindo o que um agente pode alcançar mesmo que o modelo solicite isso.
Essas camadas atendem a propósitos diferentes. O sandbox limita a capacidade bruta. A política contextual ajusta a permissão com base no estado acumulado da sessão.
Nenhuma delas substitui controles comuns de identidade, autorização de conectores, registros ou prevenção de perda de dados. O anúncio é mais útil quando interpretado como uma camada de aplicação dentro dessa pilha.
O relatório de segurança agentic da OWASP identifica a injeção de prompt como uma das principais técnicas de ataque contra sistemas de IA. Sua mensagem mais ampla é que a segurança de agentes exige controles em torno da execução, das ferramentas, da identidade e da movimentação de dados.
Isso apoia a direção arquitetural da Databricks. Um modelo probabilístico pode sugerir uma ação, mas um limite determinístico deve decidir se a ação é permitida.
O que a política da Databricks não resolve
A aplicação contextual reduz o caminho de ataque, mas sua confiabilidade depende de visibilidade completa e classificação confiável.
A primeira questão não resolvida é a cobertura. Uma política não pode bloquear um canal que não observa.
Um agente pode se comunicar por meio de um conector, comando de shell, solicitação do navegador, recurso incorporado ou artefato gerado. Todo caminho capaz de mover dados para fora do limite deve estar representado no modelo de políticas ou ser restringido em outro lugar.
A segunda questão é a classificação. O sistema precisa saber qual conteúdo é não confiável e quais dados são sensíveis.
Regras simples podem classificar páginas públicas como não confiáveis e documentos nomeados como confidenciais. Ambientes corporativos contêm casos mais difíceis, incluindo unidades compartilhadas, contas de contratados, texto copiado, arquivos gerados e dados reunidos de várias fontes de baixa sensibilidade.
Falsos negativos deixam a combinação perigosa sem detecção. Falsos positivos interrompem o trabalho comum e podem treinar usuários a aprovar avisos sem analisá-los.
A terceira questão é o escopo do estado. Uma sessão é uma unidade conveniente, mas as informações podem se mover entre sessões por meio de arquivos, armazenamentos de memória, caches, subagentes e resumos copiados.
Se um trabalhador lê dados confidenciais e outro envia o resultado, o rastreamento por sessão pode não identificar o fluxo combinado. Sistemas multiagente precisam de regras de propagação que preservem rótulos relevantes entre delegações.
A quarta questão é a integridade das políticas. A camada de aplicação, a configuração e o fluxo de eventos tornam-se infraestrutura crítica de segurança. Atacantes podem mirar lacunas de política, metadados de ferramentas malformados, destinos ambíguos ou comportamentos de falha aberta.
As equipes devem testar o limite real da política, e não apenas o modelo. Avaliações adversariais devem incluir rotas alternativas de saída, ações atrasadas, transferências entre agentes e metadados incompletos.
A quinta questão é a usabilidade. Um controle que pede aprovação com muita frequência pode reproduzir a fraqueza que deveria resolver.
A escalada baseada em risco exige limites cuidadosamente escolhidos e avisos informativos. As equipes de segurança devem medir a frequência de aprovações, a precisão das negações, as taxas de substituição e os motivos pelos quais os usuários aceitam exceções.
A beta gerenciada da Omnigent introduz outra restrição prática. Atualmente, a Databricks documenta suporte a handlers integrados, e não a código de política personalizado arbitrário, no ambiente gerenciado.
Organizações com classificações especializadas ou conectores proprietários devem verificar se as políticas disponíveis expõem contexto suficiente. A flexibilidade do código aberto não se traduz automaticamente em paridade de serviço gerenciado.
Também ainda não há base para tratar uma demonstração como validação universal. O artigo da Databricks explica um padrão de segurança e uma abordagem de implementação. Ele não estabelece que toda configuração da Omnigent bloqueia todas as técnicas de injeção de prompt.
A afirmação correta é mais restrita. A aplicação consciente da sessão pode interromper um caminho de trifeta letal, mesmo quando cada ferramenta individual permanece legítima.
Isso ainda é significativo. A arquitetura de segurança muitas vezes tem sucesso ao remover uma condição necessária de um ataque, e não ao ensinar a aplicação a reconhecer cada mensagem de atacante.
As implementações mais robustas combinarão política contextual com credenciais restritas, listas de destinos permitidos, sandboxing, logs de auditoria e testes independentes. Elas também tratarão definições de políticas como código de segurança versionado.
Três sinais mostrarão se o modelo se sustenta
O próximo teste é verificar se a política contextual se torna infraestrutura mensurável, em vez de uma demonstração persuasiva.
O primeiro sinal é uma cobertura mais ampla entre ferramentas e harnesses de agentes. A Databricks precisa mostrar que rótulos de segurança e estado da sessão sobrevivem a fluxos de trabalho comuns envolvendo navegadores, repositórios de código, sistemas de documentos, shells e agentes delegados.
O suporte em uma lista de recursos não é suficiente. As equipes precisam de evidências de que ações equivalentes recebem aplicação equivalente em diferentes harnesses e implementações de conectores.
Uma cobertura consistente fortaleceria o argumento a favor de um meta-harness compartilhado. Diferenças materiais entre runtimes enfraqueceriam a promessa de uma camada de governança única entre agentes.
O segundo sinal é a avaliação adversarial. A Omnigent precisa de testes reproduzíveis que tentem exfiltração atrasada, saída indireta, transferência entre sessões e manipulação de metadados.
Resultados úteis devem separar detecção, aprovação, negação e movimentação bem-sucedida de dados. Eles também devem informar a conclusão de tarefas benignas, pois uma política que bloqueia todo fluxo de trabalho é segura, mas inutilizável.
Fixtures de teste públicos permitiriam que equipes de segurança reproduzissem os resultados em sua própria configuração. Uma avaliação independente teria mais peso do que um cenário selecionado pelo fornecedor.
O terceiro sinal é a adoção operacional dentro de ambientes Databricks gerenciados. Observe a expansão do suporte a políticas, telemetria mais clara, controles de administração e integrações documentadas com classificações de dados corporativos.
A adoção deve produzir resultados mensuráveis. As equipes precisam saber com que frequência as políticas são acionadas, quais combinações de capacidades provocam escalada e se os revisores revertem ou aprovam a decisão.
Esses sinais importam porque o problema de segurança subjacente crescerá com a utilidade dos agentes. Agentes melhores concluirão tarefas mais longas, usarão mais ferramentas e cruzarão mais limites de confiança sem supervisão constante.
A abordagem da Databricks de inocente até ser combinado oferece um princípio de projeto crível: permitir componentes úteis enquanto bloqueia a composição perigosa. Ela desloca a atenção de saber se um modelo entende um ataque para saber se o sistema ao redor permite que o ataque seja concluído.
Os desenvolvedores devem mapear quais sessões podem acessar dados privados, ingerir conteúdo controlado por atacantes e se comunicar externamente. Compradores corporativos devem perguntar se uma plataforma rastreia essas condições ao longo do tempo, entre ferramentas e trabalhadores delegados.
Se os três continuarem disponíveis sem aplicação contextual, uma tela de aprovação sofisticada não resolve o problema. O próximo passo prático é identificar onde a terceira capacidade entra em cada fluxo de trabalho e, então, posicionar uma política testável nesse limite.
