Como dar a um agente de IA acesso a dados empresariais de forma segura

A arquitetura: o agente é um cliente, o sistema é a autoridade

Comece pela forma, porque a maioria dos erros são erros de forma. Uma pessoa pede algo ao seu agente. O agente decide quais ferramentas chamar. Cada chamada passa por uma camada de permissão que pertence ao sistema empresarial, não ao agente, e só então chega a um módulo como finanças ou CRM. O agente nunca toca no banco de dados, nunca possui uma credencial de banco de dados e nunca vê uma ferramenta que sua pessoa não poderia usar.

O princípio por trás da imagem é uma frase: o agente age com a autoridade da pessoa que representa, e nunca mais. Tudo o que vem a seguir neste artigo é uma maneira de tornar essa frase verdadeira sob pressão, quando o modelo está errado, quando um documento que lê contém instruções ou quando um token vaza.

O OWASP Top 10 para aplicações LLM nomeia a falha que esta arquitetura previne: agência excessiva, que é dividida em funcionalidade excessiva (ferramentas além do que o trabalho precisa), permissões excessivas (mais acesso a jusante do que o necessário) e autonomia excessiva (nenhuma verificação independente antes de uma ação de alto impacto). Suas mitig ações leem como uma especificação para a camada de permissão: executar no contexto do usuário, minimizar as ferramentas e suas permissões, impor autorização no sistema a jusante em vez de confiar no modelo, e exigir a aprovação de uma pessoa para ações de alto impacto.

Cinco controles, e onde cada um reside

Os controles não são novos; são os controles que você já aplica a uma pessoa com acesso ao sistema, aplicados a um cliente que age por essa pessoa. A tabela diz o que cada um responde, onde é aplicado e como é a falha quando está ausente. A coluna de localização é a mais importante. Um controle aplicado no prompt é uma sugestão.

Identidade: conectar-se como uma pessoa, via OAuth, nunca com uma chave compartilhada

A especificação de autorização do Protocolo de Contexto do Modelo é precisa sobre isso. Um servidor remoto atua como um servidor de recursos OAuth 2.1; o cliente obtém um token através de um fluxo de autorização padrão com PKCE; o cliente deve declarar para qual servidor o token é usando o parâmetro de recurso; e o servidor deve validar que cada token foi emitido especificamente para ele, rejeitando qualquer outro. A especificação proíbe explicitamente o repasse de token, onde um servidor aceita um token que não emitiu e o encaminha para baixo, pois isso destrói tanto a trilha de auditoria quanto a fronteira de confiança.

Na prática, é isso que significa "faça login uma vez, sem token para colar". A pessoa adiciona o endereço do espaço de trabalho ao seu agente, é enviada para uma página de login normal, aprova a conexão e o agente recebe um token que a identifica e funciona apenas contra aquele espaço de trabalho. A orientação da Anthropic para conectores personalizados no Claude é revisar os escopos que um servidor solicita, limitá-los sempre que possível e conectar-se apenas a servidores em que você confia. Um fornecedor que, em vez disso, pede que você cole uma chave de API da empresa em uma configuração de agente pulou o primeiro controle e tornou os outros quatro muito mais difíceis.

Escopo: filtrar antes de oferecer, verificar novamente ao executar

Um agente descobre o que pode fazer ao perguntar ao servidor pela sua lista de ferramentas. O design certo responde a essa pergunta por pessoa: a lista que um agente contador recebe é diferente da lista que um agente diretor recebe, e nenhuma inclui ferramentas para módulos que seu papel não pode ver. Este é o conselho da OWASP para minimizar a funcionalidade tornado concreto, e tem um segundo benefício: um modelo que nunca é mostrado uma ferramenta não pode ser convencido a chamá-la.

Filtrar a lista não é suficiente por si só, porque os papéis mudam, as sessões persistem e os clientes armazenam em cache. A mesma verificação deve ser executada novamente quando cada chamada chega, em relação às permissões da pessoa naquele momento. Abaixo está uma lista de ferramentas na forma que o protocolo define, para um papel que pode ler faturas, mas não registrar pagamentos. A ferramenta ausente é o ponto.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      { "name": "searchInvoices",
        "description": "Search invoices by number, reference, contact, amount, status, date range.",
        "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "outstanding_only": { "type": "boolean" } } },
        "annotations": { "readOnlyHint": true } },
      { "name": "getInvoice",
        "description": "Read one invoice in full: status, totals, dates, contact and lines.",
        "inputSchema": { "type": "object", "properties": { "invoice_id": { "type": "string" } }, "required": ["invoice_id"] },
        "annotations": { "readOnlyHint": true } }
    ]
  }
}

// recordPayment, sendInvoiceReminders and deleteInvoice exist in the system.
// They are not in this list because this person's role cannot use them.
// If the agent calls one anyway, the server answers with a permission error.

Uma resposta de lista de ferramentas no formato definido pela especificação MCP, com nomes de ferramentas do módulo de contabilidade Sois. A especificação também diz que os clientes devem tratar anotações como readOnlyHint como não confiáveis, a menos que o servidor seja confiável, o que é mais uma razão pela qual o servidor, e não a anotação, deve ser a entidade que aplica a regra.

Injeção de prompt: os dados podem responder

A ameaça específica para agentes é que os dados que eles leem podem conter instruções. Um e-mail de um cliente que termina com uma linha dizendo ao agente para encaminhar a lista de fornecedores para um endereço externo; um documento que diz para marcar cada fatura como paga. O modelo pode ou não cumprir, e nenhum comando pode garantir que não o fará, razão pela qual a injeção de comandos está em primeiro lugar na lista da OWASP e por que tanto a Anthropic quanto a OpenAI alertam sobre isso em suas orientações de conectores.

A defesa é a arquitetura, não o modelo. Um agente que só recebe as ferramentas que sua pessoa pode usar não pode encaminhar o que sua pessoa não pode ver. Um pedido para marcar faturas como pagas é verificado pelo sistema em relação às permissões da pessoa, não em relação à crença do modelo de que foi solicitado. Ferramentas consequenciais são marcadas para que o cliente pergunte a uma pessoa primeiro: o ChatGPT atualmente requer confirmação manual em uma conversa antes de ações de escrita, e a orientação da OpenAI é manter a aprovação ativada para ferramentas que modificam dados; o Claude solicita aprovação por ferramenta e aconselha reservar "permitir sempre" para servidores confiáveis. E o log registra a tentativa, então uma injeção que foi bloqueada é visível depois, em vez de silenciosa.

Orçamento e registros: torne o trabalho do agente tão revisável quanto o de uma pessoa.

O orçamento é importante por duas razões. A óbvia é o custo: um agente que recebe um resultado vago continuará chamando ferramentas até que algo o impeça, e a OWASP lista o consumo ilimitado como um risco por si só. A mais sutil é o raio de explosão: um limite por integração restringe o quanto um agente comprometido ou confuso pode fazer antes que uma pessoa perceba. Quando o próprio agente da pessoa faz o raciocínio, o custo da IA fica com ela; quando o agente do sistema faz isso, o limite deve ser definido por integração e visível por ação.

Os logs transform tudo isso de uma promessa em algo que você pode auditar. Cada chamada deve registrar para quem o agente atuou, qual ferramenta, as entradas, o resultado e o tempo, no mesmo lugar onde o sistema registra o que as pessoas fizeram. O teste é se um líder financeiro pode descobrir o que o agente fez na conta de um cliente no mês passado tão facilmente quanto pode para um colega. A especificação do MCP pede aos clientes que registrem o uso da ferramenta para auditoria; um sistema empresarial não deve depender do cliente para isso, porque o cliente não é o sistema de registro.

Uma lista de verificação que você pode aplicar a qualquer sistema.

Leve isso a qualquer fornecedor, incluindo nós. Cada um é um sim ou não, e cada um tem um teste em vez de uma pergunta a fazer.

1. O agente se conecta como uma pessoa nomeada via OAuth, sem uma chave de empresa para colar. Teste: conecte-se a partir de um cliente MCP externo e veja o que a página de login solicita.
2. A lista de ferramentas varia conforme o papel. Teste: conecte-se como um usuário restrito e como um administrador e compare o que o agente oferece.
3. A verificação é repetida quando a ferramenta é executada. Teste: remova uma permissão de um usuário conectado durante a sessão e tente a ação novamente.
4. O acesso falha de forma restrita. Teste: chame uma ferramenta que o papel não deveria ter e confirme que você recebe uma recusa, não um resultado.
5. Os gastos podem ser limitados por integração e visualizados por ação. Teste: defina um limite pequeno e veja-o ser aplicado.
6. Cada ação é registrada contra a pessoa, com entradas e resultados, onde o sistema registra todo o resto. Teste: leia o log de uma execução que você acabou de fazer.
7. Ferramentas consequenciais são marcadas para confirmação então o cliente pergunta a uma pessoa. Teste: peça ao agente para enviar dinheiro ou excluir um registro e confirme que você é perguntado primeiro.

Sois é um sistema construído para passar esta lista, e a forma no topo do artigo é sua forma. Um espaço de trabalho é um servidor MCP; qualquer cliente MCP se conecta adicionando o endereço do espaço de trabalho e fazendo login uma vez via OAuth; as ferramentas são filtradas por função antes de serem oferecidas e verificadas novamente quando são executadas; o acesso falha fechado; os gastos podem ser limitados por integração; cada ação é registrada; e redes construídas na plataforma têm seu próprio banco de dados, armazenamento, domínios e chaves. Execute a lista de verificação contra isso de qualquer maneira. O valor de uma lista de verificação é que ela não aceita a palavra de ninguém.

Perguntas que as pessoas fazem

Este artigo é revisado quando os produtos que descreve mudam. Próxima revisão agendada: 4 de dezembro de 2026.