Seu agente pode fazer deploy. Mas deveria?

SDD, Harness, Agents e Segurança em ambientes Multicloud São 16h52 de uma sexta-feira. Uma vulnerabilidade crítica acabou de ser identificada em uma aplicação em produção. O time precisa agir rápido. Parte da aplicação está rodando na AWS. Alguns workloads estão no Azure. Outros serviços utilizam Google Cloud. Um desenvolvedor pede ajuda para um Agente: Corrija a vulnerabilidade, execute os testes e prepare o deploy. Alguns minutos depois, o Agent responde: “Problema resolvido.” Ótimo. Será mesmo? A pergunta mais importante não é se um Agente consegue alterar código, executar testes, modificar Terraform ou iniciar um pipeline. A pergunta é: Até onde deveríamos permitir que ele vá? Essa é uma discussão que vai muito além de Inteligência Artificial. Estamos falando de arquitetura, segurança, DevSecOps, governança e entrega de software (Software Delivery). E é aqui que conceitos como Spec-Driven Development (SDD), Agents e plataformas como o Harness começam a se conectar. Estamos acelerando a parte errada? Nos últimos anos investimos muito em acelerar o desenvolvimento. - IDE inteligente. - Copilots. - Geração automática de código. - Testes gerados por IA. - Infrastructure as Code. - Pipelines automatizados. Agora chegamos aos agentes. Um agente pode potencialmente: Isso pode aumentar significativamente a produtividade. Mas existe outro lado. Se conseguimos gerar código dez vezes mais rápido, também podemos gerar: - Vulnerabilidades mais rápidas; - Configurações erradas mais rápido; - Infraestrutura insegura mais rápida; - Incidentes mais rápidos. Velocidade sem controles não elimina problemas. Ela apenas reduz o tempo necessário para colocá-los em produção. Por isso, à medida que agentes começam a participar do ciclo de desenvolvimento (Software Development Lifecycle), precisamos mudar a forma como pensamos sobre esse desenvolvimento. Do Prompt para a Spec Durante muito tempo, nosso fluxo foi relativamente simples: Então surgiram os copilots. Agora estamos entrando em outro estágio. Agentes podem receber objetivos e executar várias etapas de forma relativamente autônoma. Nesse cenário, uma instrução como: "Crie o serviço de pagamentos." é insuficiente. Existem dezenas de decisões escondidas nessa frase. - Qual arquitetura utilizar? - Qual banco? - Qual protocolo? - Como os secrets serão armazenados? - Quais bibliotecas são permitidas? - A aplicação pode acessar a internet? - Pode criar recursos de infraestrutura? - Pode alterar IAM? - Qual estratégia de deploy deve utilizar? - Quais controles de segurança são obrigatórios? É aqui que o Spec-Driven Development - SDD passa a ser particularmente interessante. A ideia é simples: Antes de delegar implementação, precisamos tornar explícita a intenção. Podemos imaginar: A Spec pode definir elementos como: application: name: payment-service architecture: style: hexagonal runtime: language: java version: 21 deployment: strategy: canary security: public_database: false secrets_in_code: forbidden privileged_container: false infrastructure: allowed_clouds: - aws - azure - gcp Isso muda completamente a relação entre desenvolvedor e Agente. O prompt deixa de carregar toda a responsabilidade pelo resultado. Existe um contrato. Por isso gosto de resumir SDD desta maneira: Prompt é uma instrução. Spec é um contrato. O agente continua tendo liberdade para resolver o problema. Mas sua liberdade existe dentro de limites conhecidos. Mas Spec não é controle de segurança. Aqui existe uma distinção importante. Imagine que nossa Spec diga: database: public_access: false O agente tenta resolver um problema de conectividade e altera uma regra: 0.0.0.0/0 → TCP 5432 Do ponto de vista operacional, ele resolveu o problema. A aplicação voltou a acessar o banco. Mas agora o PostgreSQL pode estar exposto para a internet. O agente poderia até responder: Connectivity issue fixed successfully. Tecnicamente correto. Arquiteturalmente desastroso. Por isso temos que separar três coisas: A Spec descreve o que queremos. A implementação materializa essa intenção. A Policy determina o que é permitido. Esse último elemento é fundamental. Agente não deve ter autoridade. Existe um princípio que considero essencial para arquiteturas agentic: Agent != Authority Um agente pode ter capacidade de executar determinada ação. Isso não significa que ele deveria possuir autoridade irrestrita para executá-la. Considere: O agente pode solicitar: deploy payment-service version 2.8 Mas a plataforma deve avaliar: - Esse agente pode executar deploy? - Nesse ambiente? - Nessa aplicação? - Essa imagem passou pelos scanners? - Existem vulnerabilidades críticas? - O Terraform atende às políticas? - Existe uma janela permitida para deploy? - Precisa de aprovação humana? - O artefato é o mesmo aprovado anteriormente? Somente depois disso a ação deveria acontecer. É uma mudança importante de mentalidade. Não queremos construir agentes incapazes de cometer erros. Isso provavelmente seria uma expectativa irreal. Queremos construir sistemas em que determinados erros não possam ultrapassar as fronteiras de segurança. Onde o Harness entra nessa arquitetura? É aqui que plataformas de entrega de software (Software Delivery) como o Harness começam a ganhar um papel interessante. Não apenas como: mas como: Podemos imaginar: A própria Harness vem expandindo essa ideia em 2026. Seus agentes de Trabalho Autônomos (Autonomous Worker Agents) podem executar como etapas de pipelines e produzir resultados auditáveis, em vez de operar fora do mecanismo tradicional de entrega. Isso é importante porque evita criar uma segunda realidade. Uma para humanos: E outra completamente diferente para agentes: O segundo modelo deveria nos preocupar. Uma arquitetura mais segura seria: Humanos e agentes utilizam os mesmos controles. - Os mesmos gates. - As mesmas políticas. - As mesmas evidências. - O mesmo Audit Trail. Policy as Code: transformando segurança em algo executável Vamos voltar ao nosso exemplo. O agente tentou expor PostgreSQL: 0.0.0.0/0:5432 Uma policy poderia simplesmente impedir isso. Conceitualmente: Resultado: O Harness disponibiliza Policy as Code baseada em Open Policy Agent - OPA - permitindo centralizar e aplicar políticas sobre pipelines e processos de entrega. Isso permite transformar regras organizacionais em controles executáveis. Em vez de escrever em um documento: Bancos de dados não devem ser expostos publicamente. Podemos fazer a plataforma efetivamente impedir isso. Essa diferença é enorme. Uma política escrita em uma Wiki é documentação. Uma política executada automaticamente é arquitetura. E quando adicionamos Multicloud? Agora nosso cenário fica mais interessante. Imagine que a empresa opere em: É tentador criar três processos diferentes. E, depois de algum tempo: Em seguida: Começamos a multiplicar complexidade. Uma alternativa é separar: O que deve ser comum? - Políticas; - Padrões; - Segurança; - Approval gates; - Audit trail; - Estratégia de deploy; - Observabilidade; - compliance. O que pode variar? A implementação na cloud. Por exemplo: | Capacidade | AWS | Azure | GCP | |---|---|---|---| | Kubernetes | EKS | AKS | GKE | | Identidade | IAM | Entra ID | IAM | | Secrets | Secrets Manager | Key Vault | Secret Manager | | Serverless | Lambda | Functions | Cloud Functions / Cloud Run | | Observabilidade | CloudWatch | Azure Monitor | Cloud Monitoring | Então podemos ter: A plataforma se torna uma camada de consistência. Não precisamos fingir que as três clouds são iguais. Elas não são. O objetivo é manter consistentes os princípios, não necessariamente as implementações. Por isso: Multicloud não significa três processos de entrega. Significa um modelo de governança com múltiplos targets. Agentes mudam também nosso Threat Model Existe outro problema. Um Agente capaz de participar do entrega de software (Software Delivery) pode ter acesso a: - Repositórios; - Pipelines; - Secrets; - APIs; - MCP Servers; - Ferramentas internas; - Sistemas de tickets; - Terraform; - Kubernetes; - Ambientes cloud. Isso significa que precisamos pensar não apenas: O Agente pode realizar esta ação? mas: O Agente deve realizar esta ação? E também: - Sob qual identidade? - Por quanto tempo? - Contra qual recurso? - Com quais credenciais? - Com qual acesso à rede? - Com qual evidência de auditoria? A Harness publicou em 2026 detalhes de como seus Agentes de Execução (Worker Agents) utilizam camadas distintas de isolamento, incluindo hardening de imagem, isolamento de processos, isolamento de secrets e controles de rede. Essa abordagem aponta para uma arquitetura de segurança que deveríamos considerar independentemente da tecnologia utilizada: Ou seja: não basta proteger o que o Agente sabe. Precisamos proteger o que ele consegue fazer. O novo caminho até produção Se juntarmos tudo, nosso fluxo começa a ficar assim: Isso muda nossa discussão sobre produtividade. Talvez a pergunta não seja mais: Quanto código um Agente consegue produzir? Talvez seja: Quanto trabalho conseguimos delegar sem abrir mão de controle? Essa é uma discussão muito mais interessante. Segurança como restrição arquitetural Existe uma ideia que considero fundamental para essa nova geração de sistemas. Durante muito tempo tratamos segurança como uma etapa: Mas, quando Agentes começam a executar ações, segurança precisa aparecer em toda a arquitetura. Segurança deixa de ser apenas: “encontre vulnerabilidades.” E passa a ser também: “limite possibilidades.” Esse talvez seja o principal ponto. Não tente construir um Agente que nunca erre - Agentes vão errar. - Desenvolvedores erram. - Scripts erram. - Pipelines erram. - Configurações erram. A resposta arquitetural não pode depender da expectativa de perfeição. Por isso, gosto de resumir essa arquitetura assim: Cada camada tem uma responsabilidade diferente. Voltando para sexta-feira São agora 17h08. Nosso Agente terminou a correção. Mas, desta vez, o fluxo foi: O patch chegou à produção. Mas isso não é o aspecto mais importante da história