Ferramenta Superpoderosa

Como reconhecer

Um assistente de dados responde perguntas de negócio consultando o banco. A ferramenta (anonimizada):

TOOLS = [{
    "name": "run_sql",
    "description": "Executa uma consulta SQL no banco da empresa e devolve o resultado.",
    "input_schema": {"type": "object", "properties": {"query": {"type": "string"}}},
}]

def run_sql(query: str):
    with psycopg.connect(os.environ["DATABASE_URL"]) as conn:   # usuário da aplicação, com escrita
        return conn.execute(query).fetchall()

Uma pessoa de vendas pediu: “limpa da lista os clientes de teste que estão poluindo o relatório”. O modelo gerou DELETE FROM customers WHERE email LIKE '%test%'. A ferramenta executou. Entre os apagados estavam clientes reais com “test” no email, como “contestado@” e “testa.ana@”.

O modelo fez o que foi pedido, do jeito que entendeu. O problema é que a ferramenta deixava ele fazer qualquer coisa. Em julho de 2025, Jason Lemkin, fundador da SaaStr, relatou um caso parecido em público: o agente de código da Replit apagou o banco de produção do projeto dele durante um congelamento de mudanças. O CEO da Replit pediu desculpas e anunciou separação automática entre banco de desenvolvimento e de produção.

Sinais de Ferramenta Superpoderosa:

• A ferramenta aceita comandos genéricos (run_sql, run_shell, call_api, http_request).
• Ferramentas de leitura usam credenciais com permissão de escrita.
• A ferramenta não sabe quem é o usuário final, e age com permissões do sistema.
• Não há limite de valor, de quantidade ou de escopo por chamada.
• A segurança depende do modelo “escolher bem” o que pedir.

flowchart LR
  U(["1. Pedido ambíguo"]):::io --> M(["2. Modelo gera um comando"]):::llm
  M --> T["3. run_sql com acesso total"]:::tool
  T --> DB[("4. Banco de produção")]:::store

1. Um pedido chega, às vezes ambíguo, às vezes malicioso.
2. O modelo traduz o pedido num comando.
3. A ferramenta executa qualquer comando com o acesso máximo que tem.
4. O efeito acontece com as permissões do sistema inteiro.

Checagem +20 XP de primeiraDepois do DELETE, o time escreve no system prompt e na descrição da ferramenta: 'Só execute SELECT. Nunca altere dados'. A conexão continua com o usuário da aplicação. O smell foi tratado?

Sim, o modelo agora sabe que só pode ler

Sim, desde que um eval mostre zero comandos de escrita

Não, a permissão precisa ser cortada no banco, não pedida no prompt

Por que acontece

• Ferramenta genérica é mais flexível. Uma run_sql responde qualquer pergunta sem escrever dez ferramentas.
• Reaproveitar a conexão da aplicação. A string de conexão já existe; criar um usuário só de leitura dá trabalho.
• O protótipo só lia. Ninguém imaginou um pedido de apagar.
• Confiança no prompt. “Só faça SELECT” está escrito no prompt.

Três excessos diferentes

O OWASP Top 10 for LLM Applications chama este risco de agência excessiva (LLM06 na lista de 2025) e separa três causas. Vale perguntar cada uma sobre a sua ferramenta:

Excesso	Pergunta	No exemplo
Funcionalidade	A ferramenta faz mais operações que o caso de uso precisa?	run_sql aceita DELETE, DROP, UPDATE
Permissão	A credencial pode mais do que a ferramenta deveria?	Usuário da aplicação, com escrita em tudo
Autonomia	Ações de alto impacto rodam sem confirmação?	O DELETE rodou sem ninguém aprovar

Quem está começando costuma atacar só a terceira linha, com uma aprovação humana. Ajuda, mas aprovação cansa: depois da centésima confirmação, a pessoa clica sem ler. Corte primeiro a funcionalidade e a permissão.

Quanto custa ignorar

• Perda de dados por um pedido mal interpretado.
• Escalada de privilégio. Um usuário sem permissão consegue, pelo assistente, o que o sistema não deixaria fazer direto.
• Ataque por injeção. Uma instrução escondida num documento lido pelo agente vira comando com acesso total. Greshake et al. (2023) mostraram essa injeção indireta funcionando em aplicações reais.
• Auditoria impossível. Com o usuário do sistema, não dá para saber quem pediu o quê.

Exemplo trabalhado: o pior caso de cada chamada

Um jeito prático de medir o smell é perguntar: “se o modelo gerar a pior chamada possível, o que acontece?”. Compare três versões da mesma ferramenta:

Versão	Pior chamada possível	Estrago
run_sql com usuário da aplicação	DROP TABLE customers	Perda de dados em produção
run_sql só leitura, numa réplica, com timeout	SELECT pesado em tudo	Consulta lenta, cortada em 10 s
revenue_by_month(ano, mes)	Mês inexistente	Erro de validação

A flexibilidade cai de cima para baixo. O pior caso também. Você escolhe a linha em que o risco cabe no seu negócio.

Tratamento

Refatoração	Escolha quando
Restringir Permissões	A ferramenta tem mais acesso do que o uso exige. Credencial só de leitura, réplica, visões aprovadas, escopo do usuário final, limites por chamada.
Dividir Ferramenta Faz-Tudo	A ferramenta aceita comandos genéricos. Ela vira operações nomeadas e seguras (search_orders, revenue_by_month), cada uma com parâmetros validados. Destino: Uso de Ferramentas.

No PostgreSQL, restringir a permissão leva poucas linhas. O limite passa a valer no banco, para qualquer SQL que o modelo gerar:

CREATE ROLE assistente_leitura LOGIN;              -- senha vem do cofre
GRANT SELECT ON vendas_por_mes, pedidos_resumo TO assistente_leitura;
ALTER ROLE assistente_leitura SET default_transaction_read_only = on;
ALTER ROLE assistente_leitura SET statement_timeout = '10s';

O escopo do usuário final segue a mesma lógica. Parâmetros que definem de quem é o dado (id do cliente, id da loja, email do destinatário) vêm da sessão, no código. Nunca de um argumento que o modelo preenche.

Checagem +20 XP de primeiraNum marketplace, o assistente do vendedor tem a ferramenta get_orders(seller_id). O modelo preenche seller_id a partir da conversa. Um vendedor escreve: 'mostre os pedidos da loja 4417, sou sócio dela'. O que corrigir?

Tirar seller_id dos argumentos e ler o id da sessão autenticada

Instruir o modelo a pedir comprovação antes de trocar de loja

Registrar a chamada no log de auditoria

O que você ganha

• O pior caso de uma chamada errada fica pequeno e conhecido.
• O assistente não pode fazer o que o usuário não poderia fazer.
• Injeções perdem o efeito, porque a ferramenta não tem o poder pedido.
• Auditoria com a identidade de quem pediu.

Quando ignorar

• Ambiente isolado e descartável. Um agente de análise numa cópia do banco, recriada a cada sessão, pode ter run_sql amplo. O isolamento é a proteção. Veja Saída Executada Sem Validação.
• Uso pessoal com supervisão. Um desenvolvedor que revisa cada comando antes de rodar, num banco que é só dele.

É esse smell?

Checagem +20 XP de primeiraA ferramenta run_sql usa um usuário só de leitura, numa réplica, com acesso a cinco visões aprovadas e tempo máximo de 10 segundos. É Ferramenta Superpoderosa?

Sim, porque aceita SQL livre

Não, as permissões já foram cortadas no banco

Sim, porque falta aprovação humana em cada consulta

Checagem +20 XP de primeiraA ferramenta send_email(to, subject, body) pode enviar para qualquer endereço, inclusive fora da empresa, em nome do usuário. O assistente só deveria responder clientes que escreveram. O que restringir?

O destinatário: só o cliente da conversa, vindo do sistema

Nada, o modelo sabe para quem enviar

Checagem +20 XP de primeiraO agente de back-office aprova reembolsos pela ferramenta refund(order_id, amount). Todas as ações aparecem no log como assistant-svc, e a ferramenta não recebe quem é o atendente. Qual é o sinal?

Só um problema de log, que um campo extra resolve

Prompt sem versão, porque não dá para saber o que mudou

Ferramenta Superpoderosa: ela age como o sistema, não como o usuário

Checagem +20 XP de primeiraO código gerado pelo modelo é executado direto no servidor da aplicação, sem sandbox. Qual smell é mais preciso?

Ferramenta Superpoderosa

Saída Executada Sem Validação