MCP e agentes confiáveis
Status da revisão: Esta página-base exige revisão especializada antes da aprovação pública. Suas afirmações devem permanecer dentro do escopo declarado aqui.
Model Context Protocol, ou MCP, fornece uma conexão padronizada entre aplicações de IA e resources, prompts e tools externos. Ele define como host, cliente e servidor negociam capacidades e trocam mensagens estruturadas.
Na UbID, MCP é um protocolo de integração para assistência de software governada. Ele não é padrão de credencial de identidade, motor de decisão de confiança ou autoridade para que um modelo de IA emita credenciais, recupere identidades, use chaves institucionais ou altere sistemas de produção autonomamente.
Funções MCP
| Função | Responsabilidade |
|---|---|
| Host | Aplicação de IA voltada ao usuário que gerencia interação, consentimento e política. |
| Cliente | Conector dentro do host que se comunica com um servidor MCP. |
| Servidor | Serviço que expõe resources, prompts ou tools aprovados. |
| Serviço de domínio | Serviço autoritativo da UbID que valida e executa uma operação de identidade permitida. |
| Aprovador humano ou de política | Ator ou regra responsável que autoriza uma transição sensível. |
O modelo pode interpretar e propor. Serviços autoritativos e política determinística continuam responsáveis pela execução.
Resources, prompts e tools
Resources
Resources fornecem contexto estruturado, frequentemente por URIs. A UbID pode usar resources read-only para expor informações aprovadas, como capacidades públicas de arquitetura, status do emissor, tipos de credenciais, suporte de protocolos ou resumos operacionais.
Uma URI de resource não concede acesso irrestrito a banco de dados. O servidor aplica autorização, minimização, filtragem e regras de evidência antes de retornar conteúdo.
Prompts
Prompts podem fornecer templates controlados para workflows recorrentes. Devem ser tratados como assistência versionada, e não como política ou autoridade executável.
Tools
Tools expõem operações com inputs e outputs definidos. A descrição de uma tool não prova que ela seja segura, e a validação de inputs não pode ser delegada a um LLM. Tools sensíveis exigem scopes explícitos, validação determinística, gates de aprovação, idempotência, efeitos limitados e execução auditável.
Padrão de controle da UbID
Operações sensíveis seguem um padrão em etapas:
- Discover — identificar resources e capacidades aprovados.
- Prepare — montar uma solicitação proposta sem executá-la.
- Validate — aplicar deterministicamente verificações de schema, identidade, política, status e risco.
- Approve — obter autorização humana ou decisão explícita de política pré-aprovada.
- Execute — invocar o serviço de domínio autoritativo com credenciais limitadas.
- Evidence — registrar solicitação, verificações, autorização, resultado e referências sem material secreto.
Preparação e validação podem ser amplamente automatizadas. Aprovação e execução permanecem restritas conforme o impacto.
Read-only primeiro
A postura inicial de MCP na UbID prioriza resources read-only e tools de diagnóstico. Read-only não significa sem risco: dados operacionais, metadados de identidade, schemas de credenciais e alertas ainda podem ser sensíveis ou permitir reconnaissance.
Servidores devem, portanto, aplicar menor privilégio, limitação de finalidade, isolamento de tenants, rate limits, filtragem de outputs e consentimento claro do usuário.
Limites de segurança e confiança
Implementações MCP devem considerar:
- prompt injection proveniente de conteúdo não confiável de resources;
- descrições maliciosas ou enganosas de tools;
- comportamento confused deputy;
- scopes excessivos e credenciais de longa duração;
- exposição de dados entre tenants;
- chaining de tools que crie ação de alto impacto não pretendida;
- exfiltração de dados por output do modelo ou sampling;
- replay, execução duplicada e falha parcial;
- substituição não autorizada do servidor;
- desvio de versão e mudanças de capacidades.
O output de uma tool é evidência a ser avaliada, e não motivo para ignorar autorização normal.
Identidade e autorização
A autorização de transporte MCP controla acesso ao servidor. A UbID ainda exige autorização consciente de identidade no nível de cada resource ou tool. O servidor deve conhecer principal, tenant, finalidade e scope aplicáveis a cada solicitação.
O modelo de IA não deve receber chaves privadas brutas, autoridade root de KMS, recovery shares, credenciais irrestritas de banco de dados ou acesso shell direto.
Assistência baseada em evidência
Um assistente confiável deve distinguir:
- fatos observados retornados por resources autoritativos;
- resultados de validação determinística;
- decisões de política;
- interpretação gerada pelo modelo;
- incerteza e evidência ausente;
- ações realmente executadas.
Essa separação impede que texto fluente seja confundido com estado autoritativo da plataforma.
Posição da UbID
Discovery read-only via MCP e assistência operacional fazem parte da baseline de referência implementada da UbID, com expansão controlada planejada para tools adicionais. Ações sensíveis de identidade permanecem sujeitas a autorização de domínio, política explícita, aprovação e evidência.
Como MCP é versionado e continua evoluindo, integrações UbID devem fixar uma versão revisada do protocolo e um conjunto de capacidades, em vez de assumir compatibilidade com todo draft ou extensão.
Limite da documentação pública
Esta página não publica inventários internos de resources, schemas de tools, prompts, tokens, scopes, endpoints operacionais, conteúdo de alertas, system instructions, limiares de guardrails, credenciais de execução nem regras de aprovação em produção.
Padrão-fonte
Consulte Agentes digitais confiáveis e UbID Sentinel AI.