Construindo Agentes de IA Seguros: Por Que Prompts de Sistema e Acesso Direto ao DB Quebrarão Seu Aplicativo

Adicionar uma interface de chat de IA a um aplicativo é relativamente simples. Você conecta uma API de LLM, ingere alguns documentos em um banco de dados vetorial e permite que os usuários façam perguntas. No entanto, no momento em que você transita de uma busca somente leitura para um assistente de leitura e gravação que pode alterar dados reais do usuário, os desafios de engenharia mudam completamente.

Se um agente pode enviar e-mails, ajustar faturas ou excluir bancos de dados, você não está mais apenas gerenciando um chatbot. Você está expondo toda a lógica do seu negócio a um tempo de execução imprevisível.

Para construir um sistema agente de qualidade de produção de forma segura, você deve estabelecer limites arquitetônicos rigorosos. Aqui está uma análise aprofundada dos três princípios fundamentais do design seguro de agentes.

1. Nunca Deixe o LLM Bypassar a Camada de Serviço

Quando os desenvolvedores constroem seu primeiro agente de chamada de ferramenta, há uma tentação de dar ao LLM ferramentas diretas e poderosas. Você pode ver ferramentas como execute_sql_query ou update_user_row. Isso é um enorme anti-padrão arquitetônico.

Um LLM nunca deve ter acesso direto ao seu banco de dados ou contornar sua lógica de negócios existente. Em vez disso, o LLM deve ser tratado como um usuário não autenticado ou não confiável que deve direcionar todas as ações através da sua API ou camada de serviço existente.

Se seu backend já possui uma camada de serviço robusta que lida com autenticação, autorização, controle de acesso baseado em função (RBAC) e validação, suas ferramentas de IA devem ser simplesmente envoltórios finos em torno desses pontos finais existentes.

// RUIM: Dando ao agente acesso direto ao DB
const writeQueryTool = {
  name: "update_database",
  description: "Executa uma consulta SQL de atualização arbitrária no banco de dados.",
  execute: async ({ query }) => {
    return db.query(query); // Alto risco de segurança
  }
};

// BOM: Envolvendo a lógica de negócios existente validada
const updateSubscriptionTool = {
  name: "update_billing_tier",
  description: "Atualiza o nível de assinatura de um cliente.",
  execute: async ({ userId, newTier }, context) => {
    // Reutiliza a lógica de negócios existente com RBAC e validação integrados
    const billingService = new BillingService(context.currentUser);
    return await billingService.updateTier(userId, newTier);
  }
};

Ao envolver a lógica de negócios existente, você garante que mesmo que o LLM alucine argumentos ou seja manipulado por um prompt malicioso, ele nunca poderá realizar uma ação que o usuário logado já não esteja autorizado a realizar.

2. Implementando Fluxos de Trabalho de Confirmação Antes da Gravação Seguros Cryptograficamente

Um prompt de sistema que diz "Sempre pergunte ao usuário por permissão antes de chamar a ferramenta transfer_funds" não é um limite de segurança. LLMs podem facilmente contornar essa restrição devido ao desvio de atenção, raciocínio complexo em várias etapas ou prompts de jailbreak.

A única maneira confiável de impor consentimento é tornar as ferramentas mutantes determinísticas. Você deve dividir a execução de ações mutantes em um compromisso de duas fases:

1. Fase 1 (Geração de Intenção): O LLM prepara a carga útil para a ação e a retorna ao aplicativo como uma ação pendente.
2. Fase 2 (Confirmação de Execução): O aplicativo cliente apresenta a carga útil estruturada ao usuário em uma interface segura. Assim que o usuário clicar em "Confirmar", o aplicativo executa a ação diretamente, contornando completamente o LLM para a gravação final.

Aqui está como você pode modelar esse fluxo de trabalho usando uma máquina de estados:

interface PendingAction {
  actionId: string;
  toolName: string;
  arguments: Record<string, any>;
  expiresAt: number;
}

class ActionQueue {
  private pendingActions = new Map<string, PendingAction>();

  // Chamado quando o LLM decide executar uma ferramenta mutante
  public stageAction(toolName: string, args: Record<string, any>): PendingAction {
    const actionId = crypto.randomUUID();
    const pending = {
      actionId,
      toolName,