Políticas de serviço para securitizáveis de AI

info

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 usados para implementar barreiras de proteção para serviços de AI. Se você deseja adicionar barreiras de proteção, como bloqueio de PII, injeção de prompt ou conteúdo não seguro, as políticas de serviço são o mecanismo: o Databricks tem barreiras de proteção integradas para riscos comuns, você pode escrever políticas personalizadas para regras específicas da sua organização e pode aplicar as decisões de um fornecedor terceirizado de barreiras de proteção com uma política de serviço externa.

Isso é 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 geralmente alcançam sistemas externos. As políticas de serviço permitem definir limites de segurança nessa atividade. Por exemplo, você pode exigir o consentimento do usuário antes que um agente envie (push) código para um repository Git por meio de um serviço MCP, recusar uma resposta de modelo que contenha informações pessoalmente identificáveis (PII) ou bloquear conteúdo inseguro.

As políticas personalizadas também podem verificar e impor a presença ou ausência de tags de solicitação fornecidas pelo chamador. Consulte Exigir um projeto qualificado e a referência de tags de solicitação.

As políticas de serviço são um dos três tipos de política de controle de acesso baseado em atributos (ABAC) no Unity Catalog:

• As políticas ABAC GRANT concedem privilégios do Unity Catalog em objetos protegíveis cujas tags governadas correspondem a uma condição. Eles controlam se um principal pode acessar um objeto.
• As políticas de filtro de linha e máscara de coluna controlam quais linhas e colunas um principal vê em uma tabela.
• As políticas de serviço regem o conteúdo de cada solicitação e resposta a um serviço de AI, para permiti-la ou negá-la. Em um serviço MCP, uma política também pode conter uma solicitação de entrada para aprovação.

As políticas ABAC GRANT são de controle de acesso. As políticas de filtro de linha e máscara de coluna e as políticas de serviço são políticas de conteúdo , que regem o que acontece após um principal ter acesso. Assim como um filtro de linha ou máscara de coluna, uma política de serviço SQL personalizada faz referência a uma função do Unity Catalog que contém a lógica de governança e a anexa a um item protegível.

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.

Aspecto	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, tags da solicitação, anotações de ferramentas e contexto do ator
Ponto de aplicação	Antes que a solicitação chegue ao serviço	Antes de o serviço ser invocado (fase de entrada, ON CALL) e após o serviço responder (fase de saída, ON RESULT)
Granularidade	Por principal, por securável	Por solicitação, com base no conteúdo e contexto

Aspecto	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, tags da solicitação, anotações de ferramentas e contexto do ator
Ponto de aplicação	Antes que a solicitação chegue ao serviço	Antes de o serviço ser invocado (fase de entrada, ON CALL) e após o serviço responder (fase de saída, 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. Em vez de um status de erro, o Databricks retorna uma resposta de sucesso (HTTP 200). O turno do assistente carrega uma mensagem curta nomeando a política de serviço que bloqueou, e um objeto databricks_service_policy de nível superior carrega os detalhes estruturados, incluindo o bloco reason. Retornar o bloco como um turno normal evita que clientes conversacionais que reenviam a história completa, como agentes de codificação, disparem novamente o mesmo bloco em cada turno posterior.
• ASK : em um serviço MCP, a política pausa uma solicitação de aprovação do usuário antes da execução da ferramenta. Use esta ação quando um usuário precisar aprovar uma operação sensível, como uma chamada de ferramenta MCP destrutiva. Para agentes externos que chamam um serviço MCP, o prompt de aprovação é entregue por meio de elicitação em modo de URL do MCP. Se uma política de SQL ou Python personalizada retornar ASK para um serviço de modelo ou serviço de provedor de modelos, o Databricks bloqueará a solicitação ou a resposta porque esses serviços não podem pedir a aprovação do usuário. Consulte Escrever uma política de decisão.

Uma política personalizada é uma função SQL definida pelo usuário (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, ou uma política de LLM como juiz que classifica o conteúdo em relação a critérios escritos por você em linguagem natural. As políticas integradas são gerenciadas pelo Databricks, e uma política de serviço externa envia o conteúdo para um serviço de barreira de proteção de terceiros que retorna a decisão.

Pontos de avaliação

A Databricks avalia uma política de serviço em dois pontos em cada interação:

• Entrada (ON CALL): antes que o Databricks invoque o serviço, em relação à solicitação. Use esta fase para inspecionar solicitações antes que elas cheguem ao serviço subjacente. Por exemplo, bloqueie uma solicitação que invoque uma ferramenta MCP destrutiva ou negue um prompt que contenha PII antes que ele chegue a um modelo.
• Saída (ON RESULT): após o serviço responder, contra a resposta. Use esta fase para inspecionar as respostas antes que elas retornem ao chamador. Por exemplo, bloqueie uma resposta que contenha conteúdo alucinado ou dados confidenciais.

Uma função de política SQL personalizada entra em execução nos dois pontos. Ele inspeciona a fase atual (event:type) e decide como agir, para que uma única política possa governar a solicitação, a resposta ou ambas. Para agir em apenas uma fase, faça um branch em event:type no corpo da função. As políticas integradas e as políticas personalizadas do tipo LLM-as-a-judge têm o escopo definido por uma configuração de Fase , e algumas políticas integradas têm execução em apenas uma fase (por exemplo, a detecção de jailbreak tem execução somente na fase de entrada, e a detecção de alucinações, somente na fase de saída). As políticas de serviço externas também são escopadas por fase: você escolhe a fase de entrada, a fase de saída ou ambas ao anexar uma.

Ordem de avaliação

Você pode anexar mais de uma política de serviço a um serviço. Cada anexo tem uma classificação (prioridade), e um DENY em uma classificação interrompe a avaliação de todas as classificações posteriores. O Databricks avalia as classificações em ordem crescente na fase de entrada (ON CALL, com a menor classificação primeiro) e em ordem inversa na fase de saída (ON RESULT). As políticas na mesma classificação mantêm a ordem em que você as anexou em ambas as fases. Use a classificação para controlar quais verificações são execução primeiro.

Avaliação dentro de uma classificação

A Databricks avalia as políticas na mesma classificação em dois estágios:

1. As políticas de LLM-como-juiz de bloqueio são executadas em paralelo. Estas são as políticas de LLM-as-a-judge integradas e personalizadas que bloqueiam conteúdo (DENY), como a detecção de conteúdo não seguro. Como elas são verificações baseadas em modelos, executá-las concorrentemente significa que a latência adicionada é aproximadamente a da avaliação individual mais lenta, e não a soma delas.
2. As políticas restantes são executadas sequencialmente , mas somente se nenhuma política no primeiro estágio retornar DENY. Este estágio cobre políticas SQL personalizadas, políticas de serviço externo, a política system.ai.detect_sensitive_data integrada e políticas que pausam para aprovação (ASK), incluindo uma política de LLM como juiz definida para perguntar em vez de bloquear. Elas são colocadas em execução na ordem em que foram anexadas, sem uma ordem fixa por tipo de política. ASK pausa uma chamada de entrada apenas para serviços MCP. Para serviços de modelo e serviços de provedor de modelos, ASK bloqueia a solicitação ou a resposta.

Uma DENY no estágio paralelo ignora o estágio sequencial. O estágio sequencial não para em um DENY: todas as políticas nele são execução, mesmo depois que uma retorna DENY. Por exemplo, uma política SQL personalizada que nega uma solicitação não impede que uma política de serviço externa posterior na mesma classificação envie o conteúdo para seu fornecedor. Quando mais de uma política nega o acesso, o chamador vê o motivo da primeira DENY na ordem de anexação. Um DENY em qualquer estágio interrompe todas as classificações posteriores; portanto, para ignorar uma política quando outra negar, coloque a política de negação em uma classificação que seja avaliada primeiro.

Como o Databricks paraleliza as verificações lentas apoiadas por modelo, empilhar várias barreiras de segurança bloqueantes em um serviço não multiplica a latência delas.

O diagrama a seguir mostra onde as duas fases se situam em torno de um serviço e o que cada decisão faz:

Para ver as políticas anexadas a um serviço específico e a ordem de execução delas, abra a tab Políticas do serviço e clique em Ver fluxo de execução .

Políticas de serviço integradas

A Databricks fornece políticas de serviço integradas sob o namespace system.ai. Eles cobrem cenários comuns de governança sem SQL personalizado. As AI guardrails da Databricks são políticas de serviço integradas: políticas pré-configuradas e gerenciadas pela Databricks (como detecção de conteúdo inseguro e jailbreak) que você anexa da mesma forma que uma política personalizada:

• 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.
• system.ai.detect_sensitive_data: detecta dados confidenciais estruturados (como números de cartão de crédito e números de Seguro Social) e bloqueia a interação ou redige os valores correspondentes. Ao contrário dos outros, é determinístico (baseado em padrões, sem modelo de avaliador) e pode redigir em vez de apenas bloquear. Consulte Detecte dados confidenciais com uma política de serviço.

Para usar uma política integrada, anexe-a a um serviço. Você precisa de MANAGE no serviço de destino.

nota

As políticas integradas são gerenciadas pela Databricks e não aparecem como funções que você pode navegar no esquema system.ai do Catalog Explorer. Você os seleciona e anexa por nome por meio da interface do Unity Gateway, conforme descrito em Criar e anexar uma política de serviço.

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. O Databricks pré-seleciona um avaliador default, portanto nenhuma configuração é necessária. Para usar um modelo diferente, expanda Opções avançadas quando anexar a política e selecione um. Você precisa de EXECUTE no serviço de modelo escolhido, além de USE CATALOG e USE SCHEMA em seu catálogo e esquema. Consulte Conceder acesso a um serviço de modelo. O Databricks verifica esse acesso quando você anexa a política, portanto, os chamadores do serviço protegido não precisam de acesso ao avaliador. O avaliador é separado do serviço que você está protegendo, de modo que 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. Na fase de entrada, trata-se da mensagem mais recente do usuário em um modelo ou serviço de provedor de modelos, juntamente com uma janela de turnos recentes da conversa (veja abaixo), ou da chamada de ferramenta e seus argumentos em um serviço MCP. Na fase de saída, trata-se da resposta do modelo.

O avaliador não vê conteúdo de imagem ou áudio. Na fase de saída e nos serviços MCP, ele avalia apenas esse único item extraído.

Na fase de entrada dos serviços de modelo e de provedor de modelo, o avaliador também recebe uma janela dos turnos recentes da conversa, para que possa identificar padrões que se desenvolvem ao longo de uma conversa, como uma escalada gradual. Ao criar uma política no formulário de política, a janela de conversa assume o valor default de 10 últimos turnos. Você pode alterar o número, defini-lo como 1 para avaliar somente a mensagem mais recente ou selecionar Avaliar a conversa inteira . Uma política que não tem uma janela de conversa definida avalia somente a mensagem mais recente.

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): true se o conteúdo violar os critérios da política.
• confidence (float, 0.0 a 1.0, opcional): a confiança do avaliador na decisão.
• reason (string): uma explicação curta do porquê o conteúdo foi sinalizado. Retornado quando flagged é true.

Quando o avaliador retorna flagged: true, o Databricks bloqueia a interação por default. Em um serviço MCP, uma política configurada para perguntar pausa a solicitação para aprovação humana antes da execução da ferramenta. 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.

Um avaliador do OpenJev não usa este contrato. Em vez disso, ele responde a uma pergunta do tipo sinalizar ou permitir e não retorna nenhum reason. Consulte Usar o OpenJev como avaliador.

O avaliador é um modelo, portanto, seus veredictos não são determinísticos, e o reason é um texto livre curto em vez de dados estruturados. Para ver quais políticas foram executadas em uma solicitação e o que cada uma decidiu, use a tabela de rastreamento unificada. Para ver também o confidence de um juiz e o conteúdo exato avaliado por ele, habilite uma tabela de inferência no serviço de modelo do avaliador. Consulte Depurar e auditar uma decisão de política.

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.

Políticas de serviço externas

Uma política de serviço externa aplica as decisões de um fornecedor terceirizado de barreiras de proteção, como um serviço de segurança de AI ou de prevenção contra perda de dados. Você o anexa com o tipo de guardrail External e o aponta para uma conexão HTTP do Unity Catalog que armazena o endpoint e as credenciais OAuth machine-to-machine do fornecedor. Em cada avaliação, o Databricks envia o conteúdo sob avaliação para o fornecedor, que retorna ALLOW ou DENY com um motivo opcional, e o Databricks aplica o resultado.

O fornecedor deve implementar a API de política externa do Databricks. As políticas de serviço externas retornam apenas ALLOW ou DENY: elas não podem reter uma chamada para aprovação nem redigir o conteúdo. Elas falham fechadas, portanto, um endpoint de fornecedor inacessível ou lento nega a chamada. Consulte Impor um guardrail de parceiro com uma política de serviço externa.

Serviços suportados

Você pode anexar políticas de serviço aos seguintes objetos protegíveis do serviço 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 de política de serviço usa semântica de falha fechada (fail-closed). Quando você anexa uma política por meio do Unity Gateway, o Databricks a valida no momento do anexo, e qualquer erro durante a avaliação resulta em DENY. Os erros incluem erros de usuário na função de política, erros de sistema, campos ausentes no contexto da solicitação e timeouts. Para uma política de serviço externa, os erros também incluem um endpoint de fornecedor inacessível, que retorne um erro ou que retorne um veredito diferente de ALLOW ou DENY.

Uma política mal configurada ou corrompida bloqueia a interação em vez de permiti-la.

Uma política no modo Logs não é de aplicação obrigatória. Ele registra o que a política teria decidido sem bloquear a interação, de modo que até mesmo um DENY em potencial permite que a solicitação prossiga. A validação da solicitação ainda se aplica, incluindo a validação de tag de solicitação.

Limitações

Aplicam-se as seguintes limitações:

• Transformation : as políticas de serviço retornam uma decisão (ALLOW, DENY ou ASK) e não transformam o conteúdo da solicitação ou da resposta. A única exceção é a política system.ai.detect_sensitive_data integrada, que pode redigir valores correspondentes em serviços de modelo.
• External service policies : uma política de serviço externo retorna apenas ALLOW ou DENY e é compatível apenas com autenticação OAuth machine-to-machine. Consulte Limitações da política de serviço externo.
• 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.
• Pass-through de serviço de provedor de modelo : em um serviço de provedor de modelo, o Databricks não avalia políticas de serviço em solicitações de pass-through, que o Unity Gateway encaminha inalteradas para o provedor quando você ativa Encaminhar todos os caminhos de URL . As políticas se aplicam somente aos caminhos de API compatíveis do provedor.
• Janela de conversa : somente a avaliação de entradas em modelos e serviços de provedor de modelos pode usar uma janela de conversa. Os serviços de avaliação de resultados e MCP avaliam uma única mensagem ou chamada de ferramenta. 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.

Próximos os passos

• Criar e anexar uma política de serviço
• Exemplos de políticas de serviço
• Detecte dados confidenciais com uma política de serviço
• Aplicar um guardrail de parceiro com uma política de serviço externa
• Referência da função de política de serviço
• Tutorial: adicionar barreiras de proteção de política de serviço a um serviço de modelo