Autenticação & Autorização

Um sistema MCP-first precisa de uma arquitetura de segurança precisa. Nem todo cliente pode ver todas as tools. Nem todo agente pode invocar todas as tools. Nem toda ação pode ser executada de forma autônoma. Nem toda informação pode chegar ao contexto da IA.

Para isso, é necessário separar claramente os diferentes tipos de identidade e definir o mecanismo de autenticação adequado para cada um.

As cinco identidades

Human User

Um usuário real do sistema, com uma identidade pessoal e permissões vinculadas ao papel. Exemplos típicos: Admin, Funcionário, Cliente, Gerente de Projeto, Agente de Suporte, Diretor.

O Human User é a identidade base. Todos os contextos delegados se referem em última instância a ele.

MCP Client

A aplicação conectada ao servidor MCP. O MCP Client não é um usuário, mas um ator técnico com seu próprio nível de confiança.

Exemplos: Claude Desktop, aplicativo interno de IA, próprio aplicativo móvel, próprio Agent Worker, cliente de integração externo.

O cliente recebe apenas as tools que correspondem ao seu nível de confiança e aos scopes configurados.

Agent Identity

O agente ou workflow concreto que está agindo. Um agente não é idêntico ao cliente que o executa, ele tem uma identidade própria e descrita com capabilities restritas.

Exemplos: Assistente de Vendas, Assistente de Folha de Pagamento, Agente de Suporte, Agente DevOps, Agente de Relatórios, Assistente Pessoal.

Delegated User Context

O Delegated User Context garante que um agente pode fazer exatamente o que o usuário em cujo nome ele age pode fazer. O diretor pode ver dados salariais, mas um Assistente de Vendas Agent não deve receber esses dados em seu contexto.

Service Identity

Para processos backend a backend sem contexto direto de usuário. Service Identities são atores técnicos com scopes estreitos e bem definidos.

Exemplos: Import Worker, Scheduled Job, Sync Worker, Monitoring Agent, Billing Worker.

Autenticação para humanos

Usuários humanos se autenticam por meios estabelecidos. A escolha do método depende dos requisitos de segurança e do contexto:

• E-mail + Senha, acesso base, sempre combinar com 2FA
• Passkeys, alternativa resistente a phishing para senhas, preferível
• TOTP / 2FA, segundo fator para todas as áreas sensíveis
• SSO, para ambientes corporativos com gerenciamento de identidade centralizado
• OAuth / OpenID Connect, para logins de terceiros e acessos delegados

Autenticação para clientes MCP

Clientes MCP são autenticados via OAuth 2.1 com Authorization Code Flow e PKCE. Isso previne ataques de injeção de código e é adequado para clientes públicos (sem Client Secret seguro).

Requisitos adicionais:

• Tokens de acesso de curta duração, minimiza o potencial de dano em vazamentos de token
• Refresh Token Rotation, cada uso de um Refresh Token gera um novo; o antigo é invalidado imediatamente
• Client Allowlist, para sistemas sensíveis, apenas clientes explicitamente registrados são aceitos; o Dynamic Client Registration é restrito ou desativado
• Validação de Redirect URI, apenas URIs previamente registradas são aceitas; redirecionamentos abertos são um vetor de ataque frequente
• Token Binding, quando tecnicamente possível, o token é vinculado ao cliente

Autenticação para serviços internos

A comunicação backend a backend segue requisitos diferentes da autenticação de usuários ou clientes. Aqui são utilizados mecanismos técnicos sem etapa de autenticação interativa:

• mTLS, autenticação TLS mútua; ambos os lados se identificam com certificados
• Tokens de serviço assinados, tokens de curta duração, criptograficamente assinados, com scopes estreitos; sem Shared Secrets de longa duração
• Secret Manager, credenciais, certificados e chaves nunca são armazenados em arquivos de configuração, mas gerenciados e rotacionados via um Secret Manager central
• Zonas de rede privada, serviços internos comunicam-se em segmentos de rede isolados; sem acessibilidade direta da rede pública
• IP Allowlist, para sistemas críticos, o acesso é adicionalmente restrito a intervalos de IP conhecidos
• Token Rotation, tokens de serviço também têm vida curta e são renovados regularmente