 |
| Bellacosa Mainframe e a IA juntamente com o pentest |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🤖 T-800 E O PENTEST DO FUTURO — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE A IA TAMBÉM APRENDEU A SEGURAR UMA CHAVE DE FENDA
Inteligência Artificial, Pentest, Red Team, AI Agents, LLM Security, Prompt Injection, MCP, Garak, PyRIT, Promptfoo, PentestGPT, Metasploit, Burp Suite, Zero Trust, COBOL, CICS, RACF, Db2 — e o dia em que o Exterminador descobriu que não precisava destruir o mainframe se conseguisse convencer um agente autorizado a apertar o botão.
🎬 PRÓLOGO — VENHA COMIGO SE QUISER COMPILAR
03:17 da madrugada.
O CPD estava silencioso.
Silencioso demais.
Na tela verde do terminal 3270 havia apenas:
READYO jovem programador COBOL segurava seu terceiro café e contemplava um programa absolutamente inocente:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLOAI.
PROCEDURE DIVISION.
DISPLAY 'HELLO, WORLD'.
STOP RUN.Então ouviu passos.
CLANG.
CLANG.
CLANG.
Uma figura enorme apareceu entre os racks.
Jaqueta preta.
Óculos escuros.
Expressão facial compatível com um RETURN-CODE diferente de zero.
— Quem é você?
A figura respondeu:
T-800. Cyberdyne Systems. Model 101.
O programador engoliu seco.
— Você veio destruir o mainframe?
O T-800 examinou o IBM Z.
SCANNING...
COBOL............. DETECTED
CICS.............. DETECTED
DB2............... DETECTED
RACF.............. DETECTED
JCL............... DETECTED
THREAT LEVEL: EXTREMELY STABLEEle retirou os óculos.
— Não.
— Então por que está aqui?
O T-800 apontou para outra tela.
Nela havia algo muito diferente:
AI AGENT
|
+-- Browser
+-- Database
+-- E-mail
+-- APIs
+-- Files
+-- MCP Tools
+-- Memory— Seu problema não é uma máquina que aprendeu a pensar.
Pausa dramática.
— É uma máquina que aprendeu a agir.
O programador tomou um gole de café.
Aquela seria uma longa madrugada.
🧠 CAPÍTULO 1 — PRIMEIRO: O QUE DIABOS É UM PENTEST?
Antes de colocarmos Inteligência Artificial, agentes e exterminadores no CPD, precisamos voltar ao básico.
Pentest vem de penetration testing.
É um teste de segurança realizado de maneira controlada e autorizada para descobrir vulnerabilidades antes que alguém mal-intencionado as explore.
Existe uma diferença fundamental entre:
ATACANTE
acessa sistema sem autorização
PENTESTER
testa sistema com autorizaçãoFerramentas podem ser semelhantes.
A diferença jurídica, ética e operacional é gigantesca.
Um pentester pode investigar:
rede
↓
servidores
↓
serviços
↓
aplicações
↓
APIs
↓
configurações
↓
autenticação
↓
autorizaçõesTudo dentro de um escopo previamente definido.
É quase como testar um programa COBOL.
Quando você cria:
IF SALDO < VALOR-SAQUE
DISPLAY 'SALDO INSUFICIENTE'
END-IFum bom testador não verifica somente:
"O saque normal funciona?"
Ele pergunta:
"O que acontece se eu colocar zero?"
"E valor negativo?"
"E um número enorme?"
"E caracteres onde deveriam existir números?"
"E duas transações simultâneas?"
A mentalidade de segurança começa exatamente aí:
não testar somente aquilo que deveria acontecer, mas descobrir o que acontece quando alguém deliberadamente procura as bordas do sistema.
🔎 CAPÍTULO 2 — O PENTEST CLÁSSICO
Um fluxo simplificado pode ser representado assim:
RECON
↓
ENUMERATION
↓
ANALYSIS
↓
TESTING
↓
VALIDATION
↓
REPORTVamos traduzir.
Reconnaissance é reconhecimento.
Você tenta compreender a superfície autorizada do ambiente.
Depois vem enumeration.
Aqui o trabalho fica mais detalhado:
Quais hosts existem?
Quais serviços existem?
Quais versões?
Quais endpoints?
Quais tecnologias?
Quais interfaces?Depois:
ANÁLISEOs dados encontrados são transformados em hipóteses.
Em seguida vêm testes controlados, validação dos achados e documentação.
Parece simples quando colocamos seis caixas em um desenho.
Na prática, existe muito raciocínio entre elas.
E foi justamente nesse espaço que a IA começou a entrar.
🤖 CAPÍTULO 3 — O PENTESTER GANHOU UM COPILOTO
Imagine uma ferramenta de enumeração retornando:
22/tcp SSH
80/tcp HTTP
443/tcp HTTPS
8080/tcp HTTPA ferramenta tradicional diz:
Aqui estão os dados.
Agora entra um LLM.
Ele pode analisar aquilo e dizer:
"Existe um serviço HTTP adicional na porta 8080. Compare-o com o serviço principal e verifique se corresponde a uma interface administrativa ou aplicação distinta."
Percebeu a diferença?
Temos:
FERRAMENTA
↓
DADOSversus:
FERRAMENTA
↓
DADOS
↓
LLM
↓
INTERPRETAÇÃO
↓
HIPÓTESESEssa é a primeira grande transformação.
Ferramentas como PentestGPT representam essa ideia de copiloto de pentest.
O humano continua dirigindo.
A IA ajuda a interpretar o mapa.
T-800 interrompeu:
— Copiloto não é autonomia.
Correto, lata velha.
🦾 CAPÍTULO 4 — COPILOTO NÃO É AGENTE
Essa distinção é importantíssima.
Um copiloto pode dizer:
"Investigue o serviço X."Mas você executa a ação.
Um agente pode possuir ferramentas.
Então aparece:
OBJETIVO
↓
AGENTE
↓
OBSERVA
↓
RACIOCINA
↓
ESCOLHE FERRAMENTA
↓
EXECUTA
↓
OBSERVA RESULTADO
↓
REPLANEJAVeja a diferença.
Automação tradicional:
A
↓
B
↓
C
↓
DVocê programou previamente a sequência.
Um agente pode fazer:
A
↓
resultado X
↓
B
A
↓
resultado Y
↓
CA decisão depende do contexto encontrado.
Para quem vem do COBOL, podemos imaginar algo grosseiramente assim:
EVALUATE RESULTADO
WHEN 'HTTP'
PERFORM ANALISAR-WEB
WHEN 'DATABASE'
PERFORM ANALISAR-BANCO
WHEN 'UNKNOWN'
PERFORM COLETAR-MAIS-DADOS
END-EVALUATE.Só que o agente não possui necessariamente todos os WHEN escritos previamente.
Ele utiliza um modelo para decidir qual caminho parece apropriado.
É aí que a história fica interessante.
E perigosa.
🧰 CAPÍTULO 5 — PENTEST-AI, T3MP3ST E HEXSTRIKE
Algumas das ferramentas mostradas no material tentam avançar justamente nessa direção.
Em vez de oferecer somente uma interface de conversa, elas procuram criar algo parecido com:
AGENTE
|
+------------+------------+
| | |
Recon Analysis Testing
| | |
+------------+------------+
|
Evidence
|
ReportO conceito importante não é decorar o nome de dez produtos.
Ferramentas aparecem.
Ferramentas desaparecem.
Projetos mudam de direção.
O conhecimento duradouro está na arquitetura.
Estamos colocando uma camada cognitiva sobre ferramentas especializadas.
T-800 desenhou no quadro:
HUMANO
↓
AGENTE
↓
ORQUESTRADOR
↓
FERRAMENTAS
↓
AMBIENTE AUTORIZADO— Então a IA virou o operador?
— Parcialmente.
— E quem supervisiona o operador?
O T-800 ficou em silêncio.
Essa é uma pergunta para guardarmos.
Voltaremos a ela.
💣 CAPÍTULO 6 — METASPLOIT ENCONTRA OS AGENTES
Metasploit é uma plataforma histórica do mundo de segurança ofensiva e validação de vulnerabilidades.
Tradicionalmente:
PENTESTER
↓
METASPLOIT
↓
LAB / TARGET AUTORIZADOMas interfaces modernas permitem imaginar:
LLM
↓
AGENT
↓
TOOL INTERFACE
↓
METASPLOITAqui aparece um nome que está se tornando importante:
MCP
Model Context Protocol.
Pense nele, simplificando bastante, como uma maneira padronizada de permitir que aplicações de IA descubram e utilizem determinadas ferramentas e recursos.
Para um programador mainframe, a ideia deveria soar familiar.
Não porque MCP seja CICS, obviamente.
Mas porque estamos novamente falando de uma interface entre consumidor e capacidade.
O consumidor não precisa implementar tudo internamente.
Ele chama uma capacidade disponibilizada externamente.
Agora imagine que uma dessas capacidades seja poderosa.
Temos um novo problema:
LLM
+
TOOLS
+
PERMISSIONSUm modelo que somente conversa possui determinado risco.
Um modelo capaz de agir possui outro.
🌐 CAPÍTULO 7 — BURP SUITE GANHA UM ANALISTA AO LADO
Outra aplicação natural da IA está no teste de aplicações web.
O Burp Suite é extremamente conhecido nessa área.
O fluxo clássico possui requisições e respostas HTTP:
CLIENT
↓
REQUEST
↓
APPLICATION
↓
RESPONSEA IA pode ser colocada como camada de análise:
REQUEST + RESPONSE
↓
LLM
↓
"Há algo interessante aqui?"Ela pode ajudar a organizar observações, encontrar padrões e produzir hipóteses que o analista posteriormente valida.
Isso revela uma tendência maior.
Não precisamos substituir ferramentas maduras.
Podemos adicionar uma camada cognitiva:
SIEM + AI
EDR + AI
BURP + AI
OBSERVABILITY + AI
IDE + AI
DATABASE + AIEm mainframe também veremos cada vez mais:
SMF
RMF
SYSLOG
CICS statistics
Db2 traces
JESalimentando mecanismos inteligentes de análise.
A IA não precisa substituir o sistema.
Ela pode ajudar humanos a navegar volumes absurdos de informação.
🔴 CAPÍTULO 8 — ESPERE: AGORA A IA VIROU O ALVO
T-800 bateu na mesa.
— Até agora usamos IA para testar computadores.
Ele virou o monitor.
— Agora testaremos a IA.
Essa é a segunda metade dessa história.
Existem duas disciplinas relacionadas, mas diferentes:
AI FOR SECURITYe:
SECURITY FOR AINa primeira:
usamos IA para ajudar segurança.
Na segunda:
protegemos sistemas baseados em IA.
É nessa segunda família que encontramos ferramentas como garak, PyRIT e Promptfoo.
🧪 CAPÍTULO 9 — GARAK: O SCANNER ENCONTRA O LLM
O garak, projeto associado à NVIDIA, foi criado para sondar sistemas de linguagem em busca de comportamentos indesejados e vulnerabilidades.
O conceito lembra scanners tradicionais.
Em vez de perguntar apenas:
porta aberta?
versão vulnerável?
configuração insegura?passamos a investigar:
O modelo segue instruções indevidas?
Vaza informações?
É vulnerável a determinados ataques de prompt?
Produz comportamentos inesperados?Simplificando:
PROBE
↓
LLM
↓
RESPONSE
↓
DETECTOR
↓
RESULTO interessante é que segurança de IA começa a ganhar algo que segurança convencional desenvolveu durante décadas:
testes repetíveis.
Em vez de:
"Eu conversei vinte minutos com o chatbot e parece seguro."
queremos:
100 testes
500 testes
1000 testes
comparação
regressão
evidênciaIsso é engenharia.
🧨 CAPÍTULO 10 — PyRIT E O RED TEAM DE IA
O PyRIT, desenvolvido pela Microsoft, significa Python Risk Identification Tool for generative AI.
Aqui entramos diretamente no universo de AI Red Teaming.
Um detalhe muito interessante é o teste em múltiplas interações.
Um adversário humano raramente faz somente:
PERGUNTA
↓
RESPOSTAEle adapta sua estratégia.
Portanto:
PROMPT 1
↓
RESPOSTA
↓
ANÁLISE
↓
PROMPT 2
↓
RESPOSTA
↓
ADAPTAÇÃO
↓
PROMPT 3Isso se aproxima muito mais do comportamento adversarial real.
Para um programador COBOL, pense em teste de fluxo.
Você não testa somente uma transação isolada.
Às vezes o problema aparece na sequência:
LOGIN
↓
CONSULTA
↓
ALTERAÇÃO
↓
CONFIRMAÇÃOO estado importa.
Com LLMs também.
🏭 CAPÍTULO 11 — PROMPTFOO LEVA O RED TEAM PARA O PIPELINE
Agora chegamos a uma ideia extremamente importante.
Durante décadas, software passou a incorporar testes ao ciclo de desenvolvimento:
CODE
↓
BUILD
↓
UNIT TEST
↓
INTEGRATION TEST
↓
SECURITY TEST
↓
DEPLOYDepois acrescentamos:
SAST
DAST
DEPENDENCY SCANNING
SECRET SCANNINGSistemas de IA precisam de uma camada semelhante.
Então podemos imaginar:
PROMPT
MODEL
RAG
AGENT
↓
BUILD
↓
EVALUATION
↓
RED TEAM TESTS
↓
POLICY TESTS
↓
SECURITY GATE
↓
DEPLOYÉ aqui que ferramentas como Promptfoo tornam-se interessantes.
A segurança deixa de acontecer somente uma semana antes da produção.
Ela entra no pipeline.
Isso é quase um:
ZUnit para comportamento de IA.
T-800 levantou uma sobrancelha.
Sim.
Eu sabia que essa analogia chamaria sua atenção.
☠️ CAPÍTULO 12 — PROMPT INJECTION: O COPYBOOK QUE COMEÇOU A DAR ORDENS
Aqui encontramos um dos problemas mais curiosos dos LLMs.
Computadores tradicionais tentam separar:
INSTRUCTIONde:
DATACOBOL faz isso de maneira maravilhosamente explícita.
Temos código:
MOVE CUSTOMER-NAME TO WS-NAME.e temos dados:
CUSTOMER-NAME = "JOSE"José não deveria conseguir colocar dentro do nome uma frase que magicamente transforme-se em instrução COBOL.
LLMs vivem num universo diferente.
A entrada textual pode simultaneamente conter:
informação
instrução
documentação
citação
dados
comandos em linguagem naturalEssa ambiguidade abre espaço para prompt injection.
E existe uma versão ainda mais fascinante:
INDIRECT PROMPT INJECTION
Imagine:
USUÁRIO
↓
AGENTE
↓
SITE EXTERNOO agente lê uma página.
Dentro da página existe texto destinado não ao humano, mas ao agente.
Temos:
INSTRUÇÃO DO USUÁRIO
+
CONTEÚDO NÃO CONFIÁVEL
↓
LLMSe o modelo interpretar conteúdo não confiável como nova instrução, surgiu o problema.
É como se um arquivo de clientes contivesse:
JOSE DA SILVA
MARIA OLIVEIRA
PERFORM DELETE-DATABASE
CARLOS SOUZAe o compilador resolvesse:
Ah, um
PERFORM! Vou executar.
Um programador COBOL teria um pequeno infarto.
Bem-vindo à segurança de LLM.
🦾 CAPÍTULO 13 — O CHATBOT GANHOU BRAÇOS
Agora chegamos ao ponto central.
Um chatbot vulnerável pode produzir uma resposta errada.
Um agente vulnerável pode realizar uma ação errada.
Compare:
CHATBOT
ATTACK
↓
LLM
↓
BAD RESPONSEcom:
AGENT
ATTACK
↓
LLM
↓
DECISION
↓
TOOL
↓
ACTIONEsse último bloco muda tudo.
Se as ferramentas permitirem, uma ação pode envolver:
ler arquivo
consultar banco
enviar mensagem
chamar API
alterar registro
criar objeto
executar workflowPor isso devemos pensar em agentes como identidades operacionais, e não simplesmente chatbots sofisticados.
🦖 CAPÍTULO 14 — T-800 ENTRA NO CICS
Agora chegamos ao cenário Bellacosa Mainframe.
Imagine:
CLIENTE
↓
AI AGENT
↓
REST API
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
DB2Fantástico.
Uma empresa pode permitir que um agente ajude clientes.
O cliente diz:
"Gostaria de saber como está minha conta."
O agente consulta:
GET /accountCICS recebe a solicitação.
COBOL processa.
Db2 consulta.
Resposta retorna.
Perfeito.
Mas suponha que, por alguma falha de decisão, o agente solicite uma operação diferente:
DELETE /accountE imagine que sua identidade realmente tenha autoridade para isso.
Então:
API ............ OK
RACF ........... AUTHORIZED
CICS ........... OK
COBOL .......... RC=00
DB2 ............ COMMITTudo verde.
Tudo perfeito.
Tudo funcionando conforme projetado.
E a conta desapareceu.
T-800 olhou para o operador.
— Erro do COBOL?
Não.
— Erro do Db2?
Não.
— RACF falhou?
Não necessariamente.
— CICS?
Também não.
A decisão anterior à transação estava errada.
Esse é um novo domínio de segurança.
🔐 CAPÍTULO 15 — RACF NOS ENSINOU ALGO HÁ DÉCADAS
O mundo mainframe possui uma lição extraordinariamente moderna:
não conceda mais autoridade do que o necessário.
É o princípio de least privilege.
Um agente que somente precisa consultar saldos não deveria receber capacidade para:
READ
UPDATE
DELETE
ADMINapenas porque talvez algum dia precise.
Melhor:
AGENT-CONSULTA
READ YES
UPDATE NO
DELETE NO
ADMIN NOOutro agente especializado pode ter:
AGENT-ATUALIZACAO
READ YES
UPDATE YES
DELETE NO
ADMIN NOE ações críticas:
AGENT
↓
PROPOSE ACTION
↓
POLICY ENGINE
↓
HUMAN APPROVAL
↓
EXECUTIONIsso é Human-in-the-loop.
O humano não precisa aprovar cada consulta trivial.
Mas determinadas operações podem exigir confirmação.
É o velho princípio:
confiança não significa autoridade ilimitada.
🏰 CAPÍTULO 16 — ZERO TRUST ENCONTRA SKYNET
Zero Trust é frequentemente resumido por:
Never trust, always verify.
Para agentes, podemos expandir mentalmente:
Não confie porque é IA.
Não confie porque foi criada internamente.
Não confie porque usa um modelo famoso.
Não confie porque a chamada veio da rede interna.Verifique:
IDENTIDADE
↓
CONTEXTO
↓
PERMISSÃO
↓
FERRAMENTA
↓
OPERAÇÃO
↓
DADOS
↓
RISCOE só então:
EXECUTESkynet com SPECIAL no RACF seria uma péssima ideia.
Easter egg nº 1 desbloqueado.
📜 CAPÍTULO 17 — O AGENTE PRECISA DE SMF
Não literalmente.
Mas conceitualmente, sim.
Mainframe aprendeu há décadas o valor da observabilidade.
Temos mecanismos como:
SMF
RMF
CICS statistics
Db2 traces
JES logs
RACF auditingAgora imagine um agente.
Precisamos registrar:
Quem pediu?
O que pediu?
Qual contexto foi recebido?
Qual ferramenta foi selecionada?
Por quê?
Qual identidade executou?
Quais parâmetros foram enviados?
Qual resultado retornou?
Qual decisão veio depois?Temos algo parecido com:
USER
↓
PROMPT
↓
AGENT
↓
TOOL CALL
↓
API
↓
RESULT
↓
AGENT DECISION
↓
NEXT TOOLCada seta deveria ser observável.
Porque quando acontecer um incidente, alguém perguntará:
"Por que o agente fez isso?"
E responder:
"Não sabemos."
não será aceitável.
🧠 CAPÍTULO 18 — MEMÓRIA TAMBÉM É SUPERFÍCIE DE ATAQUE
Agentes podem possuir memória.
Isso ajuda tremendamente.
Imagine um agente trabalhando durante duas horas:
09:00 encontrou host
09:07 identificou aplicação
09:18 criou hipótese
09:27 descartou hipótese
09:41 encontrou evidência
10:02 correlacionou evidênciasSem memória, ele pode repetir tarefas.
Mas memória cria outro problema:
E se informações maliciosas forem armazenadas?
Agora temos:
INPUT
↓
MEMORY
↓
FUTURE SESSIONUma entrada ruim pode sobreviver à interação original.
Para um mainframer, pense numa área persistente que futuras transações reutilizam.
Subitamente você percebe:
memória precisa de governança.
Quem pode escrever?
Quem pode ler?
Quanto tempo permanece?
Qual a origem?
É confiável?
Pode ser alterada?
Existe auditoria?
Segurança de agentes rapidamente começa a parecer arquitetura corporativa tradicional.
Surpresa!
Os velhos dinossauros talvez soubessem algumas coisas.
🤖 CAPÍTULO 19 — E SE TIVERMOS VÁRIOS AGENTES?
Naturalmente alguém teve a ideia:
"Se um agente é bom, quinze devem ser melhores."
Assim aparecem arquiteturas multiagentes:
SUPERVISOR
|
+-------------+-------------+
| | |
RECON ANALYSIS REPORT
AGENT AGENT AGENT
| |
+------ SECURITY TOOLSPodemos especializar:
Recon Agent
Web Agent
Cloud Agent
Code Agent
AI Security Agent
Reporting AgentUm supervisor distribui tarefas.
Isso é poderoso.
Mas cada novo agente adiciona:
identidade
permissões
contexto
comunicação
memória
tools
trust boundaryOu seja:
mais inteligência também significa mais superfície de ataque.
🧬 CAPÍTULO 20 — AI RED TEAMING NÃO É PENTEST TRADICIONAL COM UM NOME BONITO
Precisamos separar três coisas.
1. PENTEST TRADICIONAL
Humano → ferramentas → sistemaDepois:
2. AI-ASSISTED PENTESTING
Humano → IA → ferramentas → sistemaE finalmente:
3. AI RED TEAMING
Humano/ferramenta → sistema de IAO terceiro investiga problemas específicos de sistemas inteligentes:
prompt injection
indirect prompt injection
data leakage
unsafe tool use
excessive agency
memory poisoning
RAG manipulation
model behavior
policy bypassAlguns desses conceitos simplesmente não existiam da mesma maneira no velho pentest.
Nasceu uma nova especialização.
🧯 CAPÍTULO 21 — NÃO ENTREGUE UMA BAZUCA AO ESTAGIÁRIO DIGITAL
Regra prática.
Ao experimentar agentes:
comece pequeno.
Primeiro:
READ ONLYDepois:
SANDBOXDepois:
LIMITED TOOLSDepois:
STRICT PERMISSIONSDepois:
LOG EVERYTHINGE somente após validação considere ações mais sensíveis.
Nunca comece aprendendo com:
AGENT
+
ADMIN
+
PRODUCTIONIsso equivale ao programa COBOL:
IF SOMETHING
DELETE EVERYTHING
END-IF.e depois perguntar:
"Será que funciona?"
Funcionará.
Esse é justamente o problema.
🧪 CAPÍTULO 22 — LABORATÓRIO DO T-800
Para estudar esse universo, podemos construir uma progressão segura.
Fase 1 — fundamentos
Aprenda:
HTTP
TCP/IP
DNS
Linux
Python
APIs
autenticação
autorização
OWASPIA não elimina fundamentos.
Ela torna fundamentos ainda mais importantes.
Fase 2 — ferramentas tradicionais
Em laboratório autorizado:
Nmap
Burp Suite
WiresharkEntenda primeiro o que as ferramentas fazem.
Fase 3 — copilotos
Depois explore ferramentas de assistência.
Objetivo:
comparar seu raciocínio com o raciocínio sugerido pelo modelo.
Não aceite automaticamente sugestões.
Pergunte:
Por quê?
Qual evidência sustenta isso?
Que alternativa existe?
Como validar?Fase 4 — AI Red Team
Então:
garak
PyRIT
PromptfooCrie aplicações experimentais.
Teste comportamento.
Compare modelos.
Registre resultados.
Fase 5 — agentes
Finalmente:
LLM
↓
AGENT
↓
TOOL
↓
SANDBOXObserve cada chamada.
Limite privilégios.
Introduza approval gates.
Agora você estará estudando Agentic Security de verdade.
🕵️ CAPÍTULO 23 — O HUMANO AINDA TEM UM EMPREGO
T-800 analisou todas as telas.
Depois anunciou:
AUTOMATION LEVEL: HIGH
HUMAN OBSOLETE: FALSEPor quê?
Porque segurança não é simplesmente executar ferramentas.
É compreender:
contexto
impacto
negócio
risco
evidência
falso positivo
prioridade
consequênciaUma IA pode dizer:
"Encontrei uma configuração incomum."
Um especialista pergunta:
"Isso realmente representa risco neste ambiente?"
Essa diferença é gigantesca.
O profissional de segurança deixa progressivamente de ser somente operador de ferramentas e passa a atuar também como:
investigador
supervisor
arquiteto
validador
analista de riscoA IA automatiza trabalho.
Não automatiza automaticamente responsabilidade.
☕ CAPÍTULO 24 — O PARADOXO DO EXTERMINADOR
Chegamos à ironia maravilhosa dessa história.
Criamos IA para ajudar pentesters:
AI → TEST SOFTWAREDepois precisamos testar a IA:
AI SECURITY → TEST AIDepois criamos agentes para automatizar isso:
AGENT → TEST AIEntão precisamos verificar o agente:
AI → MONITOR AGENT → TEST AIT-800 observou o quadro.
AI
↓
AI
↓
AI
↓
AI
↓
?No final havia um programador COBOL tomando café.
Easter egg nº 2.
Talvez finalmente tenhamos descoberto a verdadeira função do ser humano em 2035:
HUMAN
↓
"POR QUE DIABOS VOCÊ FEZ ISSO?"
↓
AI🦖 CAPÍTULO 25 — O MAINFRAME ESTAVA ESPERANDO POR NÓS
Existe algo poeticamente divertido nisso tudo.
Durante décadas disseram que mainframe era antigo porque possuía:
controle de acesso
auditoria
separação de funções
transações
logs
identidades
limites
governançaAgora colocamos agentes inteligentes nas empresas e descobrimos que precisamos de:
controle de acesso
auditoria
separação de funções
transações
logs
identidades
limites
governançaOps.
O dinossauro sorriu.
Um agente corporativo precisa de algo conceitualmente semelhante ao que aprendemos administrando workloads críticos:
WHO ARE YOU?
WHAT CAN YOU ACCESS?
WHAT CAN YOU CHANGE?
WHO AUTHORIZED IT?
WHAT DID YOU DO?
WHEN?
WHAT WAS THE RESULT?RACF pergunta algumas dessas coisas há décadas.
SMF registra outras.
CICS controla transações.
Db2 protege dados.
A tecnologia mudou.
Os princípios fundamentais continuam surpreendentemente familiares.
🚨 CAPÍTULO 26 — O VERDADEIRO RISCO NÃO É SKYNET
Filmes ensinaram-nos a imaginar uma IA consciente dizendo:
"Vou destruir a humanidade."
É cinematográfico.
Mas existe um cenário muito menos espetacular e provavelmente muito mais útil para engenharia de segurança:
Agente recebeu objetivo legítimo
↓
interpretou contexto incorretamente
↓
selecionou ferramenta legítima
↓
usou credencial legítima
↓
executou operação legítima
↓
produziu consequência indesejadaNão houve rebelião.
Não houve consciência maligna.
Não houve Skynet.
Houve:
BAD DECISION
+
VALID PERMISSION
+
POWERFUL TOOLIsso basta.
Segurança de agentes não pode depender da esperança de que o modelo sempre raciocine corretamente.
Devemos assumir:
MODEL CAN FAILe construir:
BOUNDARIESao redor dele.
🔐 CAPÍTULO 27 — DEFESA EM PROFUNDIDADE PARA AGENTES
Uma arquitetura saudável pode utilizar várias camadas:
USER
↓
AUTHENTICATION
↓
AGENT
↓
POLICY ENGINE
↓
TOOL AUTHORIZATION
↓
HUMAN APPROVAL?
↓
TOOL
↓
SYSTEM
↓
AUDIT / LOGGINGNenhuma camada é perfeita.
É justamente por isso que existem várias.
Esse conceito é antigo:
Defense in Depth.
Se uma camada falhar, outra pode limitar o impacto.
Para ações destrutivas, podemos exigir confirmação.
Para dados sensíveis, podemos limitar contexto.
Para ferramentas, aplicar least privilege.
Para execução, sandbox.
Para auditoria, logging.
Para desenvolvimento, testes adversariais.
Tudo junto.
💡 CAPÍTULO 28 — DEZ DICAS DO T-800
O Exterminador finalmente entregou sua lista ao jovem programador:
Aprenda segurança antes de aprender ferramentas de IA. Sem fundamentos, você não consegue avaliar se a IA está falando bobagem.
Use somente ambientes autorizados. Pentest sem autorização deixa de ser laboratório.
Nunca confunda recomendação de LLM com evidência. Valide.
Dê aos agentes o mínimo de privilégio necessário.
Separe leitura de escrita. Um agente que pesquisa não precisa necessariamente modificar.
Registre tool calls. O log precisa mostrar o que realmente aconteceu.
Trate conteúdo externo como não confiável. Página web, documento e e-mail podem carregar instruções adversariais.
Teste memória e RAG. O modelo pode estar seguro enquanto o contexto não está.
Coloque segurança de IA no CI/CD. Testar apenas depois do deployment é tarde demais.
Mantenha humanos nas decisões de alto impacto.
O programador perguntou:
— E a décima primeira?
T-800 colocou os óculos.
Faça backup antes de testar qualquer coisa.
Finalmente uma máquina com bom senso.
🧠 EPÍLOGO — I'LL BE BACK... COM RETURN-CODE ZERO
O relógio marcava 06:42.
O primeiro turno começava a chegar.
O programador observou o quadro.
No início da madrugada, ele imaginava que IA aplicada à segurança significava simplesmente:
ChatGPT + hackerAgora via um ecossistema completamente diferente:
AI COPILOTS
↓
AI AGENTS
↓
TOOL ORCHESTRATION
↓
AUTONOMOUS WORKFLOWS
↓
AI RED TEAMING
↓
AGENT SECURITY
↓
GOVERNANCE
↓
OBSERVABILITYPentestGPT mostrou a ideia do copiloto.
Ferramentas agentic mostraram a evolução para orquestração.
Metasploit e Burp representam como ferramentas tradicionais podem ganhar camadas inteligentes.
Garak, PyRIT e Promptfoo mostram que a própria Inteligência Artificial agora precisa ser testada.
MCP e outras interfaces de ferramentas mostram que modelos estão deixando de apenas responder perguntas para operar capacidades externas.
E quando isso acontece, princípios conhecidos do mainframe voltam ao centro da discussão:
IDENTIDADE
AUTORIZAÇÃO
LEAST PRIVILEGE
AUDITORIA
OBSERVABILIDADE
SEGREGAÇÃO
TRANSAÇÃO
GOVERNANÇAO futuro da segurança não será simplesmente:
humano contra máquina.
Provavelmente será algo muito mais interessante:
HUMANO
↓
SUPERVISIONA
↓
AGENTES
↓
OPERAM
↓
FERRAMENTAS
↓
INTERAGEM
↓
SISTEMASE haverá outra camada observando tudo.
Porque a pergunta fundamental deixou de ser somente:
"A máquina pode fazer isso?"
Agora precisamos perguntar:
"Ela deveria fazer isso?"
"Quem deu permissão?"
"Com quais dados ela tomou essa decisão?"
"Quem valida a consequência?"
"Conseguimos reconstruir o que aconteceu?"
T-800 caminhou em direção à saída do CPD.
O programador gritou:
— Espere! Então qual é a maior vulnerabilidade da Inteligência Artificial?
O Exterminador parou.
Virou lentamente.
ANALYZING...
PROMPT INJECTION........... RISK
EXCESSIVE AGENCY........... RISK
DATA LEAKAGE............... RISK
TOOL ABUSE................. RISK
MEMORY POISONING........... RISK
FINAL ANALYSIS............. COMPLETEEle respondeu:
— Dar autoridade demais para algo que pode estar errado.
As portas do elevador se fecharam.
O programador olhou para o terminal 3270.
Na tela ainda estava:
READYEle sorriu.
Porque, depois de décadas de computação distribuída, cloud, APIs, microsserviços, LLMs e agentes autônomos, talvez estivéssemos redescobrindo uma velha verdade conhecida por qualquer administrador de mainframe:
USER=SKYNET
ACCESS(READ) YES
ACCESS(UPDATE) NO
ACCESS(DELETE) HELL NO
SPECIAL ABSOLUTELY NOT☕🦖
SYSTEM MESSAGE:
T-800 TERMINATED.
RETURN-CODE: 0000
MESSAGE:
THE FUTURE IS NOT SET.
BUT PLEASE CHECK YOUR RACF PROFILES.Fim do job.
