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 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 para um serviço de AI, para permitir, negar ou reter 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 depois que um principal tem acesso. Assim como um filtro de linha ou uma máscara de coluna, 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 objeto 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.
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 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_policyde nível superior carrega os detalhes estruturados, incluindo o blocoreason. 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. - 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:
- 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 personalizada é executada em ambos os pontos. Ela inspeciona a fase atual (event:type) e decide como agir, de modo 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 são definidas com uma opção phases e algumas são executadas em apenas uma fase (por exemplo, a detecção de jailbreak é executada apenas na fase de entrada e a detecção de alucinação apenas na fase de saída).
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 a cadeia para no primeiro DENY. O Databricks avalia as políticas em ordem crescente de classificação na fase de entrada (ON CALL, menor classificação primeiro) e na ordem inversa na fase de saída (ON RESULT). Use a classificação para controlar quais verificações são executadas primeiro.
Avaliação dentro de uma classificação
A Databricks avalia as políticas na mesma classificação em dois estágios:
- Políticas de LLM como juiz de bloqueio são executadas em paralelo. Estas são as políticas integradas que bloqueiam conteúdo (
DENY), como detecção de conteúdo inseguro. Como são verificações apoiadas por modelo, executá-las simultaneamente significa que sua latência adicionada é aproximadamente a da avaliação única mais lenta, não a sua soma. - As políticas restantes são executadas sequencialmente , mas somente se cada política paralela no primeiro estágio permitir a interação. Este estágio abrange políticas SQL personalizadas e políticas que pausam para aprovação (
ASK), avaliadas na ordem em que você as anexou.
A avaliação é interrompida no primeiro DENY em qualquer estágio, então políticas posteriores nessa classificação e todas as classificações superiores não são executadas. Como o Databricks paraleliza as verificações lentas com suporte de modelo, empilhar vários guardrails de bloqueio em um serviço não multiplica sua latência.
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.
Durante a versão beta, as políticas integradas são gerenciadas pela Databricks e não aparecem como funções que você pode navegar no esquema system.ai no Catalog Explorer. Você os seleciona e anexa pelo nome por meio da interface do usuário do Unity AI 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. 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 a entrada, a última mensagem do usuário em um serviço de modelo ou a chamada de ferramenta e seus argumentos em um serviço MCP; para a saída, a resposta do modelo.
O avaliador vê apenas esse item extraído individualmente. Ele não vê o prompt do sistema do serviço protegido ou o conteúdo de imagem e áudio. Por default, cada avaliação é limitada a uma mensagem, portanto, uma política de serviço integrada não consegue detectar padrões que abrangem várias mensagens, como uma escalada gradual ao longo de uma conversa.
Para avaliação de entrada em serviços de modelo e de provedor de modelos, você pode aumentar esta janela. Ao anexar a política, defina quantos turnos de conversa recentes o avaliador recebe, e ele verá essa janela de turnos em vez de apenas a última mensagem. Isso se aplica apenas à entrada e não está disponível em serviços MCP.
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. 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.
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 (ALLOW, DENY ou ASK) e não transformam o conteúdo da solicitação ou resposta durante a versão beta. A única exceção é a política integrada
system.ai.detect_sensitive_data, que pode redigir valores correspondentes em serviços de modelo. - 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 : Por default, uma política de serviço integrada avalia uma mensagem por vez. Para avaliação de entrada em serviços de modelo e de provedor de modelos, você pode aumentar a janela para um número de turnos de conversa recentes. A avaliação de saída e os serviços MCP permanecem como mensagem única. 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.