Segurança de dados de agentes de IA: o que acontece quando agentes se conectam a sistemas?

A IA está deixando de gerar apenas respostas e passando a tomar ações em sistemas reais. Essa mudança altera a questão central de segurança. Não basta mais perguntar se o modelo é preciso ou confiável. Também precisamos perguntar como o sistema ao redor se comporta quando o modelo interpreta mal uma instrução, encontra uma entrada maliciosa ou recebe mais autoridade do que a tarefa exige. Protocolos como o MCP facilitam a criação de conexões entre agentes e sistemas; eles também tornam o projeto dessas conexões impossível de ignorar.

Conectar um agente de IA a um sistema empresarial pode expor diferentes categorias de dados a componentes distintos, incluindo o host da IA, o servidor de ferramentas, o provedor de identidade e a aplicação de destino. O MCP define como as partes dessa conexão se comunicam, mas não determina quais dados cada implementação armazena, expõe ou retém.

Das respostas às consequências

Conectar um agente não cria um único limite de confiança. Cria uma cadeia deles: o host da IA interpreta a solicitação, um cliente de protocolo seleciona uma capacidade, um servidor de ferramentas valida e traduz a chamada, um provedor de identidade estabelece quem está agindo e o sistema de destino aplica as permissões e registra o resultado. O MCP padroniza parte dessa comunicação, mas não torna a cadeia completa segura por si só. A segurança depende das decisões tomadas em cada camada.

A primeira geração de IA generativa amplamente usada produzia principalmente coisas para as pessoas revisarem: texto, imagens, resumos e código. Cada vez mais, os agentes operam ferramentas. Eles enviam mensagens, modificam registros, acionam fluxos de trabalho, movimentam dinheiro e controlam processos físicos. Uma resposta plausível, mas incorreta, é inconveniente; uma ação plausível, mas incorreta, pode ter uma consequência imediata.

Padrões como o MCP tornam possível descobrir e chamar ferramentas por meio de interfaces estruturadas. Isso é uma melhoria importante em relação à raspagem de tela ou a integrações improvisadas, mas a estrutura por si só não é uma política de segurança. O projetista da ferramenta continua decidindo quais ações existem, quais entradas elas aceitam, qual identidade usam e que evidências retornam.

Encontramos essa distinção ao construir o servidor MCP da ezeep. A impressão torna a questão tangível porque a decisão de um agente pode se transformar em um resultado físico em segundos. A lição, porém, se aplica a qualquer sistema em operação.

Para onde os dados realmente vão

“O modelo nunca vê sua senha” é uma frase útil, mas não descreve completamente o fluxo de dados. Uma conexão de agente típica envolve várias categorias de informação: credenciais gerenciadas por uma camada de autenticação, argumentos da ferramenta construídos a partir da solicitação do usuário, resultados operacionais retornados ao modelo, dados de negócios transferidos para o serviço de destino e registros retidos por um ou mais componentes. O modelo normalmente recebe a conversa, as descrições das ferramentas disponíveis, os argumentos necessários para chamar uma ferramenta selecionada e o resultado retornado por essa ferramenta.

Essas categorias não seguem necessariamente o mesmo caminho. O OAuth pode manter uma senha e um bearer token fora do contexto do modelo, enquanto o resultado da ferramenta ainda expõe nomes de clientes, a localização dos dispositivos, valores financeiros ou metadados internos do sistema. Um documento pode trafegar diretamente entre os serviços, enquanto seu nome do arquivo, destino e status aparecem na conversa. O host da IA, o servidor de ferramentas, o provedor de identidade e o sistema de destino também podem ter políticas diferentes de registro e retenção.

Portanto, não existe uma afirmação universal e responsável do tipo “a IA não vê os dados”. As perguntas certas são: quais dados cada camada recebe, por que precisa deles, por quanto tempo os retém e se o usuário entende esse limite. Nossa própria implementação do MCP nos fornece exemplos concretos dessas distinções, mas o problema de projeto se aplica a qualquer sistema conectado a agentes.

A identidade determina o raio de impacto

Um agente não deve ter autoridade independente. Um agente pode agir por meio de uma identidade de serviço compartilhada ou em nome de um usuário individual. Nenhum dos modelos é universalmente correto. Uma identidade compartilhada se encaixa em fluxos de trabalho não supervisionados, mas cada ação herda o alcance dessa conta. A autorização por usuário oferece acesso mais restrito e atribuição mais clara, mas exige que cada usuário se autentique e que a aplicação gerencie corretamente as sessões individuais. A interpretação de uma solicitação pelo agente nunca deve substituir a autorização aplicada pelo sistema de destino.

A decisão de engenharia importante não é qual modelo parece mais seguro em termos abstratos. É se a identidade corresponde ao fluxo de trabalho e se suas permissões são mais restritas do que as consequências de um erro. No nosso trabalho com o ezeep MCP, suportamos ambos os modelos porque um serviço automatizado de armazém e um funcionário imprimindo de forma interativa têm requisitos de identidade genuinamente diferentes.

Quem é responsável quando um agente de IA executa uma ação?

Esse é um problema de design de sistema, não apenas de confiança no modelo. Uma arquitetura mais segura combina vários controles: identidades com o mínimo de privilégios, capacidades restritas e tipadas, validação no sistema a jusante, confirmação para ações com consequências, separação entre instruções confiáveis e conteúdo não confiável, e uma trilha de auditoria que mostra o que realmente aconteceu. O escopo limita o dano potencial; observabilidade e atribuição estabelecem responsabilidade após a ocorrência de uma ação.

Projete para reversibilidade

Um teste útil para qualquer capacidade de um agente não é apenas se a ação é permitida, mas o que acontece quando ela está errada. Operações de leitura, mudanças recuperáveis, compromissos financeiros, comunicações externas e administração com potencial destrutivo merecem controles diferentes. Algumas ações devem exigir confirmação. Algumas devem permitir reversão. Outras não devem ser expostas ao agente de forma alguma.

Ao construir o servidor MCP da ezeep, optamos por não expor a exclusão de usuários, grupos ou impressoras, mesmo que existam APIs REST relacionadas. Isso não torna as demais ferramentas inofensivas — a impressão gera saída física e as ferramentas administrativas podem alterar acessos — mas elimina uma classe de erros irreversíveis. O princípio é mais amplo do que impressão: o design da capacidade deve refletir a consequência, não apenas a disponibilidade técnica.

A injeção de prompt pode fazer um agente de IA executar a ação errada?

Sim. Um agente pode encontrar instruções ocultas em documentos, páginas da web, e-mails, chamados de suporte ou resultados de ferramentas. Isso é comumente chamado de injeção indireta de prompt: conteúdo que deveria ter sido tratado como dados tenta, em vez disso, influenciar o que o agente fará a seguir.

Esse risco não pode ser resolvido pedindo ao modelo para "ter cuidado". Conteúdo não confiável não deve poder conceder permissões, alterar o objetivo do usuário, selecionar uma identidade mais privilegiada ou ignorar confirmações. Entradas de ferramentas exigem validação determinística, ações com consequências precisam de verificações de políticas fora do modelo, e fluxos de trabalho sensíveis devem separar claramente instruções confiáveis de material não confiável.

A cadeia de fornecimento de ferramentas também importa. As descrições das ferramentas influenciam o comportamento do modelo, então conectar um novo servidor é, por si só, uma decisão de segurança — não apenas uma configuração de conveniência.

A segurança é decidida em cada camada

Conectar um agente a um sistema real é uma decisão de design tomada em cada camada: quais ações existem, qual identidade elas usam, quais dados cada componente vê, o que pode ser desfeito e o que é registrado. O MCP padroniza parte dessa conversa. O resto cabe às pessoas que constroem a conexão. No servidor MCP da ezeep, isso significou suportar identidades de serviço e identidades por usuário e não expor a exclusão de usuários, grupos ou impressoras. Todo agente eventualmente cometerá um erro, então a conexão precisa ser projetada para esse momento, e foi assim que construímos o servidor MCP da ezeep.

Quer usar o ezeep MCP?

Conecte nosso MCP aos seus agentes hoje.

Teste grátis