O problema
Um arquiteto precisa conectar um sistema baseado em Claude a um serviço interno de faturamento. A primeira instinto é perguntar "qual protocolo é mais fácil de implementar essa semana" — e a resposta rápida costuma ser "expõe uma API REST" ou "usa MCP pra tudo, já que é o padrão novo". Nenhuma das duas é a pergunta certa.
A pergunta certa é: que fronteira de confiança essa integração está cruzando, e quem — ou o quê — está do outro lado dela. Um agente autônomo chamando um serviço interno sem supervisão humana cruza uma fronteira diferente de um usuário aprovando cada ação antes dela acontecer. Um protocolo escolhido pela conveniência de implementação, sem essa pergunta respondida antes, é a causa mais comum de um gap de autorização que só aparece em produção.
Escolha o protocolo pela fronteira de confiança
Cada protocolo de integração resolve um tipo diferente de fronteira:
- API REST/RPC com contrato fixo: certa quando o consumidor já conhece exatamente o formato de entrada e saída, e a integração é ponto a ponto — um serviço específico conversando com outro serviço específico, sem necessidade de descoberta dinâmica de capacidades.
- MCP: certo quando o conjunto de ferramentas precisa ser descoberto dinamicamente pelo lado que consome — um agente que pode precisar de ferramentas diferentes dependendo do contexto, ou múltiplos clientes reaproveitando o mesmo servidor de ferramentas.
- CLI: certo para integração dentro de um ambiente de desenvolvimento ou pipeline de CI, onde o "cliente" é um processo automatizado rodando com as credenciais de quem disparou o pipeline, não um serviço de produção.
- Comunicação agente-a-agente: certa quando dois sistemas autônomos precisam negociar ou delegar tarefas entre si, cada um mantendo seu próprio contexto e decisão — não é o caso padrão, é a exceção que exige justificativa própria.
Escolher MCP "porque é mais moderno" para uma integração ponto a ponto com contrato fixo adiciona a complexidade de descoberta dinâmica sem nenhum benefício — é o distrator mais comum nesse domínio.
Lacunas de autenticação e autorização não aparecem no design — aparecem no incidente
O padrão de falha mais caro em integração não é "o protocolo errado". É a lacuna entre quem o sistema pensa que está autenticado e o que essa identidade está de fato autorizada a fazer. Um exemplo comum: um agente herda a credencial de serviço da aplicação que o hospeda — uma credencial criada para operações amplas do serviço, não para o escopo específico da tarefa do agente. O agente nunca "decide" abusar disso; a superfície de risco já estava lá antes de qualquer decisão do modelo.
Perguntas que expõem essa lacuna antes que ela vire incidente:
- Que credencial esse componente está usando de fato — não a que deveria estar usando, a que está configurada?
- Essa credencial tem escopo mais amplo do que a tarefa específica exige?
- Se esse componente for comprometido ou se comportar de forma inesperada, o que ele consegue alcançar com a credencial que tem?
Least privilege na integração entre sistemas
O princípio não muda entre camadas: cada integração recebe o escopo mínimo necessário pra tarefa específica, nunca o escopo mais conveniente de configurar. Na prática, isso significa: credenciais de serviço específicas por integração em vez de uma credencial compartilhada por toda a aplicação; escopos de leitura quando a tarefa não escreve; expiração curta para credenciais usadas por processos automatizados, não tokens de longa duração "porque é mais simples não renovar".
O distrator típico aqui é justificar um escopo amplo com "pode ser que precisemos disso depois" — a mesma lógica de "capacidade máxima por garantia" que aparece em outros domínios do CCAR-P, e que sempre erra a mesma restrição: o escopo deveria refletir o requisito medido de agora, não uma necessidade hipotética futura.
Coloque em prática
O laboratório desta lição implementa um recomendador de protocolo de integração a partir da fronteira de confiança envolvida, um detector de lacuna de autorização que compara o escopo de uma credencial com o que a tarefa realmente precisa, e um aplicador de least privilege que reduz um pedido de acesso ao mínimo necessário.