ADK-Rust

MCP segurança e autorização

MCP padroniza como capacidades são descritas e chamadas. Ele não decide quais capacidades um agente deve receber nem quais efeitos colaterais um usuário aprovou.

Quatro decisões separadas

  1. Autenticação da conexão — este cliente pode se conectar a este servidor?
  2. Visibilidade da capacidade — quais ferramentas e recursos o modelo pode ver?
  3. Autorização de execução — esta identidade pode realizar esta ação específica sobre este recurso agora?
  4. Aprovação humana — uma ação com consequências exige que uma pessoa confirme suas entradas e efeitos exatos?

Não agrupe essas decisões em uma lista de configuração autoApprove.

Servidores locais stdio

Um processo filho local herda uma posição privilegiada dentro do host da aplicação.

  • Use um caminho absoluto e revisado para o executável.
  • Fixe versões de pacote e binário; evite tags latest.
  • Passe apenas as variáveis de ambiente necessárias.
  • Não coloque segredos em argumentos de linha de comando.
  • Restrinja raízes do sistema de arquivos e diretórios de trabalho.
  • Aplique um perfil de sandbox do sistema operacional quando o servidor lidar com entrada não confiável.
  • Trate descrições, recursos e resultados do servidor como conteúdo não confiável.

Os caminhos de carregamento e atualização em tempo de execução de JSON validam IDs de servidor. McpServerManager não coloca em sandbox o comando configurado.

HTTP remoto transmissível

McpHttpClientBuilder pode aplicar:

  • tokens bearer;
  • um cabeçalho de chave API selecionado pelo chamador;
  • cabeçalhos arbitrários revisados;
  • aquisição fixa de token de credenciais de cliente OAuth 2.0;
  • tempos limite de solicitação; e
  • uma reinitialização de sessão limitada após uma resposta de sessão expirada.

OAuth2Config não é o fluxo completo de autorização MCP. Ele não realiza descoberta de metadados de recurso protegido, descoberta do servidor de autorização, autorização no navegador, PKCE ou negociação de indicador de recurso. Use a rmcp de autorização de APIs ou um componente de identidade quando a implantação exigir esse fluxo.

Limite a solicitação de token para que um servidor de autorização lento ou inacessível não possa travar a inicialização da conexão, e observe que o cliente nunca ecoa o segredo do cliente de volta — os corpos de erro do endpoint de token são redigidos antes de chegarem aos logs:

use adk_tool::mcp::OAuth2Config;
use std::time::Duration;

let auth = OAuth2Config::new(client_id, token_url)
    .with_secret(client_secret)
    .with_scopes(vec!["mcp.read".into(), "mcp.invoke".into()])
    .with_timeout(Duration::from_secs(10)); // token request timeout

O tempo limite padrão da solicitação de token é de 30 segundos.

Exposição e execução de ferramentas

Use with_tools ou with_filter para manter capacidades desnecessárias fora da solicitação do modelo. Em seguida, aplique a autorização e confirmação de ferramenta de ADK-Rust em tempo de execução.

Para ferramentas com consequências:

  • mostre à pessoa os argumentos finais resolvidos;
  • diferencie permissão única de política durável;
  • mantenha a aprovação vinculada ao ID exato da chamada de função;
  • torne as gravações externas idempotentes sempre que possível;
  • armazene a decisão de aprovação e o resultado da ferramenta juntos; e
  • nunca trate uma resposta de protocolo bem-sucedida como prova de um resultado de negócio bem-sucedido sem verificar as evidências retornadas.

Elicitação

Elicitação é uma solicitação do servidor por mais informações, não uma instrução que a aplicação deve obedecer. Revise a mensagem, URL, os campos solicitados e os metadados. Recuse solicitações sem suporte ou inesperadas. Valide todos os valores de formulário aceitos antes de usá-los.

Logs e segredos

Redija variáveis de ambiente, cabeçalhos de autorização, chaves API, respostas de elicitação e argumentos sensíveis de ferramentas. Registre, em vez disso, o ID do servidor, o nome da ferramenta, o ID da tarefa, o status, o tempo, a aprovação e um resumo limitado do resultado.