Pular para o conteúdo principal

Conecte um agente de IA

Dê a um agente de IA acesso aos seus registros governados, sem lhe dar acesso a nada que a pessoa que o opera já não possa ver.

Antes de começar

  • Uma organização com registros carregados.
  • Uma conta que consiga entrar, com as permissões que o agente deve ter — o agente recebe exatamente estas e nada mais.
  • Um cliente compatível com MCP.

1. Entenda o que você está concedendo

Vale ser preciso, porque é o oposto da integração habitual:

  • O agente age como o usuário autenticado. Ele carrega a identidade dessa pessoa a cada requisição.
  • Não há conta de serviço. O endpoint não tem identidade privilegiada própria.
  • Conceder acesso ao agente concede nenhum acesso a dados. As permissões existentes do usuário já decidiram isso.

A implicação prática: para limitar o que um agente alcança, limite o usuário sob o qual ele roda. Esse é todo o controle.

2. Obtenha um token

O agente se autentica como o usuário pelo seu provedor de identidade, exatamente como o console faz. Não há tipo de credencial separado nem atalho de desenvolvimento que se comporte de forma diferente da produção.

3. Configure o cliente

Aponte o cliente para o endpoint e forneça o token. O cliente descobre as ferramentas disponíveis; não há esquema separado a instalar.

4. Faça uma pergunta

Comece com algo difícil de responder contra sistemas de origem brutos:

Quantos clientes temos?

A resposta conta entidades, não linhas de origem — a plataforma resolveu as duplicatas, então a contagem é de pessoas reais, não de registros.

Depois:

Esta pessoa aparece em algum outro lugar nos nossos dados?

Essa é a pergunta que sistemas de origem estruturalmente não conseguem responder.

5. Verifique que a governança se sustenta

O cartão de resumo como uma conta restrita o vê, com três identificadores reduzidos aos quatro últimos caracteres O que uma conta restrita recebe: Social Security Number, Tax ID e National ID reduzidos aos quatro últimos caracteres. Um agente atuando por essa pessoa recebe exatamente isto.

O mesmo cartão de resumo como uma conta autorizada o vê, com os três identificadores por extenso O mesmo registro, o mesmo cartão, uma conta autorizada — os mesmos três campos por extenso. O mascaramento é aplicado quando a resposta é gerada, então a diferença é decidida no servidor, não pela tela.

Faça isso uma vez. É a verificação que importa.

Entre como um usuário com permissões restritas — alguém para quem um campo sensível está mascarado — e peça esse campo ao agente.

Ele devolve o valor mascarado. Não um erro, não uma recusa, e não o valor real: o agente recebeu a máscara e só pode repeti-la. Não há o que reconstruir, porque o mascaramento é aplicado na geração da resposta, não por endpoint.

Depois peça ao agente de um usuário somente-leitura para alterar algo. É recusado, em todo modo de autonomia — autonomia governa se uma pessoa é consultada, nunca o que a requisição pode fazer.

Esta é a demonstração que vale fazer para as partes interessadas

Dois usuários, a mesma pergunta, respostas diferentes — cada uma correta para quem perguntou. Mostra a propriedade de governança diretamente, em vez de descrevê-la.

6. Confira o log de auditoria

Toda ação de agente é registrada, atribuída ao usuário cuja identidade foi utilizada. Não há caminho separado nem menos rastreável.

A seguir


Última verificação no commit d3c2586b (2026-08-03)