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:

READY

O 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.

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 STABLE

Ele 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ção

Ferramentas 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ções

Tudo dentro de um escopo previamente definido.

É quase como testar um programa COBOL.

Quando você cria:

IF SALDO < VALOR-SAQUE
   DISPLAY 'SALDO INSUFICIENTE'
END-IF

um 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
  ↓
REPORT

Vamos 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ÁLISE

Os 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  HTTP

A 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
     ↓
   DADOS

versus:

FERRAMENTA
     ↓
   DADOS
     ↓
    LLM
     ↓
INTERPRETAÇÃO
     ↓
HIPÓTESES

Essa é 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
   ↓
REPLANEJA

Veja a diferença.

Automação tradicional:

A
↓
B
↓
C
↓
D

Você programou previamente a sequência.

Um agente pode fazer:

A
↓
resultado X
↓
B

A
↓
resultado Y
↓
C

A 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
                    |
                  Report

O 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 AUTORIZADO

Mas interfaces modernas permitem imaginar:

LLM
 ↓
AGENT
 ↓
TOOL INTERFACE
 ↓
METASPLOIT

Aqui 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
+
PERMISSIONS

Um 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
   ↓
RESPONSE

A 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 + AI

Em mainframe também veremos cada vez mais:

SMF
RMF
SYSLOG
CICS statistics
Db2 traces
JES

alimentando 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 SECURITY

SECURITY FOR AI

Na 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
  ↓
RESULT

O 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ência

Isso é 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
   ↓
RESPOSTA

Ele adapta sua estratégia.

Portanto:

PROMPT 1
   ↓
RESPOSTA
   ↓
ANÁLISE
   ↓
PROMPT 2
   ↓
RESPOSTA
   ↓
ADAPTAÇÃO
   ↓
PROMPT 3

Isso 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ÇÃO

O 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
 ↓
DEPLOY

Depois acrescentamos:

SAST
DAST
DEPENDENCY SCANNING
SECRET SCANNING

Sistemas 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:

INSTRUCTION

de:

DATA

COBOL 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 natural

Essa ambiguidade abre espaço para prompt injection.

E existe uma versão ainda mais fascinante:

INDIRECT PROMPT INJECTION

Imagine:

USUÁRIO
   ↓
AGENTE
   ↓
SITE EXTERNO

O 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
        ↓
       LLM

Se 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 SOUZA

e 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 RESPONSE

com:

AGENT

ATTACK
 ↓
LLM
 ↓
DECISION
 ↓
TOOL
 ↓
ACTION

Esse ú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 workflow

Por 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
   ↓
DB2

Fantástico.

Uma empresa pode permitir que um agente ajude clientes.

O cliente diz:

"Gostaria de saber como está minha conta."

O agente consulta:

GET /account

CICS 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 /account

E imagine que sua identidade realmente tenha autoridade para isso.

Então:

API ............ OK
RACF ........... AUTHORIZED
CICS ........... OK
COBOL .......... RC=00
DB2 ............ COMMIT

Tudo 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
ADMIN

apenas porque talvez algum dia precise.

Melhor:

AGENT-CONSULTA

READ       YES
UPDATE     NO
DELETE     NO
ADMIN      NO

Outro agente especializado pode ter:

AGENT-ATUALIZACAO

READ       YES
UPDATE     YES
DELETE     NO
ADMIN      NO

E ações críticas:

AGENT
 ↓
PROPOSE ACTION
 ↓
POLICY ENGINE
 ↓
HUMAN APPROVAL
 ↓
EXECUTION

Isso é 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
   ↓
RISCO

E só então:

EXECUTE

Skynet 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 auditing

Agora 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 TOOL

Cada 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ências

Sem memória, ele pode repetir tarefas.

Mas memória cria outro problema:

E se informações maliciosas forem armazenadas?

Agora temos:

INPUT
 ↓
MEMORY
 ↓
FUTURE SESSION

Uma 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 TOOLS

Podemos especializar:

Recon Agent
Web Agent
Cloud Agent
Code Agent
AI Security Agent
Reporting Agent

Um supervisor distribui tarefas.

Isso é poderoso.

Mas cada novo agente adiciona:

identidade
permissões
contexto
comunicação
memória
tools
trust boundary

Ou 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 → sistema

Depois:

2. AI-ASSISTED PENTESTING

Humano → IA → ferramentas → sistema

E finalmente:

3. AI RED TEAMING

Humano/ferramenta → sistema de IA

O 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 bypass

Alguns 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 ONLY

Depois:

SANDBOX

Depois:

LIMITED TOOLS

Depois:

STRICT PERMISSIONS

Depois:

LOG EVERYTHING

E somente após validação considere ações mais sensíveis.

Nunca comece aprendendo com:

AGENT
+
ADMIN
+
PRODUCTION

Isso 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
OWASP

IA não elimina fundamentos.

Ela torna fundamentos ainda mais importantes.

Fase 2 — ferramentas tradicionais

Em laboratório autorizado:

Nmap
Burp Suite
Wireshark

Entenda 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
Promptfoo

Crie aplicações experimentais.

Teste comportamento.

Compare modelos.

Registre resultados.

Fase 5 — agentes

Finalmente:

LLM
 ↓
AGENT
 ↓
TOOL
 ↓
SANDBOX

Observe 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: FALSE

Por quê?

Porque segurança não é simplesmente executar ferramentas.

É compreender:

contexto
impacto
negócio
risco
evidência
falso positivo
prioridade
consequência

Uma 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 risco

A 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 SOFTWARE

Depois precisamos testar a IA:

AI SECURITY → TEST AI

Depois criamos agentes para automatizar isso:

AGENT → TEST AI

Então precisamos verificar o agente:

AI → MONITOR AGENT → TEST AI

T-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ça

Agora 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ça

Ops.

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 indesejada

Não houve rebelião.

Não houve consciência maligna.

Não houve Skynet.

Houve:

BAD DECISION
+
VALID PERMISSION
+
POWERFUL TOOL

Isso basta.

Segurança de agentes não pode depender da esperança de que o modelo sempre raciocine corretamente.

Devemos assumir:

MODEL CAN FAIL

e construir:

BOUNDARIES

ao 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 / LOGGING

Nenhuma 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 + hacker

Agora via um ecossistema completamente diferente:

AI COPILOTS
        ↓
AI AGENTS
        ↓
TOOL ORCHESTRATION
        ↓
AUTONOMOUS WORKFLOWS
        ↓
AI RED TEAMING
        ↓
AGENT SECURITY
        ↓
GOVERNANCE
        ↓
OBSERVABILITY

PentestGPT 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ÇA

O futuro da segurança não será simplesmente:

humano contra máquina.

Provavelmente será algo muito mais interessante:

HUMANO
   ↓
SUPERVISIONA
   ↓
AGENTES
   ↓
OPERAM
   ↓
FERRAMENTAS
   ↓
INTERAGEM
   ↓
SISTEMAS

E 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............. COMPLETE

Ele 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:

READY

Ele 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.

Translate

segunda-feira, 2 de janeiro de 2023