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.
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, pode-se exigir o consentimento do usuário antes que um agente envie código para um repositório Git, remova informações pessoalmente identificáveis (PII) de uma resposta do modelo ou bloqueie 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 de ferramenta MCP destrutiva antes de sua execuçã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.
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.
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.
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 apenas a serviços MCP e serviços de modelo. Serviços de provedor de modelo e serviços de agente não são compatíveis atualmente.