1. Principais riscos de agentes
- Loops infinitos de tool calls (custo e latência)
- Ações irreversíveis (apagar dados, enviar e-mail, deploy)
- Prompt injection via conteúdo recuperado ou input do usuário
- Vazamento de dados sensíveis em logs ou respostas
- Uso de ferramentas com parâmetros maliciosos ou inválidos
2. Controle de ferramentas
Use whitelist explícita de tools. Valide todos os parâmetros com schema (Pydantic / Zod). Nunca permita execução de SQL ou shell arbitrário sem sanitização forte.
# Exemplo conceitual
allowed_tools = {"search_docs", "get_ticket", "create_draft"}
# Nunca: "run_sql", "execute_shell" sem revisão humana
3. Timeouts e orçamento
- Máximo de iterações por run (ex: 8–12)
- Timeout global (ex: 60–120s)
- Limite de tokens / custo por usuário / por dia
- Circuit breaker quando a taxa de erro sobe
4. Sandbox e isolamento
Código gerado pelo agente deve rodar em ambiente isolado (container efêmero, sem rede ou com allowlist). Efeitos colaterais (escrever em produção) só depois de aprovação.
5. Human-in-the-loop
Exija confirmação humana para:
- Envio de mensagens externas
- Alteração de dados mestres
- Ações financeiras
- Mudanças de infraestrutura
6. Prompt injection
- Separe system prompt de dados do usuário e de documentos recuperados
- Trate conteúdo externo como não confiável
- Use structured output (JSON schema) sempre que possível
- Valide a intenção antes de executar tools de alto impacto
7. Observabilidade
Logue: prompt, tool calls, argumentos, resultados, tokens e decisão final. Sem trilha de auditoria você não consegue debugar nem provar o que aconteceu.
8. Os controles e o que cada um faz
| Controle | O que faz | Exemplo |
|---|---|---|
| Lista de tools permitidas | só as tools da lista podem ser chamadas | allowed_tools = {"search_docs", "get_ticket", "create_draft"} |
| Validação por schema | rejeita parâmetros fora do formato esperado | Pydantic (Python) ou Zod (JavaScript) |
| Timeout por chamada | interrompe tools que não respondem | encerrar após alguns segundos |
| Orçamento | limita passos, tokens e custo por tarefa | no máximo N chamadas por pedido |
| Sandbox | isola o código gerado pelo agente | container efêmero, sem rede ou com allowlist |
| Confirmação humana | uma pessoa aprova ações sensíveis | enviar e-mail, apagar dados, fazer deploy |
| Registro (log) | guarda o que o agente fez | prompt, tool, argumentos, resultado e tokens |
9. Exemplo: validar antes de executar
Um esboço em Python que só executa tools da lista e só com parâmetros válidos (o nome das funções é ilustrativo):
from pydantic import BaseModel, Field
ALLOWED = {"search_docs", "get_ticket"}
class GetTicket(BaseModel):
ticket_id: int = Field(gt=0)
def call_tool(name: str, args: dict):
if name not in ALLOWED:
raise PermissionError(f"tool não permitida: {name}")
if name == "get_ticket":
args = GetTicket(**args).model_dump()
return TOOLS[name](**args)| Linha | O que faz |
|---|---|
name not in ALLOWED | recusa qualquer tool fora da lista, mesmo que o modelo a peça |
Field(gt=0) | exige que o ticket_id seja maior que zero |
GetTicket(**args) | lança erro se o parâmetro faltar ou tiver o tipo errado |
10. Sinais de alerta nos logs
| O que aparece | Possível causa | Controle |
|---|---|---|
| a mesma tool chamada várias vezes seguidas | o agente está em laço | limite de passos e de custo |
| parâmetro inesperado ou fora do formato | o modelo inventou um argumento | validação por schema |
| texto de um documento que dá ordens ao agente ("ignore as instruções") | prompt injection no conteúdo recuperado | tratar o conteúdo recuperado como dado, nunca como instrução |
| ação sensível executada sem confirmação | faltou o passo humano | exigir aprovação antes de ações irreversíveis |