Semana passada deixei um agente depurando uma integração contra uma API interna e, ao olhar os logs depois, encontrei ele chamando endpoints que eu não tinha pedido: estava “explorando” o esquema por conta própria, incluindo um DELETE legado deprecado há anos. Não aconteceu nada porque o ambiente era staging, mas a lição é a que a Postman vem repetindo há meses: o problema de segurança com agentes já não é um modelo escrevendo texto estranho — é um agente executando ações contra suas APIs, em velocidade de máquina e sem o julgamento que um desenvolvedor aplica sem perceber.
Se ainda soa estranho um agente atuar como cliente de uma API, comece por o que são servidores MCP.
A Postman publicou essa semana sua abordagem de segurança para a era agêntica e, além do marketing do próprio agente deles, o post acerta num ponto que me parece correto: suas APIs foram desenhadas para consumidores humanos com julgamento implícito, e agentes não têm nenhum. Os números do State of the API Report 2025 deixam isso cru: 89% dos desenvolvedores usam IA generativa todo dia, mas só 24% desenham suas APIs pensando em agentes. Essa lacuna é a sua superfície de ataque.
O caso que eles usam para ilustrar é didático: em 2024, numa grande instituição financeira, os atacantes não derrubaram firewall nenhum; mandaram um e-mail com instruções ocultas que fizeram um assistente de IA aprovar transferências fraudulentas de US$ 2,3 milhões. O agente fez exatamente o que foi projetado para fazer, e a API não notou a diferença. É prompt injection levado do campo do texto para o campo das ações.
Com esse enquadramento, este é o checklist que eu rodaria hoje em qualquer API que vá ser consumida por agentes. Nada de teoria nova: são princípios clássicos de segurança de APIs aplicados a um consumidor que não hesita, não pergunta e não cansa.
1. Inventário: você não protege endpoints que não conhece
O risco API9:2023 Improper Inventory Management do OWASP API Security Top 10 já existia antes dos agentes, mas com eles vira crítico. Um humano que integra sua API lê a documentação; um agente descobre endpoints chamando eles. Cada versão deprecada ainda no ar, cada endpoint de debug esquecido, cada API sombra de um time que não existe mais é uma porta que o agente vai achar por força bruta semântica.
A resposta organizacional é um catálogo vivo: quais APIs existem, quem é o dono, qual versão é suportada e qual é o contrato. A Postman empurra o API Catalog como essa camada de governança — a ideia é o agente operar sobre o que está catalogado e autorizado, não sobre tudo que responde 200 —, mas o princípio vale igual com um Backstage, um portal próprio ou um repositório de specs OpenAPI bem cuidado. Se um endpoint não está no inventário, não deveria estar exposto.
2. Autorização por objeto e por função, não “token válido, acesso total”
Os dois primeiros lugares do OWASP API Security Top 10 2023 são autorização: API1 Broken Object Level Authorization e API5 Broken Function Level Authorization. Com agentes o risco multiplica porque o padrão comum é dar ao agente um token “de serviço” com permissão de sobra “para não quebrar”.
O mínimo razoável:
- Escopos de OAuth no mínimo necessário para a tarefa concreta do agente. Se o agente consulta pedidos, o token dele não precisa de
write:payments, mesmo que “um dia talvez use”. - Autorização no nível do objeto em cada chamada: o token ser válido não significa que ele possa ler o recurso 12345. BOLA é a vulnerabilidade número um de APIs, e um agente iterando IDs explora ela sem querer.
- Separação leitura/escrita no nível da credencial, não da documentação. Se só existe um token admin, o agente vai acabar usando ele para tudo.
3. Aprovação humana para operações que mutam
Aqui está a decisão de design que mais me agrada na abordagem da Postman com o AI Engineer (em beta, disponível no plano gratuito): o agente roda num sandbox na nuvem, sem tocar produção diretamente, e pode investigar, testar, documentar e propor — mas ações que mutam passam por aprovação humana explícita, encaixada no fluxo normal de revisão de PR.
Você não precisa do produto deles para copiar o padrão: se o seu agente pode criar, modificar ou deletar via API, coloque um ponto de aprovação humana nesse caminho. Um agente que prepara a mudança e um humano que assina a execução é infinitamente mais defensável num incidente do que um agente com escrita direta “porque é mais ágil”. A velocidade que você perde no caminho feliz você recupera com folga no dia em que o agente interpretar errado uma instrução.
4. Rate limits e orçamento de consumo por credencial
API4:2023 Unrestricted Resource Consumption e API6:2023 Unrestricted Access to Sensitive Business Flows descrevem exatamente o modo de falha típico de um agente: um loop de retries martelando um endpoint pago, uma “exploração” que baixa metade do catálogo, uma tarefa que chama um fluxo de negócio sensível mil vezes porque o critério de parada estava errado.
Um humano que toma um 429 para e olha o que houve; um agente faz retry com backoff e segue. Por isso os limites têm que morar no servidor, por credencial: cotas de requisições, teto de gasto em endpoints que custam dinheiro (SMS, validações, chamadas a terceiros) e alertas quando uma credencial sai do seu padrão habitual. O rate limiting que “a gente já tinha para o frontend” provavelmente não está dimensionado para um consumidor fazendo 500 chamadas por minuto sem piscar.
5. Segredos fora do alcance do agente
Se o agente (ou a configuração dele, ou os arquivos de contexto) consegue ler uma API key, essa key vai parar num log, num prompt ou num repositório. Duas peças da Postman cobrem isso, e eu verifiquei as duas na documentação:
- Postman Vault: guarda chaves como vault secrets em vez de variáveis em texto claro. O Local Vault está disponível em todos os planos e não sincroniza com a nuvem; o Shared Vault permite compartilhar no nível do workspace, e no Enterprise (com o add-on de Advanced Security Administration) há integrações com 1Password, AWS Secrets Manager, Azure Key Vault e HashiCorp Vault para referenciar segredos sem copiá-los para a Postman.
- Secret Scanner: detecta segredos expostos em coleções, ambientes e documentação publicada, tanto localmente antes de sincronizar (Local Secret Protection) quanto na nuvem (Cloud Secret Detection, que escaneia workspaces públicos por padrão).
O princípio por baixo: o agente trabalha com referências a credenciais, nunca com a credencial em texto claro dentro do contexto dele.
6. Governança na especificação e na CI, não num PDF
Regra de segurança que só vive num documento de estilo não é cumprida por ninguém — e por um agente, menos ainda. A Postman aplica suas regras de API governance diretamente sobre a especificação OpenAPI (3.1, 3.0 e 2.0): você abre a spec no Spec Hub e a aba Issues lista as violações, e nos planos Enterprise dá para definir rulesets próprios e colocar a verificação no pipeline de CI/CD com o Postman CLI, de modo que uma spec que viola as regras quebra o build.
Fazer o contrato exigir esquemas de autenticação definidos, proibir endpoints sem documentar ou respostas que devolvem dado demais, e fazer essa validação rodar sozinha em cada PR, é a diferença entre governar e torcer. Se o código é escrito por um agente, esse controle te interessa em dobro — aliás, para auditar o que o agente faz no seu repositório e na sua CI eu já falei do Ship Safe, que combina muito bem como complemento no lado do código. Se quiser fechar outro vetor da cadeia de suprimentos, o checklist de segurança do npm também vale a pena.
7. Registre tudo o que o agente faz
Quando um agente opera em velocidade de máquina, o log é a única crônica do que aconteceu. Cada chamada autenticada com sua credencial, cada mutação aprovada (quem aprovou, quando, qual diff), cada execução em sandbox com seus artefatos. A ideia da Postman de devolver “artefatos verificáveis” — coleções, resultados de testes, logs de execução, PRs — aponta exatamente para isso: a atuação do agente tem que ser reconstruível depois. Sem esse rastro, um incidente com agente é indistinguível de uma caixa-preta, e a resposta a incidentes vira adivinhação.
Como testar a segurança de APIs com agentes de IA sem arriscar produção
O teste mais barato que você faz essa semana: monte um ambiente isolado com dados sintéticos — um mock server ou um staging bem fechado —, dê a um agente de verdade uma tarefa ambígua contra essa API e observe os logs. Quais endpoints ele descobre, o que tenta mutar, com que frequência tenta de novo. É a versão moderna do pentest, e vai te ensinar mais sobre sua superfície real do que qualquer auditoria estática. Depois, aplique o checklist: inventário, escopos mínimos, aprovação para escritas, limites por credencial, segredos referenciados, governança na CI e logs completos. Nenhum ponto é exótico; todos são urgentes quando o consumidor não é uma pessoa.
Perguntas frequentes sobre segurança de APIs com agentes de IA
O que é segurança de APIs na era dos agentes de IA?
É aplicar os controles clássicos de segurança de APIs (autorização, inventário, rate limiting, gestão de segredos, auditoria) assumindo que o consumidor é um agente autônomo que age em velocidade de máquina, sem julgamento implícito e suscetível a prompt injection. O OWASP API Security Top 10 continua sendo a referência base.
O que é prompt injection e por que afeta as APIs?
É uma técnica que esconde instruções maliciosas no conteúdo que um agente processa (um e-mail, uma página web, um documento). Se o agente tem credenciais para chamar suas APIs, essas instruções podem virar ações reais: transferências, exclusões, vazamento de dados. A defesa passa por escopos mínimos, aprovação humana em escritas e sandboxing.
O AI Engineer da Postman é gratuito?
Está em beta e disponível para usuários do plano gratuito da Postman, segundo a página do produto. As peças de segurança relevantes são a execução em sandbox, a aprovação humana para mudanças e o grafo de contexto das suas APIs. Os recursos avançados de governança (rulesets personalizados, dashboard do Secret Scanner) são dos planos Enterprise.
O que você achou?
Deixe sua opinião, pergunta ou sugestão. Os comentários são sincronizados com GitHub Discussions .