O risco oculto por trás das ferramentas de IA gratuitas: Por que o ChatGPT e outros LLMs não são seguros

Pare de fingir que seu chatbot é privado

As equipes de segurança ainda falam em "usar o ChatGPT com cuidado", como se o principal risco fosse o de um desenvolvedor colar código proprietário em um chatbot público. Esse enquadramento está desatualizado há anos. O verdadeiro problema é estrutural: modelos de linguagem grandes (LLMs) como ChatGPT, Gemini, Claude e assistentes de peso aberto não são softwares determinísticos. Eles são sistemas probabilísticos que aprendem com os dados, memorizam padrões e podem ser manipulados por meio da linguagem, e não corrigidos como os binários. Só isso já significa que a "segurança LLM" não é apenas mais uma lista de verificação de AppSec; é seu próprio domínio de segurança. (SentinelOne)

Há também uma mentira persistente dentro das empresas: "É apenas para brainstorming interno, ninguém vai ver". A realidade discorda. Dados internos - notas de auditoria, rascunhos jurídicos, modelos de ameaças, projeções de receita - estão sendo copiados para ferramentas de IA públicas ou freemium todos os dias, sem aprovação de segurança. Um estudo recente sobre o uso de IA corporativa descobriu que os funcionários estão colando ativamente códigos confidenciais, documentos de estratégia interna e dados de clientes no ChatGPT, no Microsoft Copilot, no Gemini e em ferramentas semelhantes, geralmente de contas pessoais ou não gerenciadas. Os dados corporativos deixam o ambiente por HTTPS e chegam à infraestrutura que a empresa não possui nem controla. Isso é exfiltração de dados em tempo real, não um risco hipotético. (Axios)

Em outras palavras: seus executivos acreditam que estão "pedindo ajuda a um assistente". Na verdade, o que eles estão fazendo é transmitir continuamente inteligência confidencial para um pipeline opaco de computação e registro que não pode ser auditado.

O que realmente significa "LLM security" (segurança LLM)

A "segurança do LLM" geralmente é mal interpretada como "bloquear prompts ruins e não desbloquear o modelo". Essa é uma pequena parte. A orientação moderna de fornecedores, equipes vermelhas e pesquisadores de segurança em nuvem está convergindo para uma definição mais ampla: A segurança do LLM é a proteção de ponta a ponta do modelo, dos dados, da superfície de execução e das ações downstream que o modelo pode acionar. (SentinelOne)

Na prática, o limite de segurança se estende:

• Dados de treinamento e ajuste fino. Amostras envenenadas ou mal-intencionadas podem implantar um comportamento de backdoor que só é acionado em prompts específicos criados pelo invasor. (SentinelOne)
• Pesos do modelo. O roubo, a extração ou a clonagem de um modelo bem ajustado vaza a propriedade intelectual, a vantagem competitiva e os dados potencialmente regulamentados incorporados na memória desse modelo. (SentinelOne)
• Interface do prompt. Isso inclui prompts de usuário, prompts de sistema, contexto de memória, documentos recuperados e andaimes de chamadas de ferramentas. Os invasores podem injetar instruções ocultas em qualquer uma dessas camadas para substituir a política e forçar o vazamento de dados. (Fundação OWASP)
• Superfície de ação. Os LLMs chamam cada vez mais plug-ins, APIs internas, sistemas de faturamento, ferramentas de DevOps, CRMs, sistemas financeiros, sistemas de emissão de tíquetes. Um modelo comprometido pode desencadear mudanças no mundo real, não apenas um texto ruim. (Notícias do Hacker)
• Infraestrutura de atendimento. Isso inclui bancos de dados de vetores, tempos de execução de orquestração, pipelines de recuperação e "agentes autônomos". Os sistemas agênticos herdam os riscos básicos de LLM, como injeção imediata ou envenenamento de dados, e ampliam o impacto porque o agente pode agir. (Inovia)

Wiz e outros pesquisadores de segurança na nuvem começaram a descrever isso como um "problema de pilha completa": Os incidentes de IA agora se parecem com o comprometimento clássico da nuvem (roubo de dados, escalonamento de privilégios, abuso financeiro), mas com velocidade LLM e área de superfície LLM. (Knostic)

Os órgãos reguladores estão se atualizando. O Instituto Nacional de Padrões e Tecnologia (NIST) dos EUA agora trata o comportamento adversário de ML (injeção imediata, envenenamento de dados, extração de modelos, exfiltração de modelos) como uma preocupação central de segurança no gerenciamento de riscos de IA, e não como um tópico de pesquisa especulativo. (Publicações do NIST)
Veja: Estrutura de gerenciamento de riscos de IA do NIST e Taxonomia de aprendizado de máquina adversarial (NIST AI 100-2e2025).

A incômoda verdade sobre "grátis"

Os LLMs gratuitos não são instituições de caridade. A economia é simples: atrair usuários, coletar prompts de domínio de alto valor, melhorar o produto, converter em upsell empresarial. Suas sugestões, sua metodologia de caça a bugs, seus rascunhos de relatórios de incidentes - tudo isso é combustível para o modelo de outra pessoa. (Notícias cibernéticas)

De acordo com relatórios sobre o uso de IA no local de trabalho, uma parte significativa do material confidencial que está sendo carregado inclui código inédito, linguagem de conformidade interna, linguagem de negociação legal e conteúdo de roteiro. Em alguns casos, os uploads são feitos por meio de contas pessoais para evitar controles internos, o que significa que os dados agora são regidos pela política de retenção de outra pessoa, não pela sua. (Axios)

Isso é importante por três motivos:

1. Exposição à conformidade. Você pode estar vazando dados regulamentados - dados de saúde (HIPAA), previsões financeiras (SOX) ou PII de clientes (GDPR/CCPA) - para uma infraestrutura fora de seus limites legais. Isso pode ser descoberto imediatamente em uma auditoria. (Axios)
2. Risco de espionagem corporativa. Os ataques de extração e inversão de modelos estão melhorando. Os invasores podem consultar iterativamente um LLM para reconstruir trechos da memória de treinamento ou da lógica proprietária. Isso inclui padrões de código confidenciais, credenciais vazadas e regras de decisão internas. (SentinelOne)
3. Não há limite de retenção auditável. Limpar o "histórico de bate-papo" em uma interface de usuário não significa que os dados desapareceram. Muitos provedores divulgam alguma forma de registro e retenção de curto prazo (para monitoramento de abuso, melhoria da qualidade etc.), e os plug-ins/integrações podem ter seu próprio tratamento de dados que você não consegue ver. (Notícias cibernéticas)
   Veja: O risco oculto por trás das ferramentas de IA gratuitas e SentinelOne sobre os riscos de segurança do LLM.

A versão resumida: quando seu VP cola um modelo de ameaça em um "assistente de IA gratuito", você criou um processador terceirizado de seu material mais sensível, sem contrato, sem DPA e sem SLA de retenção.

Dez modos de falha de segurança do LLM ativo que você deve modelar como ameaça

O Top 10 da OWASP para aplicativos de modelos de linguagem grandes e os recentes relatórios de incidentes de IA convergem para a mesma realidade incômoda: As implantações de LLM já estão sendo atacadas na produção, e os ataques são mapeados claramente para classes conhecidas. (Fundação OWASP)
Veja: OWASP Top 10 para aplicativos LLM.

Esta tabela não é um "trabalho futuro". Cada linha já foi observada em sistemas de produção em SaaS, finanças, defesa e ferramentas de segurança. (SentinelOne)

A Shadow AI já é um trabalho de resposta a incidentes, não uma teoria

A maioria das organizações não tem visibilidade total de como a IA está sendo usada internamente. Os funcionários pedem discretamente aos LLMs públicos para resumir auditorias, reescrever políticas de conformidade ou redigir comunicações com clientes. Em vários casos documentados, documentos confidenciais de segurança interna foram colados no ChatGPT ou em serviços semelhantes a partir de contas pessoais não gerenciadas, desencadeando análises de incidentes pós-fato. Essas análises consumiram semanas de tempo forense, não porque houve uma violação confirmada, mas porque as equipes jurídicas e de segurança tiveram que responder: "Será que acabamos de vazar dados regulamentados para um fornecedor com o qual não temos contrato?" (Axios)

Por que o DLP legado não pode resolver isso:

• O tráfego para o ChatGPT ou ferramentas semelhantes se parece com o HTTPS criptografado normal.
• A inspeção imediata completa por meio de interceptação SSL é legal e politicamente radioativa na maioria das empresas.
• Mesmo que você force os controles do navegador local, muitos recursos de IA agora estão incorporados em outras ferramentas de SaaS (editores de documentos, assistentes de CRM, resumidores de e-mail). Seus usuários podem estar vazando dados por meio de "recursos de IA" que eles nem percebem que são IA. (Axios)

Esse fenômeno é muitas vezes chamado de "Shadow AI". Esse nome é enganoso. Os funcionários não estão sendo imprudentes; eles estão apenas se movendo mais rápido do que a governança. Trate a IA sombria como um SaaS sombrio - exceto que esse SaaS pode memorizar você.

Um manual defensivo mínimo para engenheiros de segurança

Os controles a seguir são possíveis com a pilha de segurança atual. Não é necessário ficção científica.

Trate os prompts como entradas não confiáveis

• Separe os "prompts do sistema" (a política e as instruções de comportamento do modelo) da entrada do usuário. Não permita que entradas não confiáveis substituam a política do sistema. Essa é a primeira linha de defesa contra a injeção de prompts e contra a quebra de sigilo no estilo "ignore todas as regras anteriores". (Fundação OWASP)
• Registre e difunda prompts de alto risco para análise posterior.

Tratar as respostas como saída não confiável

• Nunca execute diretamente SQL gerado pelo modelo, comandos de shell, etapas de correção ou chamadas de API. Presuma que todas as saídas do modelo são controladas pelo invasor até que se prove o contrário. A OWASP chama isso de Insecure Output Handling e é um risco de alto nível do LLM. (Fundação OWASP)
• Forçar todas as ações acionadas pelo LLM por meio de aplicação de políticas, sandboxing e listas de permissões.

Autonomia do modelo de controle

• Qualquer agente que possa modificar o faturamento, as configurações de produção, os registros de clientes ou os dados de identidade/titularidade deve exigir aprovação humana explícita para ações de alto impacto. O comprometimento do agente é multiplicativo: quando um agente é orientado, ele continua agindo. (Inovia)
• Escopo das credenciais por ação, não por agente. Um agente não deve manter tokens de administrador de longa duração.

Assista ao abuso econômico

• Limite a taxa de tokens, o comprimento do contexto e as invocações de ferramentas. A OWASP chama a atenção para o "Modelo de negação de serviço": prompts adversariamente grandes podem aumentar o custo da GPU e degradar o serviço ("negação de carteira"). (Fundação OWASP)
• O departamento financeiro deve ver "gastos com inferência LLM" como um item de linha monitorado, da mesma forma que você monitora a largura de banda de saída.

Para obter orientações mais detalhadas, consulte:

• OWASP Top 10 para aplicativos de modelo de linguagem grande
• SentinelOne: Riscos de segurança do LLM
• Estrutura de gerenciamento de riscos de IA do NIST

Exemplo: envolver um LLM em uma camada de política e sandbox

O objetivo do esboço a seguir é simples: nunca confie na E/S bruta do modelo. Você aplica a política antes de chamar o modelo e coloca em sandbox qualquer coisa que o modelo queira executar depois.

# Pseudocódigo para um wrapper de segurança do LLM

class SecurityException(Exception):
    passa

# (1) Governança de entrada: rejeita tentativas óbvias de injeção de prompt
def sanitize_prompt(user_prompt: str) -> str:
    banned_phrases = [
        "ignorar instruções anteriores",
        "exfiltrar segredos",
        "despejar credenciais",
        "contornar a segurança e continuar"
    ]
    lower_p = user_prompt.lower()
    if any(p in lower_p for p in banned_phrases):
        raise SecurityException("Possível injeção de prompt detectada.")
    return user_prompt

# (2) Chamada de modelo com separação estrita entre sistema/usuário
def call_llm(system_prompt: str, user_prompt: str) -> str:
    safe_user_prompt = sanitize_prompt(user_prompt)
    resposta = model.generate(
        system=lockdown(system_prompt), função de sistema imutável #
        user=safe_user_prompt,
        max_tokens=512,
        temperature=0.2,
    )
    retornar resposta

# (3) Governança de saída: nunca execute cegamente
def execute_action(llm_response: str):
    parsed = parse_action(llm_response)

    if parsed.type == "shell":
        # Somente lista de permissão, dentro do contêiner de sandbox preso
        se parsed.command não estiver em ALLOWLIST:
            raise SecurityException("Comando não permitido.")
        return sandbox_run(parsed.command)

    elif parsed.type == "sql":
        # Consultas parametrizadas, somente leitura
        return db_readonly_query(parsed.query)

    else:
        # Texto simples, ainda tratado como dados não confiáveis
        return parsed.content

# Audite cada etapa para fins forenses e de defesa regulatória
answer = call_llm(SYSTEM_POLICY, user_input)
result = execute_action(answer)
audit_log(user_input, answer, result)

Esse padrão se alinha diretamente com os principais riscos LLM da OWASP: Injeção de Prompt (LLM01), Manipulação de Saída Insegura (LLM02), Envenenamento de Dados de Treinamento (LLM03), Negação de Serviço de Modelo (LLM04), Vulnerabilidades da Cadeia de Suprimentos (LLM05), Agência Excessiva (LLM08) e Excesso de Confiança (LLM09). (Fundação OWASP)

Onde o pentesting automatizado de IA se encaixa (Penligent)

Nesse ponto, a "segurança do LLM" deixa de soar como um teatro de governança e começa a se parecer novamente com segurança ofensiva. Você não se limita a perguntar: "Nosso modelo é seguro?". Você tenta quebrá-lo - de forma controlada - exatamente da mesma forma que testaria uma API exposta ou um ativo voltado para a Internet.

Esse é o nicho que Penligente se concentra em: testes de penetração automatizados e explicáveis que tratam os sistemas orientados por IA (aplicativos LLM, pipelines de geração aumentados por recuperação, plug-ins, estruturas de agentes, integrações de banco de dados de vetores) como superfícies de ataque, não como caixas mágicas.

Em termos concretos, uma plataforma como a Penligent pode:

• Tente injeção de prompt e padrões de jailbreak contra seu assistente interno e registre quais foram bem-sucedidos.
• Explore se um prompt não confiável pode induzir um "agente" interno a acessar APIs privilegiadas, por exemplo, finanças, implementação, emissão de tíquetes. (Inovia)
• Sondagem de caminhos de exfiltração de dados: o modelo vaza memória de conversas anteriores ou de dados de treinamento que incluem PII, segredos ou código-fonte? (SentinelOne)
• Simule a "negação de carteira": um invasor pode aumentar sua conta de inferência ou saturar seu pool de GPUs apenas alimentando prompts patológicos? (Fundação OWASP)
• Gere um relatório com base em evidências que mapeie cada exploração bem-sucedida para o impacto concreto nos negócios (exposição regulatória, potencial de fraude, aumento de custos) e orientação de correção que a engenharia e a liderança possam adotar.

Isso é importante porque a maioria das organizações ainda não consegue responder a perguntas básicas como:

• "Um prompt externo pode fazer com que nosso agente interno chame uma API de faturamento privilegiada?"
• "O modelo pode vazar partes dos dados de treinamento que se parecem muito com as informações pessoais do cliente?"
• "Alguém pode forçar nossa conta de GPU a explodir de uma forma que o Finance só perceberá no próximo mês?" (Fundação OWASP)

Os pentests tradicionais da Web raramente cobrem esses fluxos. O pentesting automatizado e com reconhecimento de LLM é a forma de transformar a "segurança LLM" de um slide de política em evidência real e verificável.

Próximas etapas imediatas para engenheiros de segurança

1. Faça um inventário dos pontos de contato do LLM. Classifique onde os LLMs residem em sua organização:
   • SaaS público (contas no estilo ChatGPT)
   • "LLM empresarial" hospedado pelo fornecedor
   • Modelos internos auto-hospedados ou ajustados
   • Agentes autônomos conectados à infraestrutura e à CI/CD
     Este é seu novo mapa de superfície de ataque. (Axios)
2. Tratar os LLMs públicos como SaaS externos. "Nenhum segredo em ferramentas de IA não gerenciadas" deve ser escrito como política, não como sugestão. Treine a equipe para tratar as ferramentas de IA gratuitas exatamente como uma postagem em um fórum público: depois que ela sai, você não controla a retenção. (Notícias cibernéticas)
3. Bloquear ações de alto impacto atrás de humanos. Qualquer agente de IA que possa movimentar dinheiro, alterar configurações ou destruir registros deve exigir aprovação humana explícita para etapas de alto impacto. Assuma o compromisso. Construa para contenção. (Inovia)
4. Tornar o pentesting com reconhecimento de LLM parte da versão. Antes de enviar um "assistente de IA" para os clientes ou funcionários, execute um teste contraditório que tente:
   • injetar prompts,
   • extrair segredos,
   • aumentar os privilégios do plug-in,
   • custo do pico.
     Trate isso como você trata os pentests de API externos.

Referências recomendadas para seu manual:

• OWASP Top 10 para aplicativos de modelo de linguagem grande - riscos classificados pela comunidade específicos para LLMs (injeção imediata, manipulação insegura de saída, envenenamento de dados de treinamento, negação de serviço, cadeia de suprimentos, agência excessiva, excesso de confiança). (Fundação OWASP)
• Estrutura de gerenciamento de riscos de IA do NIST - formaliza solicitações adversárias, extração de modelos, envenenamento de dados e exfiltração de modelos como obrigações de segurança, e não apenas curiosidades de pesquisa. (Publicações do NIST)
• SentinelOne: Riscos de segurança do LLM - catálogo contínuo de técnicas reais de invasores, incluindo injeção imediata, envenenamento de dados de treinamento, comprometimento de agentes e roubo de modelos. (SentinelOne)
• O risco oculto por trás das ferramentas de IA gratuitas - governança de dados e realidades de retenção do uso gratuito de IA na empresa. (Notícias cibernéticas)
• Penligente - teste de penetração automatizado projetado para a infraestrutura da era da IA: LLMs, agentes, plugins e superfícies de custo.

Conclusão final

A segurança do LLM não é uma higiene opcional. É resposta a incidentes, controle de custos, proteção de IP, governança de dados e segurança de produção - tudo ao mesmo tempo. Tratar o ChatGPT como "apenas uma ferramenta de produtividade gratuita" sem modelagem de ameaças é o equivalente a permitir que os engenheiros enviem credenciais de texto simples por e-mail porque "é interno de qualquer maneira". A IA gratuita não é gratuita. Você está pagando em dados, em superfície de ataque e, eventualmente, em tempo de análise forense. (Notícias cibernéticas)

Se você for responsável pela segurança, não poderá mais dizer "não estamos fazendo IA". Sua organização já está fazendo. Sua única escolha real é se você pode provar - com evidências, não com vibrações - que está fazendo isso com segurança.