Descobrir quem executa, quem autoriza e quem paga a conta

Uma integração mal desenhada deixa a empresa sem resposta no dia em que um pedido errado aparece no ERP. O gerente comercial gasta parte do dia relançando pedido do e-mail para o sistema. O CTO propõe um agente, o projeto é aprovado e, três semanas depois, chega a mensagem: integramos. A palavra é confortável e descreve pouco, porque cobre arranjos com perfis de risco bem diferentes.

Qual desses arranjos você tem na mão depende de uma pergunta curta: de quem é a credencial usada quando a ferramenta executa. Se for uma credencial de serviço compartilhada pelo time, o log do ERP registra esse usuário técnico como autor de cada pedido. No dia da investigação, o registro aponta para alguém que não tira férias e não pode ser interrogado.

Por que isso chega à diretoria e não fica com o CTO

A consequência é de compliance antes de ser técnica. Um registro que não identifica quem agiu inviabiliza investigação interna e resposta a requisição de autoridade. Derruba também a evidência que sustenta qualquer alegação de controle. Nenhum desses três problemas se resolve com arquitetura depois do fato.

As cinco peças, descritas por responsabilidade

O host é o aplicativo que a pessoa abre. Hospeda a conversa, mostra a ação antes de executar e é o único lugar onde o consentimento pode viver. Cabe a ele pedir aprovação e registrar a decisão.

Dentro do host, cada servidor conectado ganha um cliente próprio. Sete servidores significam sete clientes e sete credenciais no mesmo aplicativo. Cabe ao cliente apresentar a credencial certa ao servidor certo, sem reaproveitar a de um no outro.

Servidor é o programa que expõe as capacidades de um sistema, como o balcão de atendimento daquele sistema. Cabe a ele recusar qualquer credencial que não tenha sido emitida para ele próprio. A especificação trata essa recusa como obrigação normativa.

Já o agente escolhe qual capacidade acionar para cumprir um objetivo. Na prática, não responde por nada: ele age, e a conta recai sobre quem autorizou o que ele pode acionar.

Quanto ao modelo, ele lê e escreve texto e não tem acesso a nada. Todo acesso passa pelas peças acima, distinção que costuma faltar em apresentação de fornecedor.

Sobre quem paga a fatura do modelo, existe uma exceção que vale reconhecer quando o argumento aparecer. O protocolo tinha um recurso, chamado Sampling, em que o servidor pedia ao aplicativo do usuário que gerasse o texto. Assim o servidor dispensava chave própria de modelo e empurrava a fatura para o outro lado.

Desde 28 de julho de 2026, Sampling está depreciado, com janela mínima de 12 meses antes da remoção. A orientação oficial é integrar direto com a API do fornecedor do modelo. Quem construiu integração apoiada nele vai assumir a chave e a fatura; as datas estão em "Ler a data de validade de cada recurso".

A pergunta de responsabilidade tem resposta escrita, pública e datada, e ela surpreende muitos comitês. As empresas que aparecem numa integração típica declaram, cada uma no próprio material, que a verificação do servidor é obrigação de quem consome.

Na Anthropic, a documentação corporativa é a mais explícita. A empresa revisa conectores contra os próprios critérios de listagem antes de incluí-los no diretório. No mesmo trecho, diz literalmente que "doesn't security-audit or manage any MCP server": não audita a segurança nem gerencia servidor MCP algum. Estar listado atesta conformidade com a política de listagem.

Do lado da OpenAI, a página do modo desenvolvedor do ChatGPT descreve o recurso como destinado a quem sabe configurar e testar aplicativos com segurança. Alerta para injeção de instrução, para servidores maliciosos que tentam roubar informação e para erros do modelo em ações de escrita que podem destruir dados.

Para levar a compras, a tabela de responsabilidade compartilhada dos túneis MCP da Anthropic, publicada em 19 de maio de 2026, é a mais útil. Do lado da fornecedora ficam o controle de acesso ao túnel e a validação de certificado. Do lado da sua organização ficam conteúdo, tráfego, proteção das credenciais, chaves privadas, renovação de certificado e autorização em cada servidor.

Há ainda a questão de onde o dado passa. Em setembro de 2026, o conector MCP da API do Claude segue em beta. Não está disponível no Bedrock nem no Google Cloud e não é elegível a retenção zero de dados. Empresa com contrato de retenção zero precisa saber disso antes de ligar o conector.

Sobre por onde as mensagens trafegam, duas linhas bastam agora. O protocolo define dois caminhos: comunicação local, quando o servidor roda na máquina da pessoa, e Streamable HTTP, quando o servidor é remoto. O antigo transporte HTTP+SSE está depreciado. O detalhe de custo fica em "Calcular o que a infraestrutura obriga a manter ligado"; servidor local roda com os privilégios de quem o chamou, sem barreira automática.

Peça hoje ao dono da integração mais avançada da empresa um extrato de dez linhas do log do sistema de destino, gerado por ações do agente. Confira em cinco dias úteis se cada linha traz o nome de uma pessoa, e não de um usuário técnico. Se alguma linha trouxer usuário compartilhado, suspenda novas escritas daquele servidor até a credencial passar a derivar da pessoa.