Seu servidor MCP é seguro. O livro-razão por trás dele, não.

Em um artigo recente publicado aqui na Unite.AI, Gil Feig apresentou seis práticas recomendadas para criar um servidor MCP seguro. São recomendações sólidas, que todos os que disponibilizam um servidor MCP devem seguir. O conselho de atribuir a cada integração “uma função própria e granular, limitada estritamente às permissões necessárias” está absolutamente correto. Mas ele também pressupõe que o sistema do outro lado tenha funções granulares. Isso aponta para uma suposição mais ampla, raramente explicitada: a de que os sistemas por trás do servidor podem ser protegidos com o mesmo padrão de segurança.

Nos sistemas empresariais, muitas vezes isso não é possível. Lidero a equipe de engenharia responsável por uma camada de integração que se conecta a 32 sistemas de contabilidade e ERP, com um servidor MCP opcional por cima. É comum encontrarmos agentes bem autenticados, com escopos bem definidos e devidamente registrados do nosso lado, gravando dados em sistemas que não têm como saber que um agente esteve envolvido.

Este artigo trata da segunda parte do problema: o que os sistemas conectados realmente oferecem, o que é possível controlar na camada de integração e onde esse controle termina.

Onde a especificação MCP transfere a responsabilidade

A especificação de autorização do MCP define claramente os limites do que abrange. O servidor MCP é um servidor de recursos OAuth para seus clientes. Quando chama uma API de um sistema conectado, atua como um cliente OAuth independente, com um token separado, emitido pelo sistema correspondente. A transferência do token do cliente é expressamente proibida.

Esse é o modelo correto. Isso também significa que tudo o que diz respeito à chamada ao sistema conectado, incluindo quem tem permissão para fazer o quê e como isso é registrado, depende inteiramente desse sistema. A especificação não pode resolver aquilo que o sistema não oferece.

O mesmo vale para as orientações da OWASP sobre autonomia excessiva. Elas recomendam limitar ao mínimo necessário as permissões que as extensões de um agente têm em outros sistemas e executar ações no contexto do usuário em nome de quem atuam. Ambos são bons conselhos. Ambos pressupõem que o outro sistema tenha como definir permissões mínimas e o contexto do usuário.

O que os sistemas conectados realmente oferecem

Veja como são, do ponto de vista de quem integra sistemas, os 32 sistemas de contabilidade e ERP aos quais nos conectamos.

Um terço não oferece OAuth

21 dos 32 usam OAuth. Os outros 11 dependem de credenciais estáticas: chaves de API, nome de usuário e senha ou um par de tokens. Algumas dessas chaves nunca expiram. Um sistema amplamente utilizado informa na documentação que seus tokens de API têm validade ilimitada enquanto o usuário existir.

Longa validade, poucas opções de revogação

O OAuth ajuda menos do que se poderia esperar. Um provedor emite tokens de atualização com validade de aproximadamente 20 anos. Essa credencial foi concebida para durar mais que o agente que a utiliza, a estrutura sobre a qual ele foi desenvolvido e, muito possivelmente, a pessoa que clicou em “permitir”. Em outro sistema, nem mesmo os tokens de acesso expiram.

E, quando uma credencial é comprometida, a questão é quem pode desativá-la. O padrão para isso, a revogação de tokens OAuth (RFC 7009), existe desde 2013. Ainda assim, em cerca de quatro em cada dez sistemas, não há nenhum meio técnico para que quem faz a integração revogue as credenciais. Todos os sistemas que usam chaves de API estão nesse grupo. A única opção restante é pedir ao cliente que remova o acesso manualmente.

Escopos genéricos, nenhuma identidade do agente

A maioria das chaves estáticas simplesmente herda todos os privilégios do usuário que as criou; apenas alguns sistemas permitem restringir uma chave a endpoints específicos. Muitos sistemas OAuth têm escopos, mas eles costumam ser genéricos, como “contabilidade, leitura e gravação”. E, em nenhum dos 32 sistemas, encontramos uma maneira de registrar pela API, na mesma transação, tanto o agente quanto a pessoa em nome de quem ele atua. Agentes externos aparecem como o usuário que os conectou ou como um usuário genérico do sistema. É revelador que, nos casos em que um fornecedor incorporou agentes ao próprio produto, como fez a Microsoft no Business Central, tenha atribuído a eles contas de usuário próprias. É o mesmo modelo que recomendo adiante, mas reservado aos agentes do próprio fornecedor.

O que a camada de integração pode impor

Nada disso significa que seja preciso desistir. Entre o agente e o sistema de contabilidade, você controla quase tudo:

• credenciais individuais para cada agente na sua própria camada
• seus próprios escopos, por exemplo, acesso somente de leitura às faturas
• um registro de auditoria de cada chamada do agente, incluindo a pessoa em nome de quem ele atuou
• chaves de idempotência, para que um agente que repita uma tentativa não registre a mesma fatura duas vezes
• limites de frequência por agente
• etapas de aprovação antes de qualquer gravação

Nada disso depende dos recursos oferecidos pelo sistema de destino. Hoje já é possível ter uma camada de controle de acesso robusta no nível da integração e, se você permitir que agentes se aproximem de dados financeiros, deve criar uma.

Onde o controle termina

O que não é possível fazer é estender essa camada para além dos limites do sistema. Três coisas falham nesse ponto.

Atribuição

No sistema de contabilidade, o lançamento feito pelo agente aparece como se tivesse sido feito por quem autorizou a conexão ou por um usuário técnico. Quem audita o sistema vê um lançamento feito por esse usuário. Não é possível saber se foi uma pessoa ou um agente que o fez. Para o livro-razão, um agente que registra 400 faturas às 3h da manhã parece exatamente um gerente financeiro muito diligente. Para reconstituir o ocorrido, são necessários os registros do integrador, o que representa uma cadeia de confiança diferente daquela do sistema oficial de registro. Em uma investigação forense ou auditoria, essa é uma posição frágil.

A maioria das organizações também não está muito à frente nesse aspecto. Em uma pesquisa da Cloud Security Alliance, apenas 28% dos entrevistados disseram conseguir rastrear com confiabilidade as ações dos agentes até uma pessoa ou sistema em todos os ambientes, e 44% usam ou planejam usar chaves de API estáticas para seus agentes.

Privilégio mínimo

É possível garantir que um agente só leia faturas. Mas, se o sistema de destino não tiver escopos, as credenciais por trás da sua camada continuarão oferecendo acesso total. Quem obtiver essas credenciais poderá contornar completamente a sua camada e todas as regras que você definiu nela.

Revogação

É possível desativar seu próprio agente instantaneamente. Isso não ajuda se as credenciais do próprio sistema de destino forem comprometidas. E, nos quatro em cada dez sistemas que não têm um endpoint de revogação, o interruptor de emergência é um e-mail para o cliente.

A resposta pragmática: um usuário dedicado para o agente

A medida mais útil que você pode tomar hoje não tem nada de glamorosa. Crie um usuário dedicado para o agente no sistema de destino e conecte o agente somente por meio desse usuário.

Isso funciona em qualquer sistema que permita criar usuários e oferece três vantagens que a camada de integração não pode proporcionar:

• Atribuição no sistema oficial de registro. Os lançamentos aparecem como “agente de contas a pagar”, não como se tivessem sido feitos pelo gerente financeiro que clicou em “conectar” seis meses atrás.
• Uma forma de revogar o acesso, mesmo sem uma API para isso. O cliente pode desativar o usuário na interface, o que funciona em sistemas sem endpoint de revogação.
• Privilégio mínimo parcial. Quando o sistema tem algum tipo de modelo de funções, o usuário do agente geralmente pode ter o acesso restrito aos módulos de que realmente precisa.

Os custos são reais. Alguém precisa criar o usuário manualmente durante a integração inicial, o que gera atrito justamente no pior momento. Cerca de metade dos sistemas cobra por cada usuário adicional, desde alguns euros por mês em ferramentas para pequenas empresas até mais de cem euros em um ERP completo. Vários outros limitam o número de usuários conforme o plano, de modo que adicionar mais um usuário pode exigir um plano mais caro para toda a empresa. Além disso, um usuário de serviço sem responsável se torna um risco por si só, parte da proliferação de identidades não humanas que a Unite.AI já abordou. Como qualquer outra conta, ele precisa ter um responsável e uma data de revisão.

Isso também não resolve a falta de escopos nos sistemas que não os têm. Mas devolve a atribuição e a revogação ao sistema que os auditores realmente consultam.

A resposta estrutural: identidade delegada

A resposta correta já existe no papel. Troca de tokens OAuth 2.0 (RFC 8693) diferencia a representação de outra identidade da delegação. Na delegação, o agente mantém sua própria identidade e o token registra que ele atua em nome de uma pessoa, por meio da declaração “act”.

Aplicado à contabilidade, isso significaria que:

• o livro-razão registra que esse agente fez um lançamento em nome dessa pessoa
• os escopos são concedidos por delegação, não por usuário
• uma única delegação pode ser revogada sem afetar a conta da pessoa

Pelo que consegui apurar, nenhum dos 32 sistemas oferece algo parecido. Por enquanto, portanto, isso continua sendo uma orientação, não uma opção. Assim, o pedido deve ser dirigido aos fornecedores de software de contabilidade e ERP, e não aos integradores: os agentes já estão fazendo lançamentos nos seus livros-razão, e suas APIs devem ser capazes de indicar isso.

O que fazer antes de um agente acessar um livro-razão

Se você estiver conectando agentes a sistemas de contabilidade ou ERP, siga esta breve lista de verificação:

1. Mapeie o modelo de credenciais de cada sistema de destino. Ele usa OAuth ou uma chave estática? Por quanto tempo a credencial é válida? Ela tem escopos? É possível revogá-la?
2. Crie sua camada de acesso mesmo assim. Identidade por agente, escopos, idempotência e aprovações são responsabilidades suas, independentemente dos recursos oferecidos pelo sistema de destino.
3. Use um usuário dedicado para o agente sempre que o sistema permitir. Aceite o esforço de integração inicial e o custo da licença como o preço a pagar pela atribuição.
4. Mantenha seu próprio registro de auditoria à prova de adulteração. Em muitos sistemas, esse será o único registro da participação de um agente.
5. Documente o risco residual. Quando um sistema não tiver escopos nem revogação, diga isso ao seu cliente e registre-o também no seu próprio registro de riscos.

A fronteira é o ponto central

Proteger seu servidor MCP é necessário. Não é suficiente. A segurança de um agente que grava em um livro-razão é determinada na fronteira entre sua camada e o sistema de registro, e hoje essa fronteira é definida pelos sistemas, não por você.

A boa notícia é que a lacuna está bem definida. Os padrões existem. O que falta é o suporte a eles nos sistemas que mantêm os registros.