Para dar acesso aos dados da empresa para agentes de IA com permissão por agente, cada agente precisa de uma identidade definida, do menor escopo necessário, de um registro do que consulta e de um jeito de ter o acesso revogado. O Model Context Protocol (MCP) não impõe a segurança sozinho: segundo a especificação do MCP, a autorização é opcional, e cabe a quem implementa o servidor construir os controles de acesso. No Claude, a central de ajuda da Anthropic sobre conectores diz que a permissão é herdada de cada pessoa no serviço conectado, e cada fornecedor documenta o modelo do próprio servidor.

Por que dar a cada agente o seu próprio acesso importa?

Um agente que usa a credencial de uma pessoa alcança tudo o que essa pessoa alcança, e um conector com credencial compartilhada alcança o que a credencial pode acessar, segundo a central de ajuda da Anthropic. Sem uma decisão do time, o acesso do agente é o acesso de quem o conectou: quem libera o conector define, sem registrar a escolha, o que a IA vai poder ler. Permissão por agente quer dizer que cada agente tem o seu escopo — o conjunto de dados e de ferramentas que ele alcança — e o seu próprio registro de consultas.

Um exemplo: um agente de atendimento que consulta o status de pedidos para responder a clientes não precisa ver a folha de pagamento. São dois acessos diferentes, e quem libera o acesso precisa poder dizer isso de forma explícita, agente a agente.

O que a especificação do MCP cobre de autorização e o que fica com a empresa?

A especificação de autorização do MCP é explícita já no início: a autorização é opcional para implementações de MCP. Quando existe, ela separa dois casos. As implementações com transporte HTTP deveriam seguir a especificação; as que usam stdio — o servidor que roda localmente, na mesma máquina de quem usa — não deveriam, e buscam as credenciais no ambiente. Onde a especificação entra, o servidor MCP protegido atua como servidor de recursos OAuth 2.1, e o cliente MCP atua como cliente OAuth 2.1, em nome do dono do recurso; OAuth é o login em que a pessoa autoriza o acesso sem entregar a senha. Sobre escopo, a especificação diz que o servidor deveria indicar os escopos necessários, seguindo o princípio do menor privilégio, para evitar que o cliente peça permissões excessivas.

O que fica com quem implementa o servidor, seja a empresa ou o fornecedor, aparece no que a especificação deixa fora. A implementação do servidor de autorização — quem emite a autorização — está além do escopo dela, e esse servidor pode estar junto do servidor de recursos ou ser outra entidade. A própria especificação reconhece o limite: o protocolo não consegue impor esses princípios de segurança por si só, e cabe a quem implementa construir os fluxos de consentimento e autorização, os controles de acesso e a proteção de dados. Consentimento é a pessoa dizer o que o agente pode fazer; autorização é o sistema conferir o que cada um pode acessar.

Como o Claude trata a permissão de cada pessoa?

Segundo a central de ajuda da Anthropic, o Claude herda as permissões de cada pessoa no serviço conectado: quem não acessa um arquivo, canal ou registro no sistema de origem também não o acessa pelo conector. Conectores personalizados que usam uma credencial compartilhada — uma única chave de acesso, usada por todos — acessam o que essa credencial pode acessar.

A mesma central de ajuda orienta que, nos planos Team e Enterprise, todos que usam um conector com chave de API acessam o serviço com a mesma credencial, e por isso a credencial deve ser limitada ao que os membros devem acessar. A permissão pode ser revogada a qualquer momento desconectando o conector, nas configurações do Claude ou nas configurações de segurança do serviço de terceiros. A regra é da central de ajuda do Claude; com outro assistente, o modelo de permissão é o da documentação dele.

Como outros servidores MCP aplicam permissão por pessoa e por agente?

Cada fornecedor documenta o modelo do próprio servidor, e vale ler a documentação do sistema que está sendo conectado em vez de supor uma regra geral.

Segundo a documentação do servidor MCP da Snowflake (consultada em 07/10/2026), o servidor MCP gerenciado usa Snowflake OAuth por padrão, com External OAuth opcional — o login pela identidade da própria organização —, e controle de acesso baseado em papéis para o servidor e para as ferramentas. Controle de acesso baseado em papéis, ou RBAC, é o modelo em que as ações permitidas são identificadas por papéis, e não por identidades individuais, segundo o glossário do NIST.

Segundo a documentação da Databricks (consultada em 07/10/2026), o MCP que executa SQL em um data warehouse usa as permissões de quem chama, e o uso dele exige que um administrador da conta habilite um recurso em beta. A página de produto da Pipedrive (consultada em 07/10/2026) diz que o assistente de IA só acessa e altera dados que o usuário da Pipedrive já tem permissão de ver e editar, e que todas as ações ficam registradas no histórico de alterações. A documentação do servidor MCP da Stripe, que está em prévia pública (consultada em 07/10/2026), separa dois métodos de autenticação: OAuth, quando um cliente acessa a Stripe em nome da conta de um usuário, e chave de API de agente, quando uma aplicação de IA precisa de acesso independente e persistente.

Para reunir os dados de várias ferramentas num servidor só, veja como ter um MCP da empresa com os dados de todas as ferramentas.

Como dar a cada agente o seu acesso, passo a passo?

  1. Liste os agentes e o que cada um precisa perguntar. Anote, para cada agente, as perguntas que ele vai responder — “quanto de receita nova entrou em setembro”, “quais pedidos estão atrasados” — e de quais sistemas vêm os dados de cada resposta. O time decide quem é o dono de cada agente, ou seja, quem responde por aquele acesso.
  2. Escolha a identidade de cada agente. Há dois caminhos. No primeiro, o agente consulta em nome de uma pessoa, e o assistente usa as permissões dela, como o Claude faz com os conectores. No segundo, o agente tem credencial própria, como a chave de API de agente do servidor MCP da Stripe (em prévia pública), para acesso independente e persistente, segundo a documentação dela. O time decide qual dos dois vale para cada agente.
  3. Dê o menor escopo possível. A especificação do MCP diz que o servidor deveria indicar os escopos necessários, seguindo o princípio do menor privilégio — dar só o acesso necessário —, e a Snowflake aplica controle de acesso baseado em papéis ao servidor e às ferramentas. O time decide quais dados e quais ferramentas cada agente alcança.
  4. Separe leitura de escrita. No servidor MCP do BigQuery, segundo a documentação do Google (consultada em 07/10/2026), uma ferramenta aceita apenas operações de leitura, e o uso da outra pode ser restringido por política de negação — uma regra que bloqueia o uso de uma ferramenta. A OpenAI avisa, para o ChatGPT, que é possível que ações de escrita ocorram mesmo quando o servidor MCP marcou a ação como somente leitura, então vale conferir a restrição na credencial e na política, e não só no rótulo do servidor. O time decide se o agente pode escrever.
  5. Registre o que cada agente consulta. O registro precisa dizer qual agente leu quais dados. Como exemplo de registro, a página de produto da Pipedrive (consultada em 07/10/2026) diz que todas as ações do assistente ficam no histórico de alterações. O time decide quem lê o registro e por quanto tempo o guarda. Para auditar depois, veja os riscos de segurança de um servidor MCP e como auditar o que as pessoas perguntam.
  6. Teste e revogue. Peça ao agente uma informação fora do escopo dele e confirme que a consulta falha, o que mostra se o escopo está valendo. No Claude, a permissão pode ser revogada a qualquer momento desconectando o conector, segundo a central de ajuda da Anthropic. O time decide quem revoga o acesso e de quanto em quanto tempo revisa a lista de agentes.

Que erros deixam um agente ver mais do que deveria?

  • Usar uma chave de API compartilhada sem limitá-la ao que os membros devem acessar. Nos planos Team e Enterprise do Claude, quem usa um conector com chave de API acessa o serviço com a mesma credencial, e a orientação da Anthropic é limitar essa credencial ao que os membros devem acessar.
  • Confiar só no rótulo de somente leitura do servidor. A OpenAI avisa, para o ChatGPT, que ações de escrita podem ocorrer mesmo quando o servidor MCP marcou a ação como somente leitura.
  • Supor que o protocolo cuida da autorização. A especificação do MCP diz que o protocolo não consegue impor esses princípios sozinho e que cabe a quem implementa construir os controles de acesso.
  • Rodar o servidor localmente na conta de uma pessoa. Segundo a documentação do MCP sobre servidores locais, um servidor local roda como processo filho da conta do usuário, herda as variáveis de ambiente e pode ler o que a conta lê, e nada disso é governado pelo protocolo: depende de como o processo é executado.

Quem precisa ir além, com dados sensíveis e a definição de quem pode ver o quê, encontra o caminho em como garantir acesso controlado a dados sensíveis.

Onde a Nekt entra

A Nekt é uma plataforma de contexto para agentes de IA: conecta as fontes de dados da empresa, governa esses dados com o significado de cada número e os serve a agentes e a pessoas por servidor MCP, API e SQL. Segundo a documentação de permissões do servidor MCP, o token, a chave de acesso que o agente usa, pode ser de acesso total, que alcança o que o seu criador alcança, ou ter escopo, com seleção por tipo de recurso e por ferramenta, sempre limitada ao que o criador ainda alcança. No workshop “Nekt + Claude: construa seu primeiro agente de dados”, publicado em 22/04/2026 no canal da Nekt no YouTube, o apresentador mostra o Claude Code com um token de escopo limitado, que enxerga só três tabelas.

Segundo a documentação de permissões, o token com escopo só é somente leitura se a pessoa selecionar apenas ferramentas de leitura ao criá-lo. Toda requisição de um token fica registrada, inclusive o SQL de cada consulta, com retenção de 7 dias no Starter, 30 no Growth e 90 no Custom, e sem registro no plano Free. As permissões no nível dos dados só são aplicadas nos planos Growth e Custom; no Starter, todo membro acessa todos os dados. Para conhecer a plataforma, dá para criar uma conta gratuita.

Perguntas frequentes

Existe ferramenta de MCP com controle de permissão por usuário?

Sim, mais de um fornecedor documenta isso para o próprio servidor. A Snowflake usa controle de acesso baseado em papéis para o servidor e para as ferramentas, a Databricks, em beta, executa SQL com as permissões de quem chama e a Pipedrive diz que o assistente só acessa e altera dados que o usuário já tem permissão de ver e editar. No Claude, a central de ajuda da Anthropic diz que o assistente herda as permissões de cada pessoa no serviço conectado.

A especificação do MCP exige autorização?

Não. Segundo a especificação do MCP, a autorização é opcional para implementações de MCP. Quando existe e o transporte é HTTP, as implementações deveriam seguir a especificação; as que rodam localmente, pelo transporte stdio, não deveriam, e buscam as credenciais no ambiente.

Qual a diferença entre dar acesso a uma pessoa e dar acesso a um agente?

Dar acesso em nome de uma pessoa faz o agente consultar com as permissões dela; dar acesso ao agente é dar a ele uma credencial própria, independente e persistente. Na Stripe, cujo servidor MCP está em prévia pública, o OAuth serve quando um cliente acessa a Stripe em nome da conta de um usuário, e a chave de API de agente serve quando uma aplicação de IA precisa de acesso independente e persistente, segundo a documentação dela. No Claude, o conector herda as permissões de cada pessoa, e um conector personalizado com credencial compartilhada acessa o que a credencial pode acessar.

O que é controle de acesso baseado em papéis?

Segundo o glossário do NIST, é um modelo de controle de acesso a recursos em que as ações permitidas são identificadas por papéis, e não por identidades individuais. A Snowflake documenta o uso desse modelo, o RBAC, no servidor MCP gerenciado dela, para o servidor e para as ferramentas.

A permissão muda quando o servidor MCP roda no computador da pessoa?

Sim. Segundo a documentação do MCP sobre servidores locais, um servidor local roda como processo filho da conta do usuário, herda as variáveis de ambiente e pode ler o que a conta lê, e nada disso é governado pelo protocolo: depende de como o processo é executado. A permissão de um servidor local é a da conta que o executa.

Em resumo

  • Segundo a especificação do MCP, a autorização é opcional e o protocolo não impõe sozinho os controles de acesso: cabe a quem implementa o servidor construí-los.
  • Quem faz o quê: o time define se o agente consulta em nome de uma pessoa ou com credencial própria, e qual é o escopo de cada agente.
  • No Claude, a permissão é herdada de cada pessoa no serviço conectado, e uma credencial compartilhada acessa o que ela acessa.
  • O critério que decide é o menor escopo necessário, com leitura separada de escrita e a restrição conferida na credencial e na política, não só no rótulo do servidor.
  • Cada agente precisa de um registro do que consultou e de alguém que revogue o acesso; no Claude, a permissão pode ser revogada desconectando o conector, segundo a Anthropic.

Equipe Nekt — conteúdo da Nekt, plataforma de contexto para agentes de IA. Atualizado em outubro de 2026.