DEV Community: Rogério Fontes

Seu agente pode fazer deploy. Mas deveria?

Rogério Fontes — Tue, 06 Oct 2026 20:04:46 +0000

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.

O mais importante é que o Agente conseguiu fazer apenas aquilo que sua arquitetura permitia.

Essa será uma das grandes discussões de arquitetura dos próximos anos.

Não simplesmente:

como utilizar Agentes?

Mas:

como permitir autonomia sem entregar autoridade irrestrita?

Porque, no final:

Agentes aceleram decisões. (Agents accelerate decisions).

A arquitetura os limita. (Architecture constrains them).

A segurança os rege. (Security governs them).

E talvez essa seja a arquitetura que realmente precisamos para o Entrega de Software (Software Delivery) da era dos Agentes.

Segurança na AWS Inicia com como criar identidade: IAM, além de usuários e roles.

Rogério Fontes — Mon, 14 Sep 2026 12:49:28 +0000

Se pensamos em segurança na nuvem, é comum começarmos falando sobre firewalls, criptografia, redes privadas, WAF ou ferramentas de detecção de ameaças.

Mas precisamos pensar algo antes de praticamente todas essas tecnologias:

Quem pode fazer o quê dentro do meu ambiente AWS? Pode parecer um questionamento básico, mas sempre está no centro das decisões de segurança em cloud e não só.

Respondendo a esse questionamento, entra o AWS Identity and Access Management (IAM).

Neste artigo, pretendo ir além da explicação tradicional de usuários, grupos e roles. A ideia é olhar para IAM do ponto de vista de arquitetura e entender como conceitos como least privilege, roles, policies, permission boundaries e temporary credentials ajudam a construir workloads mais seguros na AWS.

1. Segurança geralmente começa com identidade.

Vamos pensar em uma aplicação relativamente simples:

A primeira pergunta de segurança poderia ser:

Como bloquear que alguém, por meio da internet, acesse diretamente o DynamoDB?

Outra pergunta:

Por que a aplicação precisa ter acesso ao DynamoDB?

E mais uma que poderíamos fazer:

Exatamente quais operações essa aplicação precisa executar no DynamoDB?

Ela precisa de:

GetItem
PutItem
UpdateItem

Ou realmente precisa de:

dynamodb:* ?

Essa pequena diferença representa um dos princípios mais importantes de segurança:

Menor Privilégio (Least Privilege)

Uma identidade deve possuir somente as permissões necessárias para realizar sua função.

Nada mais que isso.

2. O problema do (*), quando faz uma policy.

Durante o desenvolvimento e a criação de provas de conceito, é muito tentador criar algo assim:
{
  "Effect": "Allow",
  "Action": "",
  "Resource": ""
}

Isso funciona normalmente, e esse é justamente o "problema".

Quando damos permissão total para resolver rapidamente um problema de acesso, podemos estar criando uma dívida de segurança.

Em um ambiente real, uma aplicação que precisa apenas escrever mensagens em uma fila não deveria ter permissão para excluir filas, criar recursos ou acessar outros serviços.

Podemos começar restringindo:
{
  "Effect": "Allow",
  "Action": [
     "sqs:SendMessage"
  ],
     "Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:orders-events"
}

Agora estamos dizendo algo muito mais específico:
Esta identidade pode enviar mensagens para esta fila.
Essa mudança representa uma evolução importante:

3. IAM não é apenas Users.

Quando começamos a estudar AWS, normalmente conhecemos uma estrutura parecida com:

Isso é útil para aprender os conceitos.

Mas arquiteturas modernas na AWS deveriam depender cada vez menos de credenciais permanentes associadas diretamente a aplicações.

Considere uma aplicação Java executando no ECS.

Uma abordagem problemática seria armazenar:
aws.accessKeyId=...
aws.secretAccessKey=...

Agora temos vários problemas.

Onde armazenamos essas credenciais?
Quem pode vê-las?
Como fazemos rotação?
O que acontece se forem expostas?

4. Prefira credenciais temporárias.

Uma alternativa muito melhor é permitir que o workload assuma uma IAM Role.

Por exemplo:

A aplicação não precisa conhecer uma Access Key fixa.

O ambiente AWS fornece credenciais temporárias associadas à role.

Isso reduz significativamente o risco relacionado ao gerenciamento de credenciais de longa duração.
Para quem trabalha com Java e Spring Boot, isso também muda a forma como pensamos configuração.

Em vez de perguntar:

Onde vou colocar minha AWS_ACCESS_KEY_ID?

A pergunta deveria ser:

Qual identidade este workload deve assumir e quais permissões essa identidade realmente precisa?

Essa é uma pergunta de arquitetura, que sempre podemos fazer.

5. Políticas (Policies) são contratos de autorização.

Podemos pensar que IAM Policy seria como um contrato de autorização.

Ela responde principalmente:

Em uma policy encontramos elementos como:

Effect
Action
Resource
Condition

Por exemplo:
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-secure-bucket/*"
}

A identidade não ganhou "acesso ao S3".

Ela ganhou permissão para:

Executar GetObject nos objetos daquele bucket específico.

Essa diferença de interpretação é fundamental.

6. Identity-based e Resource-based policies

Outro conceito importante é entender onde a autorização está definida.

Uma identity-based policy está associada a uma identidade:

Já alguns serviços permitem políticas associadas diretamente ao recurso.
Por exemplo:

Isso permite construir modelos de autorização mais sofisticados.

O S3 é um exemplo clássico, mas outros serviços AWS também possuem resource-based policies.

Como criadores de arquitetura, precisamos entender não apenas:

Qual policy devo criar?

Um pensamento melhor seria:

Onde essa decisão de autorização deveria existir?

7. Permission Boundaries

Agora chegamos a um conceito muito interessante quando começamos a trabalhar com ambientes maiores.

Imagine que uma organização permita que desenvolvedores criem suas próprias IAM Roles.

Isso oferece autonomia.
Mas também cria um risco.

O desenvolvedor poderia criar:

Uma Permission Boundary permite estabelecer um limite máximo de permissões que aquela identidade poderá receber.

Podemos pensar assim:

A policy pode solicitar determinadas permissões, mas a boundary estabelece até onde elas podem chegar.

Isso é especialmente interessante em ambientes onde queremos combinar:
- Autonomia + governança.

8. RBAC e ABAC

Outro ponto importante de arquiteturas maiores é decidir como as permissões serão organizadas.

Uma abordagem tradicional é o:

RBAC — Role-Based Access Control

Permissões baseadas em funções.

Por exemplo:

Developer
SecurityEngineer
DatabaseAdministrator
Auditor

Mas, conforme o ambiente cresce, administrar centenas de combinações de roles e policies pode se tornar complicado.

É aí que entra:

ABAC — Attribute-Based Access Control

No ABAC, podemos tomar decisões utilizando atributos, frequentemente representados por tags.

Por exemplo:

Project = Payments
Environment = Production
Team = Security

Isso permite criar modelos de autorização mais dinâmicos.
Imagine uma regra conceitual:

Desenvolvedores podem acessar recursos quando a tag Project do recurso corresponde ao projeto associado à identidade.

Agora o modelo pode escalar sem precisarmos criar uma policy diferente para cada novo projeto.

9. IAM é arquitetura.

Esse talvez seja o principal ponto deste artigo.
IAM não deveria ser algo configurado depois que a arquitetura está pronta.

Ele faz parte da arquitetura.
Quando desenhamos:

Deveríamos também desenhar:

Assim começamos a tratar identidade como parte do design do sistema.

10. Um exercício prático

Considere uma aplicação de pedidos.

Ela precisa:

Criar pedidos no DynamoDB.
Publicar um evento em uma fila SQS.
Ler configurações.
Registrar logs. Antes de criar qualquer policy, responda:

DynamoDB
Ele precisa acessar todas as tabelas?

Provavelmente não.

SQS
Ela precisa administrar a fila?

Provavelmente não.

Talvez apenas:

sqs:SendMessage
IAM

A aplicação precisa criar usuários ou roles?

Não.

Credenciais
Precisamos armazenar Access Key e Secret Key?

Se o workload está corretamente integrado com IAM Roles, provavelmente não. O resultado começa a parecer: Isso é least privilege aplicado à arquitetura.

11. O que eu evitaria

Algumas práticas deveriam levantar imediatamente um alerta:
Evite roles com muitos privilégios:

AdministratorAccess, para aplicações. Cuidado, sempre lembre-se do privilégio mínimo.

Evite políticas (policies) com (*):

Action: *
Resource: *

Evite usá-la sem justificativa comprovada.

Evite usar Access Keys armazenadas no código.

Crie credenciais comitadas no Git (vamos fazer como em um próximo artigo).
Usar um Vault, como SecretManager para as credenciais.

Evite uma única IAM Role compartilhada por vários workloads.
Evite permissões adicionadas continuamente sem revisão.

IAM não deveria ser tratado como uma barreira que precisamos remover para fazer a aplicação funcionar. Ele é justamente um dos mecanismos que impedem que uma falha em um componente comprometa todo o ambiente.

Conclusão

Segurança na AWS não começa no firewall.

Ela começa respondendo corretamente:

Quem pode fazer o quê, em qual recurso e sob quais condições?

IAM Users, Roles e Policies são apenas as ferramentas.

Os princípios por trás delas são mais importantes:

Menor privilégio (Least privilege);
Credenciais temporárias;
Separação de responsabilidades;
Autorização explícita;
Redução do blast radius;
Governança.

Para um arquiteto ou mesmo quem está pensando em arquiteturas com segurança primeiro (Security first), portanto, IAM não deveria ser apenas um serviço AWS.

IAM é uma decisão arquitetural.

E essa será justamente a abordagem desta série: não apenas explicar serviços de segurança da AWS, mas entender como eles participam da construção de arquiteturas seguras.

No próximo artigo, vamos aprofundar esse problema:

Designing Least-Privilege Access on AWS

Vamos sair da teoria e construir uma arquitetura real utilizando IAM Roles, Policies e Permission Boundaries, mostrando também alguns erros que podem resultar em privilege escalation.

AWS Security Architecture in Practice — #01
Uma série sobre arquitetura, segurança e construção de workloads seguros na AWS.