Tutorial / Implantação / Governança de IA
A Hipótese 3 do nosso raio-x sobre o que o CEO quer da segurança da informação apontava um vácuo real: agentes de IA, bots e service accounts operando com privilégio que ninguém formalmente concedeu. Aqui está o passo a passo para fechar esse vácuo antes que ele vire incidente — ou processo.
Nível: Implantação prática
Público: CISO, TI, Compliance, Jurídico
Pré-requisito: Inventário de sistemas e diretório de identidade existente
Por que "identidade não-humana" virou perímetro
Todo controle de acesso corporativo foi desenhado em torno de uma premissa: existe uma pessoa do outro lado do login. Essa premissa quebrou. Hoje um agente de IA pode abrir chamado, consultar banco de dados, aprovar fluxo, gerar relatório e se comunicar com outro sistema — sem que ninguém tenha preenchido formulário de acesso, assinado termo de responsabilidade ou passado por processo de desligamento quando o projeto acabou.
Isso não é uma falha de ferramenta. É a ausência de um processo formal de ciclo de vida para um tipo de identidade que a maioria das políticas de segurança brasileiras simplesmente não prevê ainda. O objetivo deste tutorial é fechar esse vácuo com um processo replicável, não com mais uma licença de software.
Atenção: antes de qualquer ferramenta, o problema aqui é de processo e responsabilidade. Comprar uma plataforma de gestão de identidade não resolve nada se ninguém for dono do ciclo de vida do agente.
O passo a passo
Passo 1 — Descoberta (encontre o que você não sabe que existe)
Faça o inventário de identidades não-humanas em produção
Antes de governar, é preciso enxergar. Levante, sistema por sistema, toda credencial que não pertence a uma pessoa física: chaves de API, service accounts, tokens OAuth de integração, webhooks, copilotos plugados em ferramentas de produtividade, agentes autônomos e bots de automação (RPA). Cruze três fontes: o diretório de identidade (Active Directory / Azure AD / Okta), os logs de acesso das plataformas SaaS críticas, e o cofre de segredos (secrets manager), se existir.
Em paralelo, rode uma varredura de Shadow AI: pergunte a cada gestor de área, por escrito, "quais ferramentas de IA sua equipe usa hoje que não passaram pela aprovação de TI?". A resposta honesta costuma revelar mais do que qualquer scanner técnico.
Por que isso importa: pesquisas com CISOs de grandes empresas mostram que a maior parte das identidades de IA hoje em produção nunca passou por aprovação formal — elas simplesmente apareceram junto com a adoção orgânica de ferramentas.
Passo 2 — Classificação (nem toda identidade carrega o mesmo risco)
Classifique cada identidade não-humana por criticidade de acesso
Construa uma matriz simples com três eixos: o que o agente acessa (dado pessoal, dado financeiro, propriedade intelectual, sistema operacional crítico), o que ele pode fazer (só ler, ou também escrever/executar/aprovar) e quem é o dono humano responsável por aquele agente dentro da organização. Todo agente sem dono humano identificado entra automaticamente na categoria de risco mais alta até ser regularizado.
Nível 1 — Leitura de dado público / interno não sensível
Nível 2 — Leitura de dado sensível ou pessoal (LGPD)
Nível 3 — Escrita/execução em sistema operacional
Nível 4 — Aprovação financeira, jurídica ou decisória
Nível 5 — Acesso irrestrito / privilégio administrativo
Por que isso importa: sem classificação, toda a governança vira burocracia genérica aplicada igualmente a um bot de FAQ e a um agente com acesso a folha de pagamento — o que garante que ninguém leve a política a sério.
Passo 3 — Menor privilégio (corte o que sobra)
Aplique privilégio mínimo e segregação de função também para agentes
Nenhum agente de IA deveria ter, por padrão, mais acesso do que a tarefa específica exige. Revogue permissões herdadas "por conveniência" no momento da criação e substitua credenciais compartilhadas por credenciais únicas e escopadas por agente — nunca uma chave de API genérica reutilizada em cinco automações diferentes. Sempre que possível, separe o agente que lê dado do agente que age sobre esse dado.
Por que isso importa: a maior parte dos incidentes envolvendo automação não vem de invasão externa — vem de um agente que tinha permissão de sobra sendo usado (por erro ou por ataque) fora do escopo para o qual foi criado.
Passo 4 — Ciclo de vida formal (nasce, muda, morre)
Trate cada agente como um funcionário com admissão, mudança de cargo e desligamento
Formalize três momentos obrigatórios: provisionamento (todo novo agente exige solicitação registrada, dono humano nomeado e justificativa de acesso), revisão periódica (a cada 90 dias, o dono confirma por escrito que o agente ainda é necessário e que o escopo de acesso continua correto) e desligamento formal (quando o projeto termina, o time muda ou a ferramenta é substituída, a credencial é revogada no mesmo dia — não "quando alguém lembrar").
Por que isso importa: a maioria das credenciais comprometidas em incidentes reais não são credenciais ativas sendo mal usadas — são credenciais de projetos encerrados que ninguém desligou.
Passo 5 — Monitoramento contínuo (comportamento, não só acesso)
Monitore o comportamento do agente, não apenas se ele tem permissão
Ter acesso autorizado não significa comportamento normal. Estabeleça uma linha de base de comportamento esperado para cada identidade não-humana (volume de chamadas, horário de execução, escopo de dado tocado) e alerte sobre desvios: um agente que normalmente consulta 200 registros por dia e de repente consulta 40 mil merece investigação, mesmo estando dentro da permissão técnica que possui.
Por que isso importa: em ataques que sequestram credenciais legítimas, o comportamento anômalo costuma aparecer semanas antes de qualquer alerta tradicional de segurança disparar.
Passo 6 — Auditoria e evidência (documente para o Jurídico e o Conselho)
Produza evidência formal de que o processo existe e está sendo seguido
Mantenha registro auditável de cada decisão: quem aprovou o acesso, quando foi revisado pela última vez, e quando foi revogado. Esse não é um exercício burocrático — é exatamente o tipo de evidência de diligência prévia que protege administradores de responsabilização pessoal em caso de incidente, sob a LGPD e sob o Marco Civil da Internet.
Por que isso importa: em qualquer investigação pós-incidente, a pergunta decisiva não é "o ataque foi sofisticado?" — é "a organização conseguia demonstrar controle sobre quem/o que tinha acesso ao dado comprometido?".
Matriz de responsabilidade sugerida
| Etapa | Responsável sugerido | Frequência |
|---|
| Descoberta e inventário | TI / Segurança da Informação | Contínua, com varredura formal trimestral |
| Classificação de risco | Segurança da Informação + área de negócio dona do agente | No provisionamento e a cada mudança de escopo |
| Aprovação de acesso | Gestor da área + Segurança da Informação | No provisionamento |
| Revisão de privilégio | Dono humano do agente | A cada 90 dias |
| Desligamento | TI, mediante confirmação do dono | Imediato ao fim do uso |
| Auditoria e evidência | Compliance / Auditoria interna | Semestral |
O que isso significa sob a lei brasileira
Base legal para justificar o investimento internamente
- LGPD — um agente de IA com acesso não governado a dado pessoal é, na prática, um ponto de tratamento de dado sem controlador claro, o que agrava a responsabilização em caso de incidente.
- Marco Civil da Internet — a guarda de registros de acesso e uso precisa contemplar também identidades não-humanas, sob pena de lacuna probatória em investigação futura.
- Resolução BCB nº 493/2025 — para empresas do setor financeiro, gestão de risco cibernético de terceiros e de automações já é exigência regulatória explícita, não boa prática opcional.
Checklist rápido de implantação
- Inventário completo de identidades não-humanas concluído e validado com gestores de área
- Matriz de classificação de risco aplicada a cada agente identificado
- Todo agente sem dono humano nomeado foi regularizado ou desativado
- Processo formal de provisionamento e desligamento documentado e comunicado
- Linha de base de comportamento estabelecida para agentes de risco alto
- Evidência de revisão periódica armazenada para consulta de auditoria e Jurídico
Quer um diagnóstico da exposição real da sua empresa?
RDS conduz levantamento de identidades não-humanas, due diligence digital e produção de evidência técnico-jurídica para blindagem de Conselho, Compliance e Jurídico — atendimento 100% virtual, sem deslocamento.
Uma produção de RDS @RDSWEB — inteligência cibernética, OSINT e investigação digital defensiva. Acompanhe também no Facebook OSINT Brasil.
Entrar
