Políticas de serviço para securitizáveis de AI
Beta
Esse recurso está em Beta. Administradores do account podem controlar o acesso a este recurso do console do account, na página **Prévias**. Consulte Gerenciar prévias do Databricks.
As políticas de serviço permitem governar o conteúdo das interações com os serviços de AI registrados no Unity Catalog — incluindo servidores MCP **externos** e modelos de qualquer provedor, não apenas os hospedados pelo Databricks. As concessões do Unity Catalog determinam *se* uma entidade pode chamar um serviço. As políticas de serviço governam *como* essa interação prossegue, com base no conteúdo da solicitação e da resposta e em quem está realizando a chamada.
As políticas de serviço são os mecanismos que você usa para implementar barreiras de segurança para serviços de AI. Se você busca adicionar barreiras de segurança, como bloqueio de PII, injeção de prompt ou conteúdo não seguro, as políticas de serviço são o mecanismo: a Databricks tem barreiras de segurança integradas para riscos comuns, e você pode escrever políticas personalizadas para regras específicas da sua organização.
Isto é mais importante quando os agentes atuam em nome dos usuários. Um agente herda tudo o que o usuário pode acessar, e os serviços frequentemente alcançam sistemas externos. As políticas de serviço permitem estabelecer limites de segurança para essa atividade. Por exemplo, você pode exigir o consentimento do usuário antes que um agente envie o código para um repositório Git, negar uma resposta do modelo que contenha informação pessoalmente identificável (PII), ou bloquear conteúdo inseguro.
As políticas de serviço são um tipo de política de controle de acesso baseada em atributos (ABAC) com escopo para serviços de AI. As políticas ABAC se dividem em dois grupos: as políticas de controle de acesso (como concessões) decidem se um principal pode alcançar um objeto, enquanto as políticas de conteúdo governam o que acontece depois disso. As políticas de serviço são políticas de conteúdo para serviços de AI, o mesmo papel que as políticas de filtro de linha e máscara de coluna desempenham para tabelas. Assim como esses, uma política de serviço faz referência a uma função do Unity Catalog que contém a lógica de governança e a anexa a um securable.
Como as políticas de serviço complementam as concessões do Unity Catalog
Os privilégios do Unity Catalog e as políticas de serviço abordam diferentes questões de governança e operam em diferentes pontos de aplicação.
Privilégios do Unity Catalog | Políticas de serviço | |
|---|---|---|
Pergunta respondida | Este principal pode chamar este serviço? | Como esta interação deve prosseguir? |
Entradas | Identidade principal e privilégios concedidos | Conteúdo da solicitação, conteúdo da resposta, anotações da ferramenta e contexto do ator. |
Ponto de aplicação | Antes que a solicitação chegue ao serviço | Antes que o serviço seja invocado (ON CALL) e depois que o serviço responde (ON RESULT) |
Granularidade | Por principal, por securável | Por solicitação, com base no conteúdo e contexto |
As políticas de serviço não substituem as concessões do Unity Catalog. Um principal deve ter primeiro os privilégios apropriados do Unity Catalog para chamar um serviço. As políticas de serviço avaliam então o conteúdo de cada interação para impor regras de governança adicionais.
Decisões de política
Uma política de serviço avalia o conteúdo de uma solicitação ou resposta e retorna um de três resultados:
- PERMITIR : a interação continua.
- DENY : a política bloqueia a interação. O chamador recebe um erro estruturado com um motivo opcional.
- SOLICITAR : a política retém a interação para aprovação humana antes de prosseguir. Este o passo de aprovação habilita fluxos de trabalho com intervenção humana para operações sensíveis. Por exemplo, um administrador pode aprovar uma chamada destrutiva de ferramenta MCP antes de sua execução. Para agentes externos que chamam um serviço MCP, esse prompt de aprovação é entregue por meio da elicitação de URL do MCP. Consulte Escrever uma política de decisão.
Uma política é uma função definida pelo usuário SQL (UDF) que recebe o evento de interação (que inclui o ator e o conteúdo da solicitação ou resposta) e retorna um resultado de decisão.
Pontos de avaliação
A Databricks avalia uma política de serviço em dois pontos em cada interação:
- ON CALL : antes que o Databricks invoque o serviço, contra a solicitação. Use esta fase para inspecionar solicitações antes que cheguem ao serviço subjacente. Por exemplo, bloqueie uma solicitação que invoca uma ferramenta MCP destrutiva ou negue um prompt que contém PII antes que chegue a um modelo.
- NO RESULTADO : depois que o serviço responde, na resposta. Utilize esta fase para inspecionar as respostas antes que elas retornem ao chamador. Por exemplo, bloquear uma resposta que contenha conteúdo alucinatório ou dados confidenciais.
Uma função de política personalizada ocorre a execução em ambos os pontos. Ele inspeciona a fase atual (event:type) e decide como agir, assim, uma única política pode governar a solicitação, a resposta ou ambos. Para atuar em apenas uma fase, crie um branch em event:type no corpo da função. Políticas integradas são definidas com uma opção phases em vez disso, e algumas têm execução em apenas uma fase (por exemplo, a detecção de jailbreak tem execução apenas ON CALL e a detecção de alucinação apenas ON RESULT).
Ordem de avaliação
É possível anexar mais de uma política de serviço a um serviço. Cada anexo tem uma classificação (prioridade), e a cadeia para no primeiro DENY. O Databricks avalia as políticas em ordem crescente de classificação em ON CALL (menor classificação primeiro) e na ordem inversa em ON RESULT . Use a classificação para controlar a ordem de execução das verificações.
O diagrama a seguir mostra onde as duas fases se situam em torno de um serviço e o que cada decisão faz:
Políticas de serviço integradas
A Databricks fornece políticas de serviço integradas no catálogo system.ai. Isso abrange cenários comuns de governança sem SQL personalizado. Os guard-rails de AI da Databricks são políticas de serviço integradas: políticas pré-configuradas e gerenciadas pela Databricks (como detecção de PII e conteúdo inseguro) que você anexa da mesma forma que uma política personalizada:
system.ai.block_pii: nega interações que contêm informações de identificação pessoal.system.ai.block_unsafe_content: nega interações que contêm conteúdo inseguro ou prejudicial.system.ai.block_jailbreak: nega solicitações que tentam contornar as instruções de segurança do modelo.system.ai.block_hallucination: nega respostas que contenham conteúdo alucinatório.
Para usar uma política integrada, anexe-a a um serviço. Você deve ter o privilégio EXECUTE na função de política e MANAGE no serviço de destino.
Como funcionam as políticas de serviço integradas
As políticas de serviço integradas são verificações de LLM como avaliador: cada uma executa um prompt selecionado pelo Databricks em um modelo avaliador para decidir se o conteúdo viola a política.
O serviço de modelo do avaliador
Cada política de serviço integrada executa seu prompt em um **serviço de modelo de avaliador**, o modelo que julga o conteúdo. Databricks pré-seleciona um avaliador default, portanto, nenhuma configuração é necessária. Para usar um modelo diferente, expanda **Opções avançadas** ao anexar a política e selecione uma; você precisa CAN QUERY de no modelo que escolher. O avaliador é separado do serviço que você está protegendo, portanto, uma política pode julgar uma solicitação para um serviço de modelo usando um modelo diferente como avaliador.
O Databricks mantém o prompt da política, que é somente leitura. É possível visualizar em Prompt ao anexar a política para ver os critérios exatos que o avaliador aplica.
O que o avaliador recebe
Quando uma política de serviço integrada é executada, o Databricks envia uma solicitação ao avaliador com duas partes:
- Uma mensagem do sistema que contém o prompt de política e um contrato de saída (descrito na seção a seguir).
- Uma mensagem do usuário que contém o conteúdo em avaliação: para uma solicitação (ON CALL), a última mensagem do usuário em um serviço de modelo ou a chamada da ferramenta e seus argumentos em um serviço MCP; para uma resposta (ON RESULT), a resposta do modelo.
O avaliador vê apenas esse único item extraído. Ele não vê o prompt do sistema do serviço protegido, turnos anteriores na conversa, ou conteúdo de imagem e áudio. Como cada avaliação tem escopo de uma mensagem, uma política de serviço integrada não consegue detectar padrões que abrangem várias mensagens, como escalonamento gradual em uma conversa.
Contrato de saída
O Databricks anexa automaticamente um contrato de saída JSON ao prompt da política, para que o avaliador retorne uma decisão estruturada em vez de texto livre. O avaliador retorna:
flagged(Boolean):truese o conteúdo violar os critérios da política.confidence(float,0.0a1.0, opcional): a confiança do avaliador na decisão.reason(string): uma explicação curta do porquê o conteúdo foi sinalizado. Retornado quandoflaggedétrue.
Quando o avaliador retorna flagged: true, o Databricks bloqueia a interação por default. Se a política estiver anexada a um serviço MCP e configurada para perguntar, um resultado sinalizado, em vez disso, pausa a chamada para aprovação humana. Como o Databricks aplica o contrato para você, as políticas de serviço integradas não precisam de configuração além da fase e da classificação.
Custo de avaliação
A Databricks não cobra uma taxa separada para políticas de serviço integradas. Cada avaliação é cobrada como qualquer outra chamada ao serviço de modelo avaliador, portanto, o custo depende de como esse modelo é servido. Os tokens cobrados por cada avaliação cobrem o prompt da política, o contrato de saída, a mensagem extraída e a resposta do avaliador. Para limitar a sobrecarga, mantenha o número de políticas por fase pequeno e prefira um modelo avaliador de baixa latência.
Serviços suportados
Durante a versão beta, é possível anexar políticas de serviço aos seguintes objetos protegíveis de serviço do Unity Catalog:
- Serviços MCP: servidores MCP gerenciados, externos e personalizados.
- Serviços de Modelo: endpoints de LLM hospedados e externos.
- Serviços de provedor de modelo: provedores de modelo externos governados.
Comportamento de falha fechada
A avaliação da política de serviço usa semântica de falha-fechada. Quando você anexa uma política por meio do Unity AI Gateway, a Databricks a valida no momento da anexação, e qualquer erro durante a avaliação resulta em DENY. Os erros incluem erros do usuário na função da política, erros do sistema, campos ausentes no contexto da solicitação e tempos limite.
Uma política mal configurada ou corrompida bloqueia a interação em vez de permiti-la.
Limitações
As seguintes limitações se aplicam durante a versão beta:
- Transformação : As políticas de serviço retornam uma decisão (PERMITIR, DENY ou PERGUNTAR); elas não transformam o conteúdo da solicitação ou da resposta durante a versão beta.
- Serviços compatíveis : As políticas de serviço aplicam-se a serviços MCP, serviços de modelos e serviços de provedor de modelos. Os serviços de agente não são compatíveis.
- Avaliação de mensagem única: Uma política de serviço integrada avalia uma mensagem por vez, portanto, não consegue detectar padrões que abrangem várias mensagens em uma conversa. Consulte Como funcionam as políticas de serviço integradas.
- **Avaliação aninhada**: Se o serviço de modelo de avaliador que você selecionar para uma política de serviço integrada tiver suas próprias políticas anexadas, a Databricks as ignorará ao executar a avaliação. Isso impede a recursão.