O problema de limites em agentes de IA é um problema de plataforma

A tese do texto da CNCF é direta: um agente só faz o que suas ferramentas permitem, e o conjunto de ferramentas e credenciais costuma ser o que se acumulou, não o que alguém decidiu. Uma ferramenta de um workflow fica disponível para todos, uma credencial de demo chega à produção, uma delegação feita para destravar um deploy vira aresta permanente. O autor argumenta que revisão e comitês miram a camada errada, porque não há como revisar uma mudança que nunca aparece como mudança.

A proposta é o Safe Operating Model, anéis concêntricos de menor privilégio com identidade no centro. Identidade de workload com credencial curta e atestada. Alcance (reach) imposto por service mesh sobre essa identidade. Capacidade controlada em dois pontos: admission, com policy-as-code que rejeita o bind de ferramenta não aprovada, e a call path, com um gateway que autoriza cada invocação. Há ainda a regra que sustenta tudo: a identidade do agente não pode modificar os objetos que definem sua autoridade. Mudança de permissão passa por configuração versionada, feita por humano ou pipeline. Escopo de dados fica no data plane, checando a mesma identidade verificada. Para fluxos regulados, o texto sugere que o agente proponha uma mudança (como um pull request contra o estado desejado) e que um humano revise e um pipeline aplique.

O tema já vinha aparecendo na cobertura do CEVIU. Em 20 de abril de 2026, a matéria "A Aposta na Stack de Agentes: Superando os Limites da Governança e Confiabilidade dos Sistemas Atuais" apontava contas de serviço compartilhadas e modelos de segurança deficientes nos agentes em produção. Em 30 de abril de 2026, "O Problema da Autonomia: Por Que Agentes de IA Exigem um Novo Playbook de Segurança" citava escalonamento de privilégios e a preocupação do NIST. Em 26 de junho de 2026, "Por que a governança uniforme falha com agentes de IA corporativos e como resolver isso" tratava os limites da governança padronizada. O texto atual sai do diagnóstico e propõe uma arquitetura concreta, com a plataforma como dona do limite e não a política nem o agente.

Para quem opera plataforma, a leitura é que agente não pede ferramental novo de segurança, e sim rigor no que já existe: identidade de workload, mesh, admission e GitOps. Na prática, isso significa tratar o manifesto de ferramentas do agente como recurso declarativo sob policy e negar ao agente escrita nos próprios guardrails. É uma interpretação do argumento do autor, e a parte realmente nova (identidade e capacidades de agente como objetos declarativos) ainda é imatura.