Pesquisa da SecurityHQ sobre Agentes de IA Descobre que Políticas Superam a Responsabilização por Incidentes

A SecurityHQ publicou uma pesquisa mostrando que 76% dos líderes de cibersegurança entrevistados têm políticas formais de responsabilização por IA, enquanto apenas 17% conseguiriam reconstruir a atividade de agentes em questão de minutos. A pesquisa da SecurityHQ sobre agentes de IA, desenvolvida com a Datadog, expõe uma tensão prática: atribuir responsabilidade não torna necessariamente uma decisão automatizada explicável.

Divulgadas em 15 de outubro de 2026, as conclusões surgem à medida que agentes empresariais ganham permissão para realizar tarefas em sistemas de negócios. Agentes de IA são sistemas de software que usam modelos e ferramentas conectadas para executar tarefas. Sua autoridade cria questões que políticas escritas, por si só, não conseguem responder.

A expansão do Security Copilot pela Microsoft oferece uma referência concreta para essa mudança rumo ao trabalho de segurança delegado. A pressão agora recai sobre líderes de segurança, proprietários de aplicações e fornecedores para conectar ações automatizadas a evidências e à autoridade humana responsável.

Pesquisa da SecurityHQ sobre Agentes de IA Separa Política de Preparação

O estudo entrevistou 204 líderes de cibersegurança de organizações de médio e grande porte. Segundo o anúncio da pesquisa, 45% haviam enfrentado um incidente envolvendo agentes de IA ou automação em que a responsabilidade não estava clara.

Essa redação merece atenção. A categoria de incidentes inclui automação, portanto o resultado não comprova que 45% tenham sofrido uma violação causada por um agente de IA autônomo. A responsabilização pouco clara também descreve um problema organizacional, e não uma falha técnica específica ou determinado nível de dano.

A constatação diz respeito à capacidade das organizações de explicar ações delegadas quando a responsabilidade passa a ser contestada. Uma política pode identificar um responsável sem mostrar qual instrução, permissão ou interação de sistema produziu um resultado.

As constatações públicas sobre responsabilização da SecurityHQ também distinguem a visibilidade histórica da prontidão investigativa imediata. Apenas 49% disseram conseguir reconstruir integralmente as ações de um agente nos 30 dias anteriores.

Essa distinção muda a forma como compradores devem interpretar os resultados. Reter registros e responder a perguntas urgentes são capacidades relacionadas, mas atendem a necessidades operacionais diferentes. Uma organização pode preservar evidências relevantes e ainda precisar de um trabalho manual substancial para conectá-las.

Por outro lado, um painel pode resumir a atividade recente sem reter detalhes suficientes para uma investigação posterior. Nenhuma das possibilidades estabelece o que aconteceu dentro das organizações pesquisadas. Ambas explicam por que uma única alegação de visibilidade exige uma análise mais cuidadosa.

A mudança importante está no enquadramento da pesquisa. A SecurityHQ coloca a propriedade da política ao lado da capacidade de estabelecer uma sequência de ações, tornando visível a distância entre essas capacidades.

Para compradores empresariais, isso cria uma questão de aquisição mais exigente. A explicação de um fornecedor sobre governança deve se conectar às evidências que um cliente recebe depois que um agente atua.

Para equipes internas de segurança, a mesma distinção afeta os relatórios. A existência de um processo de aprovação não estabelece que os investigadores possam recuperar a aprovação associada a uma ação contestada.

Uma política de responsabilização continua útil porque define expectativas. Seu valor operacional depende de as pessoas conseguirem aplicar essas expectativas a um evento específico.

A pesquisa não estabelece que organizações com políticas tenham enfrentado menos incidentes. Também não mostra que a compra de monitoramento adicional resolveria a incerteza sobre responsabilidade.

Sua contribuição mais restrita ainda é relevante. Empresas podem alocar formalmente a responsabilidade sem dispor das evidências necessárias para exercê-la sob pressão.

É por isso que a história importa além de mais uma pesquisa sobre risco de IA. A pesquisa questiona se medidas familiares de governança descrevem a preparação real quando o software recebe autoridade delegada.

Trabalho de Segurança Delegado Coloca Compradores e Operadores Sob Pressão

Líderes de segurança enfrentam pressão porque os agentes operam em sistemas que já dividem a responsabilidade entre equipes diferentes. Um proprietário de aplicação pode autorizar um fluxo de trabalho, enquanto outra equipe administra suas credenciais e outra conduz a resposta a incidentes.

Uma credencial é a prova digital que o software apresenta ao solicitar acesso. Quando vários fluxos de trabalho compartilham essa prova, identificar a conta pode deixar sem resposta quem foi o iniciador real.

Uma questão de propriedade aparentemente simples então se divide em várias perguntas. Quem aprovou a tarefa, quem concedeu o acesso, quem manteve a integração e quem poderia interromper a execução?

Essas funções não precisam pertencer à mesma pessoa. A dificuldade surge quando a organização não consegue conectá-las durante uma investigação.

Delegar trabalho aumenta a importância de saber onde a autoridade começa, muda e termina. Um executivo nomeado não consegue resolver um incidente simplesmente por constar em um documento de governança.

As consequências operacionais vão além dos departamentos de segurança. Proprietários de negócios precisam entender se a ação de um agente atendeu a um objetivo aprovado. Equipes de aplicações precisam de contexto suficiente para distinguir comportamento esperado de uso indevido.

As equipes jurídica e de risco enfrentam uma preocupação diferente: se o registro disponível sustenta a explicação fornecida posteriormente pela empresa. Uma narrativa confiante tem valor limitado quando suas evidências de suporte permanecem fragmentadas.

Os fornecedores também enfrentam pressão porque os clientes dependem do design do produto para partes desse registro. Os clientes não conseguem recuperar de forma independente informações que um serviço nunca expõe ou retém.

A Microsoft ilustra por que essas questões se tornaram imediatas. Seu anúncio de agentes de segurança de março de 2025 apresentou agentes para tarefas como triagem de phishing, que consiste em classificar e avaliar mensagens suspeitas de engano.

A empresa apresentou essas capacidades como uma forma de reduzir o trabalho rotineiro dos defensores. Isso fornece um contexto concreto de implementação sem estabelecer que os produtos da Microsoft apresentem as lacunas relatadas pela SecurityHQ.

A comparação diz respeito à proposta de compra. A Microsoft descreve o trabalho que os agentes podem assumir; a SecurityHQ pergunta se as organizações conseguem prestar contas da atividade delegada posteriormente.

Essas propostas pertencem à mesma discussão de compra. Uma alegação de eficiência se torna mais útil quando os compradores também conseguem avaliar o esforço de investigação, as opções de intervenção e a disponibilidade de evidências.

Para um centro de operações de segurança, a equipe responsável por monitorar e responder a ameaças, a redução da carga de trabalho rotineira oferece um apelo claro. Ainda assim, ações não resolvidas criam trabalho em outros lugares.

Um analista que recebe a conclusão de um agente ainda precisa compreender sua base quando as circunstâncias mudam. Outro investigador pode precisar revisitar essa decisão depois que a tarefa original termina.

A pressão, portanto, alcança tanto a aprovação da implementação quanto as operações contínuas. Os compradores precisam de evidências sobre como o sistema se comporta após a adoção, inclusive quando suas ações exigem explicação.

Isso não torna a autonomia inerentemente inadequada para o trabalho de segurança. Torna o escopo da autoridade delegada central para avaliar se o acordo operacional vale a pena.

Automação Útil Ainda Precisa de uma Trilha de Ações Explicável

A tensão central está entre o tempo que os agentes economizam no trabalho comum e o esforço necessário para explicar resultados excepcionais. A execução mais rápida só cria valor dentro de limites que a organização consegue defender.

Considere a triagem de phishing como um fluxo de trabalho ilustrativo, e não como um incidente relatado pela SecurityHQ. Um agente analisa uma mensagem suspeita, consulta informações conectadas e produz uma classificação.

Uma investigação útil conectaria a mensagem, as informações consultadas, a identidade do agente e a ação resultante. Se houvesse aprovação, os investigadores também precisariam conectá-la à ação.

Registrar que uma tarefa foi concluída responde a uma pergunta mais limitada. Isso estabelece um ponto final sem necessariamente explicar como o sistema chegou até ele.

Uma trilha de ações responsabilizável deve conectar instruções, autoridade, execução e resultado. A conexão importa porque qualquer um desses elementos pode se tornar a parte contestada de um incidente.

A instrução pode ter sido apropriada enquanto a permissão era excessiva. A permissão pode ter sido apropriada enquanto informações encontradas durante a execução redirecionaram a tarefa.

Alternativamente, o agente pode ter seguido corretamente o fluxo de trabalho solicitado enquanto a regra de negócio subjacente estava errada. A responsabilização também precisa abrir espaço para essa possibilidade.

Um registro centrado inteiramente no modelo corre o risco de ignorar essas distinções. Um modelo é apenas parte da aplicação que recebe instruções, recupera informações e chama ferramentas conectadas.

Uma interface de programação de aplicações, ou API, é uma interface de software por meio da qual um sistema solicita as funções de outro sistema. A atividade de agentes pode atravessar essas interfaces e seus registros separados.

Cada serviço pode descrever com precisão sua interação local, deixando a tarefa geral difícil de reconstruir. O elemento ausente é a relação entre registros que, isoladamente, são válidos.

As constatações sobre segurança de agentes da Salt Security, de 13 de outubro, oferecem uma visão separada desse problema. Sua pesquisa combinou mais de 380 respostas de pesquisa com telemetria de produção.

Apenas 12,5% dos entrevistados disseram conseguir rastrear consistentemente caminhos completos de agentes em todos os agentes. A Salt também informou que 17,5% conseguiam interromper automaticamente um agente com comportamento inesperado em produção.

Esses números medem capacidades diferentes das questões de reconstrução da SecurityHQ. Eles não devem ser combinados em uma pontuação compartilhada nem tratados como estimativas equivalentes.

Sua relevância é conceitual: rastrear uma ação e interromper uma ação são partes separadas do controle. Uma explicação completa após um incidente não reverte suas consequências.

Da mesma forma, interromper um fluxo de trabalho não explica por que ele se comportou de forma inesperada. Os compradores precisam avaliar ambas as capacidades sem presumir que uma garante a outra.

A comparação comercial é, portanto, mais ampla do que uma disputa entre fornecedores individuais. A SecurityHQ enfatiza a responsabilização operacional, a Microsoft descreve tarefas de segurança delegadas e a Salt destaca rastreamento e contenção.

Essas perspectivas se cruzam em torno de um problema comum dos clientes. As empresas precisam que o trabalho delegado permaneça compreensível além das fronteiras dos produtos, onde a responsabilidade frequentemente se torna mais difícil de estabelecer.

A Aprovação Humana Não Pode Carregar Todo o Fardo da Responsabilização

A revisão humana continua sendo uma resposta atraente porque coloca uma pessoa próxima de uma decisão relevante. Sua utilidade depende do que essa pessoa consegue inspecionar e autorizar.

Uma aprovação vinculada a um objetivo vago deixa espaço para discordâncias sobre as ações permitidas. Uma aprovação vinculada a uma ação específica estabelece um limite mais claro.

Mesmo assim, os investigadores precisam saber se a execução correspondeu à solicitação aprovada. Aprovação e execução descrevem momentos diferentes, potencialmente separados por mudanças nas informações ou nas condições do sistema.

A supervisão humana contribui para a responsabilização quando o registro de aprovação corresponde à autoridade realmente exercida. O envolvimento de uma pessoa não fornece automaticamente o histórico técnico que falta.

Essa distinção importa para líderes empresariais que esperam que um revisor final assuma a responsabilidade por todo um fluxo de trabalho. Um revisor não pode avaliar de forma significativa informações que o sistema não revela.

Também importa para equipes de produto que decidem onde posicionar etapas de aprovação. Interromper cada ação introduz atrito, enquanto aprovar uma tarefa inteira delega uma margem de decisão mais ampla.

A escolha prática envolve quais decisões exigem intervenção e quais limites o software pode impor diretamente. Fluxos de trabalho diferentes justificam respostas diferentes porque suas possíveis consequências variam.

Um sistema que apenas recomenda uma resposta apresenta uma questão de autoridade diferente daquela de um sistema que altera acessos. A comparação relevante é a ação permitida, e não a presença de um rótulo de IA.

A identidade também se torna mais importante à medida que os agentes atuam além das fronteiras organizacionais. A autenticação estabelece quem ou o que está fazendo uma solicitação; a autorização determina o que esse solicitante pode fazer.

Nenhuma das duas funções, por si só, explica o objetivo de negócio por trás de uma solicitação. Uma investigação se beneficia ao conectar a identidade técnica à tarefa e à pessoa ou processo que a delegou.

O trabalho de identidade de agentes do NIST oferece uma referência institucional para esse desafio. Em setembro, o órgão identificou o desenvolvimento de software como seu primeiro caso de uso de implementação.

Esse trabalho se concentra em identificar, autenticar e autorizar agentes dentro do ciclo de vida de desenvolvimento de software. Trata-se de um esforço de implementação, e não de evidência de que a responsabilização empresarial foi resolvida.

A direção importa porque a responsabilização depende, em parte, de como a autoridade transita pelo software. Padrões e demonstrações podem ajudar a tornar essas relações mais fáceis de expressar de modo consistente.

No entanto, uma identidade técnica não pode decidir quem deve assumir um resultado empresarial contestado. As organizações ainda precisam de responsabilidades explícitas para implantação, manutenção, revisão e intervenção de emergência.

Registros claros e funções claras se reforçam mutuamente. Os registros ajudam a estabelecer o que aconteceu, enquanto as funções determinam quem deve avaliar e responder a essas evidências.

A mesma distinção se aplica ao conhecimento organizacional. Uma base de conhecimento da equipe pesquisável pode apoiar o acesso a políticas e responsabilidades, enquanto as evidências de execução estabelecem o que os sistemas realmente fizeram.

Manter essas funções distintas ajuda a evitar um erro conhecido. Documentar o fluxo de trabalho esperado não estabelece que uma execução específica o seguiu.

A Pesquisa Levanta Questões Que Não Pode Resolver

A pesquisa sobre agentes de IA da SecurityHQ fornece evidências sobre a experiência relatada e a confiança dos respondentes. Ela não mede de forma independente o comportamento de todos os agentes dentro de suas organizações.

A prontidão autodeclarada pode diferir do desempenho durante um incidente real. Os respondentes podem interpretar de maneiras diferentes a reconstrução, a responsabilização e a atividade dos agentes.

Um líder pode descrever uma forte supervisão central enquanto implantações descentralizadas permanecem fora desse campo de visão. Outro pode relatar baixa prontidão apesar de contar com equipes capazes e processos internos pouco familiares.

Essas possibilidades não invalidam os resultados. Elas limitam a certeza das conclusões extraídas deles.

A pesquisa sustenta um exame rigoroso da prontidão empresarial, e não uma estimativa universal de falha dos agentes. Seus resumos públicos não devem se tornar um substituto para testar implantações individuais.

O anúncio público e a página de destino não fornecem detalhes metodológicos suficientes para estabelecer ampla representatividade. Os leitores devem evitar supor que a amostra espelha todos os setores ou portes de empresa.

A combinação de agentes de IA e automação na pergunta sobre incidentes cria outra limitação. Ela deixa incerto quanto da incerteza relatada surgiu de agentes mais novos em comparação com fluxos de trabalho automatizados já estabelecidos.

Essa distinção importa ao interpretar a novidade. Há muito tempo as organizações enfrentam dificuldades para atribuir responsabilidades entre integrações de software, serviços terceirizados e processos operacionais compartilhados.

As implantações de agentes podem complicar esse problema existente sem tornar nova toda fragilidade subjacente. Tratar toda a questão como exclusiva da IA corre o risco de ocultar falhas de controle conhecidas.

A relação entre políticas e incidentes também permanece sem resolução. Os resultados agregados não estabelecem quais respondentes tinham políticas quando ocorreram incidentes específicos.

Portanto, eles não podem demonstrar que as políticas falharam em prevenir incidentes, nem que organizações sem políticas tiveram desempenho pior. Qualquer uma dessas afirmações exigiria evidências adicionais.

A pesquisa sobre agentes de IA da SecurityHQ também vem de organizações com interesses comerciais em segurança e monitoramento. Esse contexto merece ser divulgado sem que suas observações sejam automaticamente descartadas.

A resposta cética apropriada é examinar definições, metodologia e evidências reproduzíveis. Patrocínio comercial e resultados úteis podem coexistir.

Cautela semelhante se aplica às comparações com os resultados da Salt. Perguntas, populações e métodos de medição diferentes impedem uma classificação clara da prontidão empresarial entre os estudos.

Concordância quanto à preocupação geral não estabelece concordância sobre a prevalência medida. Os estudos contribuem com observações separadas sobre visibilidade, autoridade e intervenção.

A pesquisa tampouco estabelece que centralizar mais registros sempre melhora a segurança. Os registros podem conter informações sensíveis, e o acesso a evidências investigativas cria suas próprias responsabilidades.

A implicação analítica é mais restrita: as organizações precisam de evidências suficientes para as decisões que delegam. O que conta como suficiente depende da ação e de suas consequências.

Uma resposta convincente mostraria como um fluxo de trabalho específico permanece atribuível durante uma falha. Uma afirmação mais ampla de que uma plataforma torna todos os agentes responsáveis exige uma base de evidências muito maior.

Acompanhe Evidências de Incidentes, Controles de Produto e Implementações de Identidade

Nos próximos meses, os desenvolvimentos mais úteis mostrarão se as organizações conseguem transformar a responsabilização declarada em capacidade operacional demonstrável. Anúncios de adoção, por si só, deixarão essa questão sem resposta.

O primeiro sinal é a qualidade das reconstruções de incidentes e dos exercícios controlados publicados. Relatos úteis conectariam a tarefa delegada, a autoridade relevante, a sequência de ações e a intervenção.

Eles também devem identificar o que os investigadores não puderam recuperar. Uma reconstrução incompleta, mas franca, fornece mais evidências do que a garantia de que uma equipe manteve o controle.

Demonstrações repetidas em diferentes fluxos de trabalho fortaleceriam a confiança de que as práticas de responsabilização funcionam além de um exemplo preparado. Lacunas persistentes reforçariam a preocupação levantada pela SecurityHQ.

O segundo sinal é a evidência de produto que conecta a execução dos agentes à investigação e à contenção. Os compradores devem observar o que os fornecedores expõem aos clientes, em vez de depender de linguagem ampla sobre governança.

Uma demonstração significativa mostraria como um investigador acompanha uma tarefa entre serviços conectados. Também mostraria o que acontece quando um operador autorizado interrompe o fluxo de trabalho.

O momento e o escopo da interrupção importam. Impedir a próxima ação é diferente de reverter alterações concluídas, e as demonstrações de produto devem tornar essa distinção compreensível.

Controles mais claros apoiariam uma delegação mais ampla quando os clientes puderem verificar seu comportamento. Lacunas sem explicação entre registros locais fortaleceriam o argumento a favor de uma autoridade mais restrita.

O terceiro sinal é o progresso de implementação em torno da identidade e autorização de agentes. O caso de uso anunciado pelo NIST para desenvolvimento de software oferece um local concreto para acompanhar resultados técnicos.

Exemplos práticos poderiam esclarecer como a autoridade delegada permanece atribuível à medida que o software transita entre serviços. Seu valor dependerá de as organizações conseguirem aplicar a abordagem a fluxos de trabalho reais.

O progresso reduziria a ambiguidade sobre a identidade técnica, embora deixasse as decisões de propriedade empresarial com a organização. Atrasos deixariam os clientes mais dependentes de abordagens específicas de cada produto.

O próximo parâmetro útil é saber se as organizações conseguem explicar e interromper atividades delegadas em condições realistas. Esse parâmetro conecta os resultados da pesquisa às decisões que os compradores já enfrentam.

Para leitores que avaliam uma implantação, a pesquisa sobre agentes de IA da SecurityHQ oferece um motivo para examinar as evidências por trás das garantias existentes. Comece com um fluxo de trabalho relevante que já tenha um responsável. Peça a esse responsável que explique uma execução concluída usando os registros disponíveis hoje. Acompanhe a instrução, a permissão, a ação e o resultado. Depois, identifique quem pode intervir quando esses elementos deixam de corresponder. Conexões ausentes revelam um problema mais específico do que uma preocupação geral com a segurança da IA. Elas também criam uma discussão mais clara com fornecedores e equipes internas sobre o que precisa melhorar. Antes de conceder autoridade mais ampla, peça uma demonstração que torne visíveis o histórico de ações e o limite de intervenção. Sua organização consegue defender essa explicação quando o resultado é contestado?