Segurança do agente

A criação de agentes de IA seguros é uma responsabilidade compartilhada entre o Agent Framework e os desenvolvedores de aplicativos. O Agent Framework fornece os blocos de construção — abstrações, provedores e orquestração — mas os desenvolvedores são responsáveis por validar entradas, proteger fluxos de dados e configurar as ferramentas adequadamente para seu cenário.

Este artigo descreve as práticas recomendadas para criar agentes seguros e seguros com o Agent Framework.

Entender os limites de confiança

Os dados fluem por vários componentes quando um agente é executado: entrada do usuário, provedores de histórico de chat, provedores de contexto, serviço LLM e ferramentas de função. Cada limite em que os dados entram ou saem do aplicativo representa uma superfície de ataque potencial.

Principais limites de confiança a serem considerados:

• Serviço de IA — recebe mensagens de chat (que podem incluir PII e instruções do sistema) e retorna a saída gerada por LLM.
• Armazenamento de histórico de chat — os provedores podem carregar e persistir mensagens de conversa por meio do armazenamento externo.
• Serviços de contexto — os provedores de contexto podem recuperar ou armazenar dados de serviços externos (memórias, perfis de usuário, resultados de RAG).
• Serviços acessados por ferramentas – as ferramentas de função executam código fornecido pelo desenvolvedor que pode chamar APIs ou bancos de dados externos.

Toda a comunicação de serviço externo é tratada por SDKs de cliente escolhidos pelo desenvolvedor. O Agent Framework não gerencia detalhes de autenticação, criptografia ou conexão para esses serviços.

Práticas recomendadas

Validar entradas de função

A IA pode chamar qualquer função que você fornecer como uma ferramenta e escolher os argumentos. Trate os argumentos fornecidos por LLM como entrada não confiável, semelhante à entrada do usuário em uma API Web.

• Usar a listagem de permissões – validar entradas em relação a valores bons conhecidos em vez de tentar filtrar padrões conhecidos e ruins. Por exemplo, verifique se um caminho de arquivo está dentro de um diretório permitido, em vez de verificar a presença de sequências de travessia ...
• Impor restrições de tipo e intervalo — verifique se os argumentos são do tipo esperado e dentro de intervalos aceitáveis (limites numéricos, limites de comprimento de cadeia de caracteres, intervalos de data).
• Limitar comprimentos de cadeia de caracteres – imponha o máximo de comprimentos em argumentos de cadeia de caracteres para evitar ataques de esgotamento ou injeção de recursos.
• Impedir traversão de diretório — Quando as funções aceitam caminhos de arquivo, resolvê-los para caminhos absolutos e verificar se estão dentro dos diretórios permitidos.
• Use consultas parametrizadas — se os argumentos forem usados em consultas SQL, comandos de shell ou outros contextos interpretados, utilize consultas parametrizadas ou técnicas de escape — nunca concatenação de strings.

Exigir aprovação para ferramentas de alto risco

Por padrão, todas as ferramentas fornecidas a um agente são invocadas sem aprovação do usuário. Use o mecanismo de aprovação da ferramenta para bloquear operações de alto risco por trás da confirmação humana.

Ao decidir quais ferramentas exigem aprovação, considere:

• Efeitos colaterais – as ferramentas que modificam dados, enviam comunicações, fazem compras ou têm outros efeitos colaterais geralmente devem exigir aprovação.
• Confidencialidade de dados – as ferramentas que acessam ou retornam dados confidenciais (PII, dados financeiros, credenciais) justificam a aprovação.
• Reversibilidade — as operações irreversíveis (exclusão, envio de emails) são de maior risco do que as consultas somente leitura.
• Escopo de impacto — ferramentas com amplo impacto (operações em massa) devem exigir mais escrutínio do que as de escopo restrito.

Manter mensagens do sistema controladas pelo desenvolvedor

As mensagens de chat carregam uma função (system, user, , assistant) toolque determina como o serviço de IA as interpreta. Entender essas funções é fundamental:

Função	Nível de confiança
system	Maior confiança – forma diretamente o comportamento do LLM. Nunca deve conter entradas não confiáveis.
user	Não confiável – pode conter tentativas de injeção de prompt ou conteúdo mal-intencionado.
assistant	Não confiável – gerado pela LLM, que é um sistema externo.
tool	Não confiável – pode conter dados de sistemas externos ou conteúdo influenciado pelo usuário.

Não coloque a entrada do usuário final em mensagens com função system-role. O Agent Framework usa o texto não tipado como padrão para a user função, mas tenha cuidado ao construir mensagens programaticamente.

Provedores de extensão vet

Provedores de contexto e provedores de histórico podem injetar mensagens com qualquer função, incluindo system. Anexe apenas os provedores em que você confia.

Esteja ciente da injeção de prompt indireto: se o armazenamento de dados subjacente estiver comprometido, conteúdo adversário poderá influenciar o comportamento de LLM. Por exemplo, um documento recuperado via RAG pode conter instruções ocultas que fazem com que a LLM se desvie do comportamento pretendido ou exfiltrate dados por meio de chamadas de ferramenta.

Validar e higienizar a saída do LLM

As respostas LLM devem ser tratadas como saída não confiável. O serviço de IA é um ponto de extremidade externo que o Agent Framework não controla. Esteja atento a:

• Alucinação – Os LLMs podem gerar informações plausíveis, mas incorretas em termos de fatos. Não trate a saída do LLM como confiável sem verificação.
• Injeção de prompt indireto — os dados recuperados por ferramentas, provedores de contexto ou provedores de histórico de chat podem conter conteúdo adversário projetado para influenciar a LLM.
• Cargas úteis maliciosas — O resultado do LLM pode conter conteúdo prejudicial se renderizado ou executado sem sanitização (HTML/JavaScript para XSS, SQL para injeção, comandos de shell).

Sempre valide e sanifique a saída do LLM antes de renderizá-la em HTML, executá-la como código, usá-la em consultas de banco de dados ou passá-la para qualquer contexto sensível à segurança.

Proteger dados confidenciais em logs

O Agent Framework dá suporte a registro em log e telemetria por meio do OpenTelemetry. Os dados confidenciais só são registrados quando habilitados explicitamente:

• Registro em log — No nível Trace do log, a coleção completa ChatMessages é registrada em log. Isso pode incluir Informações Pessoais Identificáveis (PII). Trace o nível nunca deve ser habilitado na produção.
• Telemetria – Quando EnableSensitiveData está definida, a telemetria inclui o texto completo das mensagens de chat, incluindo chamadas de função e resultados. Não habilite isso em produção.

Proteger dados de sessão

As sessões (AgentSession) representam o contexto da conversa e podem ser serializadas para persistência. Trate as sessões serializadas como dados confidenciais:

• As sessões podem referenciar o conteúdo da conversa ou os identificadores de sessão.
• Restaurar uma sessão de uma fonte não confiável é equivalente a aceitar entradas não confiáveis. Um back-end de armazenamento comprometido pode alterar as funções para aumentar a confiança.
• Armazene sessões no armazenamento seguro com os controles de acesso e a criptografia apropriados.

Implementar limites de recursos

O Agent Framework não impõe restrições ao comprimento de entrada/saída ou às taxas de solicitação, pois não sabe o que é razoável para seu cenário. Você é responsável por:

• Limites de comprimento de entrada – restringir o comprimento de entrada para evitar estouro de contexto ou ataques do DoS.
• Limites de comprimento de saída — use limites fornecidos pelo serviço (por exemplo, MaxOutputTokens em opções de chat).
• Limitação de taxa de requisições – use mecanismos de limitação de taxa para evitar custos excessivos e o abuso de requisições simultâneas.

Próximas Etapas 

Visão geral das ferramentas

Conteúdo relacionado

• Ferramentas de Funções
• Observabilidade
• Provedores de contexto