Seu copiloto de SaaS está vazando dados: construa um kill‑switch de exfiltração agora

Uma caixa de busca para achar tudo o que você sabe — e uma consulta de distância de vazar tudo o que você não deveria. O recente susto de exfiltração do Atlassian Rovo não foi um caso bizarro; é o desfecho lógico de colar modelos de linguagem de grande porte em conectores cross‑SaaS e chamar isso de “produtividade”. Se você toca uma startup ou uma scale‑up, já tem 10–25 sobreposições de IA em jogo — Copilot disso, Q&A daquilo — muitas habilitadas por admins de negócio bem‑intencionados. Seu DLP e as suposições de “menor privilégio” deixam de se aplicar quando um indexador do fornecedor varre sua organização e um modelo responde através de silos.

Este post oferece um playbook operacional, direto: trate copilotos de SaaS como integrações não gerenciadas, capazes de fluxo de dados entre fronteiras. Construa um kill‑switch nos planos de identidade, rede e conteúdo, e treine isso trimestralmente. Se você não consegue impedir que um copiloto leia um espaço sensível do Confluence em menos de 15 minutos, você não o controla — ele controla você.

O que mudou: copilotos colapsaram seus limites de confiança

Controles tradicionais assumiam três separações:

• Limites de aplicativos: Jira não é Confluence, Drive não é GitHub.
• Escopos de usuário: Alice pode ler os projetos do Time A, não do Time B.
• Localidade dos dados: o conteúdo fica no app onde foi criado.

Copilotos cross‑SaaS apagam as três:

• Conectores e indexadores operados pelo fornecedor varrem múltiplos silos, frequentemente com contas de serviço que enxergam mais do que qualquer humano.
• RAG mistura resultados no momento da resposta, então “uma resposta prestativa” pode citar um post‑mortem interno que Alice nunca deveria ver.
• Caches, embeddings e traces persistem fora do seu tenant, muitas vezes com semânticas vagas de retenção e exclusão.

É por isso que uma sobreposição de IA pode vazar mesmo quando seus apps base estão corretamente permissionados. O modo de falha não é um único ACL; é agregação sem governança.

Uma taxonomia simples de risco para copilotos

Classifique o que você já tem antes de desenhar controles:

• Nível 1 — Assistentes no aplicativo (menor risco): Recursos de IA atrelados a um único produto e às suas permissões (por exemplo, “resumir este issue do Jira”).
• Nível 2 — Busca entre silos (médio/alto): Sobreposições que indexam múltiplos produtos (Confluence, Drive, Slack, GitHub) e respondem através deles. É aqui que vivem RAG + conectores.
• Nível 3 — Agentes que executam ações (alto/crítico): Sistemas que leem amplamente e também criam/modificam recursos (abrir tickets, fazer push de código, atualizar o CRM). Combinam risco de exfiltração com escritas destrutivas.

Sua postura padrão deve ser supor que copilotos Nível 2/3 estão presentes salvo prova em contrário. Em 2026, é raro encontrar menos de 6–12 conectores habilitados em uma organização de engenharia de 200–500 pessoas.

O modelo de controle do CTO: plano de requisições, plano de dados, kill‑switch

Você precisa de controles em três lugares:

• Plano de requisições: Quem pode invocar o copiloto, quais tokens ele possui e que escopos pode solicitar sob demanda.
• Plano de dados: O que o copiloto (e seu fornecedor) pode de fato indexar, armazenar em cache, criar embeddings e recuperar; por quanto tempo os dados vivem e onde.
• Kill‑switch: Um método cronometrado e treinado para cortar o acesso em minutos via revogação de identidade, bloqueios de egress na rede e desligamento no fornecedor.

Passo 1 — Faça inventário do que você realmente tem (2 semanas)

Você não governa fantasmas. Comece com a telemetria que já possui:

• Logs de DNS e proxy: Puxe os últimos 30–90 dias. Espere ver chamadas para api.openai.com, *.anthropic.com, gemini.googleapis.com, bedrock.*.amazonaws.com e uma longa cauda de endpoints de LLM de vendors.
• Concessões de OAuth: Exporte logs de consentimento de apps corporativos do seu IdP (Okta/Azure AD). Ordene por escopos como read:all, files:read, wiki:read, repo:read, audit:read.
• Configs de conectores: Em Jira/Confluence, Slack, Google Workspace, GitHub e Drive, enumere apps do marketplace com “index”, “assist” ou “search” nas descrições. Documente se usam conta de serviço ou tokens em nome do usuário (OBO).
• Consoles de admin dos fornecedores: Para copilotos que você adquiriu deliberadamente, capture residência de dados, retenção e configurações de escopo de conectores. Se você não conseguir encontrá-las, isso já é um achado por si só.

Pontue cada copiloto pelo raio de impacto: número de conectores × escopo máximo × retenção. Qualquer coisa com contas de serviço e indexação entre silos é vermelho.

Passo 2 — Corrija identidade primeiro: escopos, JIT e OBO (2–3 semanas)

Erros de identidade são o motivo pelo qual copilotos veem mais do que seus admins imaginam.

• Elimine contas de serviço com leitura global. Substitua por tokens em nome do usuário (OBO) atrelados a grupos gerenciados por SCIM. Se o fornecedor não consegue fazer OBO, ele não recebe escopos amplos.
• Expansão just‑in‑time (JIT) para pilotos. Crie grupos temporários (por exemplo, “Copilot‑Confluence‑Pilot”) com validade de 7–14 dias. Vincule o acesso do fornecedor a esses grupos; revogue por padrão.
• Tokens de prova de posse (Proof‑of‑possession/DPoP) onde suportado. Vincule tokens ao cliente para reduzir replay.
• Consentimento por conector. Nada de escopos “ler tudo no Drive”. Use drive.file ou permissões por pasta. Para Confluence, vincule a spaces; para GitHub, a orgs/repos específicos.
• Gire concessões trimestralmente. Expire consents a menos que sejam explicitamente re‑aprovados. Automatize via políticas do IdP.

Espere uma queda de 10–20% no “fator uau” dos demos quando você remover escopos globais. É um trade‑off aceitável para não vazar as atas do seu conselho.

Passo 3 — Coloque a rede de volta no comando (2 semanas)

Você não vai descriptografar cada fluxo TLS, mas pode controlar para onde o tráfego de IA vai.

• Allowlists de egress para destinos de IA. Use Cloudflare Gateway, Zscaler ou seu secure web gateway atual para permitir apenas endpoints de LLM avaliados e domínios de vendors de copilotos conhecidos. Bloqueie por padrão o acesso curinga a novos endpoints de IA.
• SNI e IP pinning para tráfego de vendors. Onde os vendors publicarem faixas de IP, restrinja de acordo. Isso não vai impedir todos os pivôs de SaaS, mas reduz a superfície de ataque.
• Política de split‑tunnel. Force dispositivos corporativos a passarem pelo gateway; detecte e bloqueie logins de contas pessoais nos mesmos domínios de copilotos a partir de IPs corporativos.
• Limites de taxa e tamanho. Exfiltração adora volume. Limite taxas de requisição e tamanhos de resposta para endpoints de IA a limites razoáveis; alerte em picos.

Política de rede é seu kill‑switch mais rápido: uma regra de deny vence a busca em 12 consoles de admin separados.

Passo 4 — Higiene de conteúdo na borda (3–4 semanas, em paralelo)

Se você precisa indexar, higienize antes. Não confie que redatores do lado do fornecedor entendam seus dados.

• Proxy de redação pré‑conector. Insira um serviço leve entre o crawler do fornecedor e suas fontes usando os webhooks/hooks de fetch disponíveis. Redija/mascare de forma determinística classes de alto risco: chaves de API, segredos, SSNs, números de conta bancária, e‑mails de clientes, termos de saúde que você sabe que acionam escopo regulatório.
• Redação estruturada + com modelo. Use regex simples e validadores de checksum para formatos óbvios; complemente com um pequeno modelo local para classificar parágrafos sensíveis (nomes de clientes, features de roadmap). Garanta que a redação seja determinística e reprodutível; registre os hashes de antes/depois.
• Blocklists no lado do tenant. Mantenha uma denylist de spaces, drives, repos e canais do Slack que nunca devem ser indexados. Negue por padrão qualquer coisa rotulada como “legal”, “exec”, “finance” ou “security”.
• TTL em embeddings e caches. Exija que vendors respeitem retenção de 7–30 dias para embeddings e logs de conversas. Se não puderem configurar, faça disso um aditivo contratual ou reduza o escopo.

Sim, a redação degrada a qualidade das respostas. Esse é o ponto. Você quer respostas seguras por padrão, respostas profundas por solicitação explícita.

Passo 5 — Auditoria de recuperação, honeytokens e exercícios (2–3 semanas)

Assuma que algo vai escapar. Você precisa detectar e interromper rápido.

• Logs de recuperação. Para cada resposta, registre os URIs de origem (space/page/file/repo) e o usuário que chamou. Armazene por 90 dias. Se um fornecedor não consegue expor isso, ele não está pronto para enterprise.
• Honeytokens e canários. Plante uma string secreta única e não pública em um space/repo excluído. Alerta se ela aparecer em respostas ou sair da sua rede via logs de egress.
• Exercícios trimestrais de kill‑switch. Simule um vazamento: dispare uma detecção, acione o bloqueio de rede, revogue o consentimento no IdP e solicite a pausa do crawler do fornecedor. Meça o MTTR até contenção (<15 minutos) e erradicação completa (<24 horas).

Opcional, mas poderoso: envolva fornecedores no seu próprio broker

Se você for grande o suficiente para justificar, insira um serviço broker na frente de copilotos de terceiros:

• Wrapper de OAuth. Faça os fornecedores se autenticarem no seu broker, que então troca tokens OBO de curta duração para cada fonte. Centralize consentimento, rotação e revogação.
• Política como código. Codifique quais grupos podem consultar quais conectores, em que horário e de quais dispositivos. Negue por padrão; registre todas as decisões.
• Redação inline e marca d’água. Aplique sua sanitização centralmente e incorpore marcas d’água invisíveis para rastrear vazamentos.

Isso adiciona uma ou duas semanas à implementação, mas se paga em controle e auditabilidade.

O que exigir dos fornecedores

Não aceite “confie em nós, não treinamos com seus dados” como postura de segurança. Seu checklist de RFP/renovação deve incluir:

• Suporte a OBO e escopo por conector. Nada de contas de serviço globais.
• Residência e retenção de dados configuráveis (máx. 7–30 dias) para embeddings, caches e logs.
• Trilhas completas de recuperação por resposta (URIs, timestamps, identidade do usuário, versão do modelo).
• Pausar/retomar indexação via API e garantias de hard delete com evidências.
• SOC 2 Tipo II com escopo cobrindo explicitamente o pipeline de indexação e recuperação de IA, não apenas o web app.
• Endurecimento contra prompt injection em crawlers e filtros de recuperação; divulgação das mitigações.
• SLA de incidentes que trate recuperação não autorizada como incidente de segurança com obrigações de notificação.

O plano de kill‑switch de exfiltração em 30‑60‑90 dias

Dias 0–30: Congele, descubra e reduza o escopo

• Imponha um congelamento temporário em novas instalações de copilotos/conectores. Explique o porquê.
• Conclua o inventário: egress de DNS/proxy, concessões no IdP, apps do marketplace. Classifique em Níveis 1–3.
• Remova contas de serviço com leitura global. Converta para OBO ou restrinja o escopo a grupos piloto com validade de 14 dias.
• Ative allowlisting de rede para endpoints de IA. Comece com bloquear tudo; permita apenas os 3–5 destinos em que você confia explicitamente.
• Estabeleça uma denylist de spaces/repos/drives que nunca devem ser indexados.
• Documente a baseline de configuração do fornecedor: residência, retenção, auditoria, controles de pausa.

Dias 31–60: Coloque controles no caminho

• Implemente ou fortaleça seu secure web gateway (Cloudflare Gateway, Zscaler, etc.) com SNI/IP pinning para domínios de IA e copilotos. Implemente limites de taxa/tamanho.
• Levante um proxy de redação na frente de suas fontes de maior risco (Confluence/Drive/Slack). Comece com redação determinística de segredos/PII; adicione um pequeno classificador para parágrafos sensíveis.
• Integre logging de recuperação onde os vendors suportarem; envie para seu SIEM. Se não for suportado, exija em contrato antes da renovação.
• Semeie honeytokens e canários; verifique se você consegue detectá‑los no egress.
• Negocie aditivos contratuais para limites de retenção, trilhas de recuperação e SLAs de incidentes.

Dias 61–90: Simule e automatize

• Rode um exercício completo de kill‑switch: dispare a detecção, bloqueie o egress, revogue consents, pause crawlers do fornecedor. Capture MTTR e lacunas.
• Automatize política como código no seu IdP e gateway: grupos, expirações, allowlists, regras de deny e detecção de drift.
• Publique internamente um Padrão de Segurança de Copilotos: níveis, vendors aprovados, configs obrigatórias, cadência de revisão e playbook de emergência.
• Estabeleça uma revisão trimestral de logs de recuperação para capturar scope creep e instalações sombra.

Trade‑offs que você deve encarar

• Qualidade da resposta vs. segurança. Redação e conectores com escopo vão tornar as respostas menos mágicas. Seu objetivo é previsível, não mágico.
• Fricção vs. shadow IT. Se você apertar demais, times vão contornar via contas pessoais. Combine controles com uma rampa de entrada para pilotos aprovados.
• Lock‑in de fornecedor vs. controle. Envolver copilotos no seu broker dá controle, mas torna a migração mais difícil. Mantenha sua política e lógica de redação portáveis.
• Custo vs. visibilidade. Fazer logging de recuperações e operar um gateway não é de graça. Orce isso como seguro cibernético; você vai agradecer na primeira vez que um canário disparar.

Por que agora, não depois da próxima manchete

Em 2026, sobreposições de IA são o caminho mais rápido de “interno” para “público”. A maioria das organizações descobre que tem uma dúzia desses caminhos só depois de um vazamento. A infraestrutura de que você precisa — escopos de identidade, allowlists de egress, redação pré‑indexação, logging de recuperação — é tecnologia chata e comprovada. Você consegue erguer o kill‑switch central em 4–6 semanas com um time sênior e enxuto. Temos visto que uma equipe nearshore de 3–5 engenheiros faz isso 20–30% mais barato do que correr atrás do prejuízo pós‑incidente com consultores e PR no seu pescoço.

Não espere a próxima história ao estilo Rovo se desenrolar dentro do seu tenant. Faça inventário, contenha e esteja apto a puxar o plugue — nos seus termos.

Principais aprendizados

• Copilotos cross‑SaaS colapsam limites de apps e permissões; trate‑os como integrações de alto risco por padrão.
• Construa controles em três camadas: plano de requisições (tokens OBO, escopos JIT), plano de dados (redação pré‑indexação, denylists, limites de retenção) e rede (allowlists de egress).
• Exija trilhas de recuperação, suporte a OBO e configurabilidade de retenção dos fornecedores; torne isso contratual.
• Erga um proxy de redação determinístico para fontes sensíveis; aceite respostas um pouco piores em troca de muito mais segurança.
• Instrumente logs de recuperação, plante honeytokens e treine um kill‑switch de 15 minutos trimestralmente.
• Um pequeno time sênior entrega isso em 4–6 semanas; é mais barato do que limpar um vazamento.

Author: Diogo Hudson Dias