Agentforce e MCP externo: as três formas de conectar (e onde a autenticação quebra)

Todo projeto de Agentforce chega num ponto em que o cliente pergunta: "e se o agente precisar puxar dado de um sistema que não é Salesforce?". A resposta técnica existe desde que o Model Context Protocol virou padrão de integração, mas o que pouca gente para para desenhar direito é a parte de identidade. Dentro do org, a resolução de quem é quem já está resolvida: usuário Salesforce mapeado para usuário Slack, herdado automaticamente por qualquer coisa construída em cima, canal de registro, agente instalado no Slack, tanto faz. O problema aparece no momento exato em que esse agente atravessa um servidor MCP para conversar com Snowflake, Docusign ou Google Drive. Ali, a identidade Salesforce deixa de ser a única variável em jogo. Cada sistema externo tem seu próprio modelo de autenticação e autorização, e é sua responsabilidade como arquiteto costurar isso sem abrir buraco de segurança.

Existem hoje três arquiteturas possíveis para colocar um servidor MCP externo na frente dos seus agentes Agentforce ou do Slackbot. Cada uma resolve identidade de um jeito diferente e serve para um cenário diferente.

Opção 1: Agentforce conecta direto no MCP externo

Essa é a opção certa quando o agente precisa viver dentro do org e, mais importante, quando ele precisa combinar contexto Salesforce com contexto externo numa única cadeia de raciocínio, não em chamadas separadas que alguém (ou algo) precisa depois costurar manualmente.

Exemplo que uso bastante em conversa de arquitetura: um agente avaliando se uma oportunidade forecastada está realmente em risco precisa da data de fechamento e da categoria de forecast que estão no Salesforce, junto com o histórico de redlines que está no CLM ou no Docusign. Três rodadas de redline com duas semanas de prazo é sinal vermelho. As mesmas três rodadas com seis semanas de prazo, nem tanto. Só dá para chegar nessa leitura combinando os dois contextos no mesmo turno de raciocínio, e é exatamente isso que essa arquitetura entrega.

Na prática, você registra o servidor MCP externo no Agentforce Registry, em Setup, e configura endpoint e método de autenticação. Se o servidor exige autenticação, ele precisa suportar OAuth 2.0, e você vai encontrar dois caminhos possíveis dependendo do que o servidor MCP suporta:

• Autenticação por usuário (per-user): via named credential pareada com external credential usando Per-User Principal. Cada usuário Salesforce passa por um consentimento OAuth único na primeira vez que aciona a conexão, autenticando no sistema externo como ele mesmo. Salesforce guarda um token separado por usuário a partir daí. Isso significa, na prática, que cada usuário Salesforce precisa ter conta correspondente no sistema externo antes da conexão resolver para ele. E aqui mora um detalhe que costuma pegar arquiteto desprevenido: uma vez que a identidade resolve, quem manda no que o agente pode fazer é o modelo de permissão do sistema externo, não o Salesforce. Se você não está preparado para auditar o acesso de cada usuário lá fora, um service account escopado é o caminho mais seguro.
• Service account (client credentials flow): uma credencial única resolve toda chamada, independente de quem pediu. É tudo ou nada: o superfície de dados e ação que essa conta alcança precisa ser algo que você aceita que qualquer usuário autorizado a usar aquele agente também alcance.

Uma dica prática que vale ouro em implementação: não assuma qual grant type o servidor suporta, verifique. Servidor MCP compatível com a especificação publica isso num endpoint de discovery padrão. Procure authorization_code se precisa de resolução por usuário, client_credentials se está mirando service account.

Outro ponto que muita gente ignora: registrar o servidor não dá ao agente acesso a tudo que ele expõe. Você escolhe, ferramenta por ferramenta, agente por agente, na configuração de subagente do Agent Builder, quais capacidades externas combinam com qual raciocínio interno. É granular por design, e deveria ser tratado como tal no seu desenho de governança.

Opção 2: Slackbot conecta direto no MCP externo

Aqui o cenário é diferente: a tarefa é nativa do Slack e não precisa de contexto Salesforce. Puxar um arquivo do Figma, checar um incidente no PagerDuty, rascunhar um envelope Docusign a partir de uma thread. Nenhum desses casos ganha algo passando pelo Salesforce sem necessidade, então por que forçar o hop?

O client MCP nativo do Slack já está em GA e conecta o Slackbot a qualquer app via MCP através de um registry no Slack Marketplace. Já são mais de 20 apps parceiros disponíveis, incluindo Atlassian, Box, Canva, Docusign, Linear, Notion e Zoom. A resolução de identidade segue o mesmo princípio da Opção 1 (per-user), mas passa pela infraestrutura de credenciais do Slack, não pelas named credentials do Salesforce.

O fluxo de aprovação tem três portões: o desenvolvedor (parceiro ou interno) declara o servidor MCP no manifest do app Slack junto com o escopo OAuth mcp:connect; um admin aprova via revisão padrão do Slack App Directory, vendo exatamente quais domínios de servidor MCP estão sendo solicitados; e, quando o usuário conecta, dispara um fluxo OAuth cujo token fica guardado na infraestrutura de credenciais do Slack.

Dois pontos de atenção que mudam desenho de projeto:

• Toda chamada MCP é feita como o usuário Slack, mapeado para sua identidade equivalente no sistema externo. Permissão e controle de acesso são aplicados na origem, exatamente como se a pessoa tivesse aberto a ferramenta diretamente. Pergunta de arquiteto: é esse o modelo de acesso que você realmente quer?
• Ferramentas de escrita e exclusão exigem confirmação explícita do usuário antes do Slackbot agir, e o GA atual ativa modo somente leitura por padrão. Desenhe qualquer workflow que precise de ação assumindo que vai ter uma etapa de confirmação no meio.

Um gotcha real de projeto: o controle de acesso ainda é só a nível de app, aprovado para todo mundo que tem acesso ao app ou para ninguém. Escopo granular por usuário, grupo ou role ainda não existe. Se o seu desenho pede um piloto restrito ou rollout mais controlado, essa camada do Slack simplesmente não consegue aplicar isso hoje.

Opção 3: Agentforce conecta no MCP externo e expõe subagentes como ferramentas para o Slackbot

Essa terceira arquitetura combina as duas anteriores. O Slackbot não fala direto com o sistema externo, ele fala com as ferramentas do agente Agentforce, e é o Agentforce quem gerencia a conexão com o MCP externo. Na prática, isso constrói em cima da Opção 1: a integração Slack-Salesforce determina o mapeamento de usuário Slack para usuário Salesforce, e a conexão Agentforce controla o escopo de acesso ao servidor MCP externo.

Quando isso faz sentido? Dois motivos reais que vejo em projeto: você já tem o Agentforce conectado ao MCP externo e quer reaproveitar essa conexão para o Slackbot, ou o agente Agentforce carrega um raciocínio específico, moldado via Agent Script, que o Slack sozinho não consegue reproduzir com a mesma precisão. Se a precisão do raciocínio importa para o caso de uso, essa é razão suficiente para rotear pelo agente em vez de conectar o Slackbot direto.

Em termos de identidade, você está empilhando duas resoluções: a identidade Slack-Salesforce resolve pelo mapeamento padrão da integração nativa, e a identidade Agentforce-sistema externo resolve exatamente como na Opção 1, seja per-user ou service account. É mais peça se movendo, e cada peça precisa ser auditada separadamente.

Service account: trate como decisão binária

Quando per-user não é a estratégia certa, service account é a outra opção de desenho. A desvantagem é óbvia: o acesso não é escopado pelo usuário final. Mas isso também pode ser vantagem, porque se o acesso do usuário no sistema externo é mais amplo ou mais restrito do que você quer que o agente ou o Slackbot tenham, o service account deixa você definir esse limite deliberadamente em vez de simplesmente herdar o que já existe.

O ponto de atenção é que, com service account, toda chamada resolve para uma única credencial, não importa quem perguntou. A decisão não é um exercício de escopo fino, é binária: a superfície de dados e ação que essa conta alcança é algo que todo mundo autorizado a usar aquele agente ou aquele fluxo do Slackbot deveria poder alcançar? Se a resposta for não para qualquer grupo de usuário, service account não é a peça certa ali.