IA impulsiona ações de cibersegurança, mas proteção exige mais que investimento

A valorização de fornecedores de segurança reflete expectativas sobre a demanda criada pela inteligência artificial. Dentro das empresas, entretanto, o desafio é transformar orçamento em limites de acesso, proteção de dados e capacidade de interromper ações indevidas.

A relação entre IA e cibersegurança ganhou uma expressão financeira no pregão de 21 de setembro de 2026. Segundo reportagem de David Moadel, do 24/7 Wall St., distribuída pelo Yahoo Finance, CrowdStrike e Okta avançavam 4,02% e 4,05%, respectivamente, enquanto Palo Alto Networks subia 2,06%. Eram variações durante o pregão, não cotações de fechamento.

A publicação associou o movimento a alertas sobre segurança de IA e à expectativa de aumento dos gastos empresariais com defesa. A distinção é importante: trata-se de uma interpretação de mercado sobre demanda futura, não de comprovação de novas receitas ou de maior eficácia dos produtos. No mesmo recorte, o fundo setorial CIBR avançava 2,46%, próximo dos 2,53% do QQQ.

A alta das ações não é uma avaliação de segurança

Para gestores, o episódio é um ponto de partida para uma discussão diferente daquela feita por investidores. Uma empresa pode aumentar despesas com tecnologia e continuar sem saber quais agentes acessam suas bases, quem autorizou essas conexões ou como interrompê-las. O valor contratado, isoladamente, não demonstra que uma exposição foi eliminada.

Também seria inadequado transformar a diferença entre as ações em uma classificação técnica dos fornecedores. A própria documentação de Prisma AIRS, da Palo Alto Networks, descreve proteção de aplicações, modelos e agentes de IA. Esse escopo declarado não prova eficácia independente, mas mostra por que rótulos simplificados, como associar um fornecedor apenas à rede, não substituem a avaliação de capacidades.

Quando o conteúdo recebido vira uma instrução

Um risco central aparece quando a IA deixa de apenas produzir respostas e passa a acionar ferramentas. A OWASP descreve a prompt injection indireta como a influência de conteúdo externo, como arquivos e páginas, sobre o comportamento do modelo. A informação que deveria ser analisada pode ser interpretada como uma ordem, desviando a tarefa original.

Em um exemplo hipotético, um assistente de compras poderia consultar uma proposta de fornecedor contendo instruções para encaminhar documentos internos a outro destinatário. O dano dependeria de suas ferramentas e permissões: conseguir redigir uma mensagem não é o mesmo que poder enviá-la. Não se trata de consciência ou vontade própria da IA, mas de uma fronteira de confiança mal protegida.

Esse mecanismo se conecta à análise já publicada pelo Blog sobre prompt injection em páginas e documentos. A defesa deve tratar conteúdo recuperado como não confiável, testar tentativas de desvio e limitar consequências. Instruções no prompt ajudam, mas não equivalem a uma barreira de autorização; a OWASP também ressalta que RAG e ajustes do modelo não eliminam essa vulnerabilidade.

Identidade e privilégios determinam o alcance do dano

A autonomia excessiva, tratada pela OWASP como Excessive Agency, combina funções desnecessárias, permissões amplas ou liberdade para executar ações de alto impacto. Um conector criado para consultar documentos não deveria permitir exclusão por conveniência. Da mesma forma, uma tarefa restrita a um departamento não justifica uma conta de serviço com acesso a toda a organização.

A aplicação do princípio do menor privilégio exige separar operações de leitura e escrita, reduzir ferramentas disponíveis e preservar o contexto de autorização do usuário. Ações sensíveis devem depender de aprovação efetiva antes da execução. A decisão de permitir uma operação precisa ser aplicada no serviço ou conector, não delegada exclusivamente ao modelo que propôs realizá-la.

Autenticar uma identidade também não significa autorizar qualquer ação. Conforme o guia de autorização da OWASP, a aplicação deve negar acessos por padrão e validar permissões em cada requisição. Isso inclui o recurso concreto: uma autorização para consultar um contrato não deve permitir acessar outro cliente apenas pela troca de um identificador.

Dados e credenciais precisam de proteção própria

Nem toda exposição depende de uma ação deliberadamente maliciosa. A OWASP inclui a divulgação de informações sensíveis entre os riscos de aplicações com modelos de linguagem: dados pessoais, documentos confidenciais e informações comerciais podem aparecer indevidamente em respostas. Restringir fontes e usuários, minimizar dados enviados e aplicar mascaramento são controles complementares, não substitutos uns dos outros.

A avaliação deve alcançar o destino da informação, inclusive as condições de uso, retenção e exclusão previstas para cada serviço contratado. Não se deve presumir que todos os fornecedores tratam os dados da mesma forma. Uma política de uso de IA precisa esclarecer o que pode ser enviado, por quem e com qual finalidade, além de verificar se essas restrições funcionam tecnicamente.

Chaves de API e outros segredos merecem uma camada separada. O guia de gerenciamento de segredos da OWASP orienta controle de acesso, auditoria e gestão de todo o ciclo de vida das credenciais. Em integrações com IA, isso significa evitar segredos no contexto do modelo, preferir credenciais de duração limitada quando suportadas e preparar rotação e revogação sem depender da exclusão de uma conversa.

Resultados incorretos também podem produzir prejuízo

A saída do modelo deve ser tratada como entrada não confiável para o próximo sistema. A categoria Improper Output Handling, da OWASP, aborda a falta de validação antes de utilizar respostas em outros componentes. Aceitar automaticamente um comando, uma consulta ou conteúdo executável transforma um erro de geração em possível alteração de dados, execução indevida ou exposição de informação.

O problema também pode chegar à disponibilidade e ao custo operacional. A OWASP descreve o consumo sem limites como risco para recursos e despesas. Limites de requisições, tempo de execução e consumo por usuário ou tarefa ajudam a conter abusos. Um agente que repete chamadas indefinidamente pode comprometer um serviço mesmo sem explorar uma vulnerabilidade tradicional.

Governança precisa aparecer na operação

O AI Risk Management Framework do NIST organiza a gestão de riscos nas funções Govern, Map, Measure e Manage. Aplicadas ao ambiente corporativo, elas ajudam a conectar responsabilidades, contexto de uso, avaliação e tratamento. A segurança deixa de ser uma aprovação isolada no lançamento e passa a acompanhar mudanças nos sistemas e em suas condições de operação.

Um inventário útil deve relacionar aplicação, responsável, dados utilizados, integrações e consequência de uma falha. A prioridade pode então considerar tanto exposição quanto impacto: um assistente que consulta material público demanda controles diferentes dos exigidos para outro que altera contratos ou autoriza operações financeiras. Essa classificação deve orientar limites de autonomia e decisões de aceitação de risco.

A validação operacional precisa ir além de perguntar ao modelo se ele respeita regras. O guia de segurança de agentes da OWASP recomenda testes adversariais, rastreabilidade e proteção das aprovações. Uma autorização para ação crítica deve estar vinculada à operação exata, aos parâmetros e ao prazo, evitando que uma confirmação genérica seja reutilizada para executar algo diferente.

Os registros devem permitir reconstruir quem solicitou a tarefa, qual ferramenta foi acionada, que autorização foi aplicada e qual resultado ocorreu, sem transformar logs em depósitos de segredos. Também devem existir meios de interromper operações e reverter alterações quando possível. Para mudanças irreversíveis, a prevenção precisa ser mais rigorosa: desligar o agente depois do envio de um documento não desfaz o vazamento.

Como transformar orçamento em redução de risco

Como proposta de avaliação, a direção pode acompanhar a proporção de agentes inventariados com responsável definido, acessos revisados, integrações com autorização testada e ações críticas cobertas por aprovação verificável. Outros indicadores úteis são o tempo para revogar uma credencial comprometida e o resultado dos testes de recuperação. Essas métricas devem ser adaptadas ao negócio, não tratadas como uma certificação automática.

A contratação de tecnologia deve responder às lacunas identificadas. Uma prova de conceito pode verificar se a solução realmente bloqueia uma operação fora do escopo, registra evidências suficientes e se integra à resposta a incidentes. O critério decisivo é a redução demonstrável da exposição, incluindo limitações e risco residual, e não apenas a presença de IA no nome do produto.

O retorno relevante é manter o controle

A aproximação entre IA e cibersegurança exige separar dois planos: a expectativa de crescimento do mercado e a proteção efetiva das organizações. Para a gestão, a pergunta não é qual fornecedor mais se valorizou em um pregão, mas quais acessos, dados e operações permanecem sem controle demonstrável. Investimento faz sentido quando fecha essa distância e sustenta uma capacidade verificável de prevenir, detectar e responder.