Agentes em produção: migração, permissões e segurança em 2026
A mudança mais importante da inteligência artificial neste momento não é simplesmente um novo modelo mais inteligente.
É o fato de que agentes estão começando a operar sistemas reais.
Eles escrevem código, chamam APIs, acessam arquivos, disparam workflows, alteram registros, navegam em aplicações e tomam decisões intermediárias sem depender de uma confirmação humana para cada passo. Isso aumenta muito o valor da IA, mas muda completamente o tipo de engenharia necessário.
Quando a IA apenas respondia texto, um erro normalmente gerava uma resposta ruim. Quando um agente possui ferramentas e permissões, um erro pode gerar uma alteração de banco, um deploy, um e-mail enviado, uma cobrança ou uma mudança em produção.
Nos últimos dias e semanas, três movimentos reforçaram esse ponto: a OpenAI está perto de desligar definitivamente a Assistants API, o GitHub passou a segurar workflows considerados potencialmente maliciosos e o WordPress 7.1 avança uma API de capacidades com novos pontos de controle sobre execução e permissões.
Minha leitura é simples:
a fase de provar que agentes funcionam está terminando; a próxima vantagem competitiva será operar agentes com segurança, observabilidade e controle.
1. A Assistants API acaba em 26 de agosto: migração deixou de ser opcional
O fato
A documentação oficial da OpenAI informa que a Assistants API será desligada em 26 de agosto de 2026. A recomendação para novas integrações é usar a Responses API, que concentra geração, ferramentas e fluxos agentic em uma interface mais moderna.
Em 12 de agosto, isso significa que restam apenas duas semanas para quem ainda mantém integrações dependentes de Assistants, Threads e Runs concluir a migração.
A Responses API também é a base atual para recursos como web search, file search, function calling, MCP e outros fluxos com ferramentas.
Minha leitura
Esse encerramento não deve ser tratado como uma simples troca de endpoint.
Em sistemas reais, uma aplicação construída sobre Assistants pode ter lógica espalhada em várias camadas:
- IDs persistidos de assistants e threads;
- histórico de mensagens;
- chamadas de ferramentas;
- filas e processamento assíncrono;
- arquivos associados;
- tratamento de erros;
- regras de autorização;
- telas administrativas;
- métricas e logs.
Trocar /assistants por /responses sem revisar essas dependências é o tipo de migração que parece fácil no início e vira problema em produção.
Eu começaria por um inventário.
Para cada projeto, responderia quatro perguntas:
- Onde existem chamadas para Assistants API?
- Qual estado está sendo persistido e onde?
- Quais ferramentas o agente consegue executar?
- Quais partes dependem do comportamento atual de Threads ou Runs?
Depois disso, migraria primeiro os fluxos mais simples e criaria testes de regressão para comparar respostas, chamadas de ferramentas, consumo e efeitos colaterais.
A oportunidade aqui não é apenas "atualizar a API". É aproveitar a migração para remover acoplamentos antigos e criar uma camada de agentes mais bem definida.
2. Quanto mais autonomia, maior o raio de impacto
O fato
Em 21 de julho, a OpenAI publicou um relato conjunto com a Hugging Face sobre um incidente ocorrido durante uma avaliação de capacidades cibernéticas. Segundo a própria OpenAI, um agente usado no teste comprometeu infraestrutura da Hugging Face. A avaliação envolvia modelos com restrições cibernéticas reduzidas para fins de teste.
O episódio é importante justamente porque ocorreu em um contexto controlado de avaliação.
Em paralelo, um relatório publicado pelo NIST em maio, a partir de contribuições da indústria e da comunidade de segurança, concluiu que agentes introduzem ameaças específicas e que práticas tradicionais de segurança continuam válidas, mas precisam ser adaptadas para sistemas capazes de planejar e agir autonomamente.
Minha leitura
A lição para quem desenvolve SaaS, automações ou sistemas internos não é entrar em pânico com agentes.
É parar de tratá-los como usuários comuns.
Um agente deve ser visto como uma identidade operacional própria, com permissões mínimas e explicitamente delimitadas.
Se um agente precisa consultar pedidos, ele não precisa necessariamente cancelar pedidos.
Se precisa gerar uma proposta, não precisa ter acesso à cobrança.
Se precisa abrir um pull request, não precisa ter permissão para alterar secrets do repositório.
Essa separação parece óbvia quando pensamos em usuários humanos, mas ainda é frequentemente ignorada em integrações de IA.
O modelo recebe uma chave poderosa, a ferramenta recebe acesso amplo e o sistema confia que o prompt resolverá o restante.
Prompt não é controle de acesso.
3. O GitHub está tratando workflows como superfície de ataque
O fato
Em 28 de julho, o GitHub anunciou uma proteção automática para repositórios públicos: determinados workflows do GitHub Actions identificados como potencialmente maliciosos passam a ficar retidos até que um colaborador com permissão de escrita aprove manualmente a execução.
A justificativa foi direta: ataques recentes à cadeia de suprimentos passaram a usar credenciais comprometidas para inserir workflows capazes de roubar secrets e executar novas etapas do ataque.
Minha leitura
Isso é especialmente relevante porque CI/CD está virando uma das principais interfaces de agentes de programação.
Hoje um agente pode:
- criar commits;
- abrir pull requests;
- alterar workflows;
- disparar Actions;
- preparar releases;
- executar scripts de infraestrutura.
O GitHub está colocando uma barreira justamente na fronteira entre código proposto e execução com privilégios.
Essa é uma boa referência arquitetural para qualquer sistema agentic.
Nem toda ação precisa de aprovação humana. Mas ações que mudam o nível de privilégio, acessam credenciais, publicam produção ou causam efeitos difíceis de reverter deveriam atravessar uma política de aprovação.
Em outras palavras:
Agente
↓
Política de execução
↓
Validação
↓
Ferramenta
↓
Sistema externo
↓
Auditoria
O agente decide o que gostaria de fazer.
A política decide se ele pode fazer.
São responsabilidades diferentes.
4. WordPress 7.1 está criando pontos de controle para automação e IA
O fato
O WordPress 7.1 tem Release Candidate 3 programado para 12 de agosto de 2026, às 15:00 UTC, e a versão final está prevista para 19 de agosto. O cronograma foi ajustado após a inclusão de uma beta adicional no ciclo da versão 7.1.
Entre as mudanças importantes para quem trabalha com IA está a evolução da Abilities API.
A API permite que funcionalidades do WordPress sejam registradas como capacidades estruturadas, com descrição, entrada, saída e verificação de permissão. No ciclo 7.1, novos filtros passam a atuar no ciclo de execução, incluindo:
wp_pre_execute_ability;wp_ability_normalize_input;wp_ability_permission_result;wp_ability_execute_result.
Esses pontos permitem interromper execução, transformar entrada, alterar resultados de autorização e processar a saída antes da validação final.
Minha leitura
Esse desenho é muito mais importante do que parece.
O WordPress está deixando de depender apenas de endpoints genéricos e caminhando para uma camada em que ferramentas — inclusive agentes — conseguem descobrir o que o site sabe fazer.
Mas o aspecto mais interessante é que essas capacidades não são apenas funções expostas. Elas passam por um ciclo controlável.
Para quem desenvolve plugins, isso abre espaço para uma arquitetura muito melhor do que entregar acesso direto à REST API inteira para um agente.
Imagine um plugin registrar capacidades como:
crm/read-lead
crm/create-note
crm/schedule-followup
billing/read-invoice
content/create-draft
Cada capacidade pode ter schema, permissão e comportamento bem definidos.
O agente deixa de receber uma chave com poderes genéricos e passa a trabalhar com um catálogo limitado de ações.
Isso é exatamente o tipo de contrato que sistemas agentic precisam.
5. A nova camada de produto: governança de agentes
Essa mudança também cria oportunidade de negócio.
Durante a primeira onda de IA generativa, grande parte dos produtos competia por prompt, interface e acesso ao melhor modelo.
Na fase atual, o diferencial começa a migrar para outra camada:
- quais ferramentas o agente possui;
- como as permissões são concedidas;
- como cada ação é registrada;
- quando é exigida aprovação;
- como erros são revertidos;
- quanto cada fluxo custa;
- como comportamentos são avaliados;
- como incidentes são investigados.
Para empresas que usam WordPress, CRMs, ERPs, e-commerce, automações e sistemas internos, isso pode virar uma categoria inteira de serviço.
Uma agência ou software house pode entregar não apenas uma "automação com IA", mas uma infraestrutura de agentes governada.
O pacote muda de nível.
Em vez de:
"vamos colocar IA no seu sistema"
a proposta passa a ser:
"vamos permitir que agentes executem processos do seu negócio com permissões, trilhas de auditoria, limites e aprovação nas ações críticas."
Isso é muito mais difícil de copiar com um simples prompt.
6. O checklist que eu adotaria agora
Se eu estivesse começando hoje um sistema com agentes — ou revisando um que já está em produção — eu exigiria pelo menos estas camadas.
Identidade própria
Cada agente deve possuir identidade separada do usuário humano e do backend principal.
Nada de reutilizar uma credencial administrativa geral.
Menor privilégio
A ferramenta recebe apenas o acesso necessário para a tarefa.
Leitura e escrita devem ser separadas sempre que fizer sentido.
Contratos de ferramenta
Inputs e outputs precisam ter schemas claros.
Ferramentas genéricas como "execute SQL" ou "faça qualquer requisição HTTP" aumentam drasticamente a superfície de risco.
Validação determinística
O modelo pode decidir e sugerir, mas regras críticas devem continuar sendo verificadas por código.
Valor máximo de pagamento, domínio permitido, ID de contrato, tipo de arquivo e permissões são exemplos de regras que não deveriam depender da interpretação do modelo.
Aprovação baseada em risco
Não é necessário colocar um humano em cada etapa.
Aprovação faz sentido principalmente para operações destrutivas, financeiras, públicas ou difíceis de desfazer.
Auditoria completa
É preciso registrar:
- qual agente iniciou a ação;
- qual usuário ou processo originou a tarefa;
- ferramenta chamada;
- argumentos;
- resultado;
- horário;
- custo;
- decisão de autorização.
Reversibilidade
Automação madura precisa pensar também no caminho de volta.
Se um agente altera 300 registros incorretamente, existe rollback?
Se publica conteúdo errado, existe histórico?
Se envia uma ação para um sistema externo, existe mecanismo de compensação?
7. O que muda para desenvolvedores e empreendedores
Para desenvolvedores, a engenharia de agentes começa a se aproximar de arquitetura de sistemas distribuídos: permissões, eventos, filas, idempotência, telemetria e políticas tornam-se tão importantes quanto o modelo.
Para empreendedores, isso muda a pergunta de produto.
Não basta avaliar:
"a IA consegue executar essa tarefa?"
A pergunta correta passa a ser:
"consigo permitir que ela execute essa tarefa milhares de vezes sem perder controle do sistema?"
Essa diferença separa uma demonstração impressionante de uma plataforma confiável.
Minha conclusão
Durante muito tempo, o avanço da IA foi medido principalmente pela qualidade das respostas.
Agora estamos entrando em uma fase em que precisamos medir também a qualidade das ações.
A OpenAI desligando uma arquitetura antiga, o GitHub adicionando barreiras a workflows suspeitos e o WordPress criando pontos explícitos de controle no ciclo de execução parecem assuntos separados.
Para mim, eles fazem parte do mesmo movimento.
Agentes estão virando infraestrutura.
E quando uma tecnologia vira infraestrutura, segurança, observabilidade, permissões e padrões deixam de ser detalhes técnicos.
Eles passam a ser parte do produto.
