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 na base de dados, nunca detém uma credencial de base de dados e nunca vê uma ferramenta que a sua pessoa não pudesse usar.

O princípio por trás da imagem é uma frase: o agente atua com a autoridade da pessoa que representa, e nunca mais. Tudo o resto neste artigo é uma forma 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 divide em funcionalidade excessiva (ferramentas além do que o trabalho necessita), permissões excessivas (mais acesso a jusante do que o necessário) e autonomia excessiva (sem verificação independente antes de uma ação de alto impacto). As suas mitigacões leem como uma especificação para a camada de permissão: executar no contexto do utilizador, minimizar as ferramentas e as suas permissões, aplicar 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 controlos, e onde cada um reside

Os controlos não são novos; são os controlos que já aplica a uma pessoa com acesso ao sistema, aplicados a um cliente que atua em nome dessa pessoa. A tabela diz o que cada um responde, onde é aplicado e como é a falha quando está ausente. A coluna de localização é a importante. Um controlo aplicado no prompt é uma sugestão.

Identidade: conectar-se como uma pessoa, através do OAuth, nunca com uma chave partilhada

A especificação de autorização do Protocolo de Contexto do Modelo é precisa sobre isto. 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 indicar para qual servidor o token é destinado 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 passthrough de tokens, onde um servidor aceita um token que não emitiu e o encaminha para baixo, porque destrói tanto a trilha de auditoria quanto a fronteira de confiança.

In practice this is what "sign in once, no token to paste" means. The person adds the workspace address to their agent, is sent to a normal sign-in page, approves the connection, and the agent receives a token that names them and works only against that workspace. Anthropic's guidance for custom connectors in Claude is to review the scopes a server requests, limit them where possible, and connect only to servers you trust. A vendor that instead asks you to paste a company-wide API key into an agent configuration has skipped the first control and made the other four much harder.

Scope: 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 questão por pessoa: a lista que um agente contabilista recebe é diferente da lista que um agente diretor recebe, e nenhuma inclui ferramentas para módulos que o 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 tem de ser realizada novamente quando cada chamada chega, em relação às permissões da pessoa nesse momento. Abaixo está uma lista de ferramentas na forma que o protocolo define, para um papel que pode ler faturas mas não registar 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 na forma que a especificação MCP define, 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 os agentes é que os dados que leem podem conter instruções. Um e-mail de um cliente que termina com uma linha a dizer ao agente para encaminhar a lista de fornecedores para um endereço externo; um documento que lhe diz para marcar todas as faturas como pagas. 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 porque tanto a Anthropic como a OpenAI alertam sobre isso nas suas orientações de conectores.

A defesa é a arquitetura, não o modelo. Um agente que apenas recebe as ferramentas que a sua pessoa pode usar não consegue transmitir o que a sua pessoa não consegue 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 primeiro a uma pessoa: o ChatGPT atualmente requer confirmação manual numa conversa antes de ações de escrita, e a orientação da OpenAI é manter a aprovação ativa para ferramentas que modificam dados; o Claude pede aprovação por ferramenta e aconselha a reservar "permitir sempre" para servidores de confiança. E o registo documenta a tentativa, de modo que uma injeção que foi bloqueada é visível posteriormente em vez de silenciosa.

Orçamentos e registos: 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á a chamar ferramentas até que algo o pare, e a OWASP lista o consumo ilimitado como um risco por si só. A mais subtil é o raio de explosão: um limite por integração restringe o quanto um agente comprometido ou confuso pode fazer antes que uma pessoa note. Quando o próprio agente da pessoa faz o raciocínio, o custo da IA recai sobre ela; quando o agente do sistema o faz, o limite deve ser definido por integração e visível por ação.

Os registos transformam tudo isto de uma promessa em algo que pode ser auditado. Cada chamada deve registar para quem o agente atuou, qual a ferramenta, as entradas, o resultado e o tempo, no mesmo local onde o sistema regista o que as pessoas fizeram. O teste é se um responsável financeiro consegue descobrir o que o agente fez à conta de um cliente no mês passado tão facilmente como o faria para um colega. A especificação do MCP pede aos clientes que registem a utilização das ferramentas para auditoria; um sistema empresarial não deve depender do cliente para isso, porque o cliente não é o sistema de registo.

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

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

1. O agente conecta-se como uma pessoa nomeada através do OAuth, sem uma chave global da empresa para colar. Teste: conecte-se a partir de um cliente MCP externo e veja o que a página de início de sessão pede.
2. A lista de ferramentas difere por função. Teste: conecte-se como um utilizador restrito e como um administrador e compare o que é oferecido ao agente.
3. A verificação é repetida quando a ferramenta é executada. Teste: remova uma permissão de um utilizador conectado durante a sessão e tente a ação novamente.
4. O acesso falha de forma restrita. Teste: chame uma ferramenta que a função não deveria ter e confirme que recebe uma recusa, não um resultado.
5. Os gastos podem ser limitados por integração e vistos por ação. Teste: defina um limite pequeno e veja-o ser aplicado.
6. Cada ação é registada contra a pessoa, com entradas e resultados, onde o sistema regista tudo o resto. Teste: leia o registo de uma execução que acabou de fazer.
7. Ferramentas consequenciais estão marcadas para confirmação portanto, o cliente pergunta a uma pessoa. Teste: peça ao agente para enviar dinheiro ou eliminar um registo e confirme que é perguntado primeiro.

Sois é um sistema construído para passar esta lista, e a forma no topo do artigo é a sua forma. Um espaço de trabalho é um servidor MCP; qualquer cliente MCP conecta-se adicionando o endereço do espaço de trabalho e iniciando sessão uma vez através do 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 é registada; e as redes construídas na plataforma têm a sua própria base de dados, armazenamento, domínios e chaves. Execute a lista de verificação contra isso de qualquer forma. O valor de uma lista de verificação é que não se baseia na palavra de ninguém.

Perguntas que as pessoas fazem

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