{"id":24687,"date":"2026-02-02T09:00:58","date_gmt":"2026-02-02T12:00:58","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=24687"},"modified":"2026-01-30T12:04:30","modified_gmt":"2026-01-30T15:04:30","slug":"top-agentic-ai-risks-2026","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/top-agentic-ai-risks-2026\/24687\/","title":{"rendered":"Agentes de IA na sua organiza\u00e7\u00e3o: gerenciamento de riscos"},"content":{"rendered":"

Como proteger uma organiza\u00e7\u00e3o contra a\u00e7\u00f5es perigosas de agentes de IA que ela utiliza? Isso j\u00e1 n\u00e3o \u00e9 apenas um exerc\u00edcio te\u00f3rico, considerando que os danos reais que a IA aut\u00f4noma pode causar v\u00e3o desde oferecer um atendimento ao cliente de baixa qualidade<\/a> at\u00e9 destruir bancos de dados corporativos principais<\/a>.\u00a0 \u00c9 uma quest\u00e3o na qual os l\u00edderes empresariais est\u00e3o se concentrando intensamente atualmente, enquanto ag\u00eancias governamentais e especialistas em seguran\u00e7a correm para fornecer respostas.<\/p>\n

Para CIOs e CISOs, os agentes de IA criam um enorme desafio de governan\u00e7a. Esses agentes tomam decis\u00f5es, utilizam ferramentas e processam dados sens\u00edveis sem a participa\u00e7\u00e3o humana no processo. Isso faz com que muitas das nossas ferramentas tradicionais de TI e seguran\u00e7a n\u00e3o sejam suficientes para controlar a IA.<\/p>\n

A organiza\u00e7\u00e3o sem fins lucrativos OWASP Foundation lan\u00e7ou um guia pr\u00e1tico exatamente sobre esse tema. Sua abrangente lista dos 10 principais riscos para aplica\u00e7\u00f5es de IA ag\u00eantica<\/a> abrange desde amea\u00e7as tradicionais de seguran\u00e7a, como escalonamento de privil\u00e9gios, at\u00e9 problemas espec\u00edficos de IA, como envenenamento da mem\u00f3ria do agente. Cada risco \u00e9 acompanhado de exemplos do mundo real, de uma an\u00e1lise comparativa em rela\u00e7\u00e3o a amea\u00e7as semelhantes e de estrat\u00e9gias de mitiga\u00e7\u00e3o. Neste post, resumimos as descri\u00e7\u00f5es e consolidamos as recomenda\u00e7\u00f5es de defesa.<\/p>\n

\"Os

Os 10 principais riscos da implementa\u00e7\u00e3o de agentes de IA aut\u00f4nomos. Source<\/a><\/p><\/div>\n

Sequestro de objetivo do agente (ASI01)<\/h2>\n

Esse risco consiste na manipula\u00e7\u00e3o das tarefas ou da l\u00f3gica de tomada de decis\u00e3o de um agente, explorando a incapacidade do modelo subjacente de distinguir entre instru\u00e7\u00f5es leg\u00edtimas e dados externos. Invasores usam inje\u00e7\u00e3o de prompts ou dados forjados para reprogramar o agente e faz\u00ea-lo executar a\u00e7\u00f5es maliciosas. A diferen\u00e7a fundamental em rela\u00e7\u00e3o \u00e0 inje\u00e7\u00e3o de prompt tradicional \u00e9 que esse tipo de ataque compromete o processo de planejamento em m\u00faltiplas etapas do agente, em vez de apenas levar o modelo a produzir uma \u00fanica resposta incorreta.<\/p>\n

Exemplo: um invasor incorpora uma instru\u00e7\u00e3o oculta em uma p\u00e1gina da Web que, ao ser interpretada pelo agente de IA, aciona a exporta\u00e7\u00e3o do hist\u00f3rico de navega\u00e7\u00e3o do usu\u00e1rio. Uma vulnerabilidade dessa natureza foi demonstrada no estudo EchoLeak<\/a>.<\/p>\n

Uso indevido e explora\u00e7\u00e3o de ferramentas (ASI02)<\/h2>\n

Esse risco surge quando um agente, orientado por comandos amb\u00edguos ou sob influ\u00eancia maliciosa, utiliza de forma insegura ou n\u00e3o intencional as ferramentas leg\u00edtimas \u00e0s quais tem acesso. Entre os exemplos est\u00e3o a exclus\u00e3o em massa de dados e o envio de chamadas redundantes a APIs com cobran\u00e7a por uso. Esses ataques costumam ocorrer por meio de cadeias complexas de chamadas, o que permite que passem despercebidos pelos sistemas tradicionais de monitoramento de hosts.<\/p>\n

Exemplo: um chatbot de atendimento ao cliente com acesso a uma API financeira \u00e9 manipulado para processar reembolsos n\u00e3o autorizados, pois seu acesso n\u00e3o estava restrito ao modo somente leitura. Outro exemplo \u00e9 a exfiltra\u00e7\u00e3o de dados por meio de consultas DNS, de forma semelhante ao ataque ao Amazon Q<\/a>.<\/p>\n

Abuso de identidade e privil\u00e9gios (ASI03)<\/h2>\n

Essa vulnerabilidade envolve a forma como permiss\u00f5es s\u00e3o concedidas e herdadas em fluxos de trabalho ag\u00eanticos<\/a>. Invasores exploram permiss\u00f5es existentes ou credenciais em cache para escalar privil\u00e9gios ou executar a\u00e7\u00f5es para as quais o usu\u00e1rio original n\u00e3o tinha autoriza\u00e7\u00e3o. O risco se agrava quando agentes utilizam identidades compartilhadas ou reutilizam tokens de autentica\u00e7\u00e3o em diferentes contextos de seguran\u00e7a.<\/p>\n

Exemplo: um funcion\u00e1rio cria um agente que utiliza suas credenciais pessoais para acessar sistemas internos. Se esse agente for posteriormente compartilhado com outros colegas, todas as solicita\u00e7\u00f5es feitas a ele tamb\u00e9m ser\u00e3o executadas com os privil\u00e9gios elevados do criador.<\/p>\n

Vulnerabilidades na cadeia de suprimentos ag\u00eantica (ASI04)<\/h2>\n

Os riscos surgem quando s\u00e3o utilizados modelos, ferramentas ou personas de agentes pr\u00e9-configurados de terceiros que podem j\u00e1 estar comprometidos ou ser maliciosos desde a origem. O que torna esse cen\u00e1rio mais complexo do que no software tradicional \u00e9 o fato de que componentes ag\u00eanticos costumam ser carregados de forma din\u00e2mica e nem sempre s\u00e3o conhecidos previamente. Isso amplia significativamente o risco, sobretudo quando o agente tem permiss\u00e3o para buscar, por conta pr\u00f3pria, um pacote considerado adequado. Observa-se um aumento tanto de ataques de typosquatting, em que ferramentas maliciosas em reposit\u00f3rios imitam os nomes de bibliotecas populares, quanto do fen\u00f4meno relacionado conhecido como slopsquatting<\/a>, no qual um agente tenta chamar ferramentas que sequer existem.<\/p>\n

Exemplo: um agente assistente de codifica\u00e7\u00e3o instala automaticamente um pacote comprometido contendo uma backdoor, permitindo que um invasor extraia tokens de CI\/CD e chaves SSH diretamente do ambiente do agente. J\u00e1 h\u00e1 registros documentados de ataques destrutivos direcionados a agentes de desenvolvimento de IA<\/a> ocorrendo em ambientes reais.<\/p>\n

Execu\u00e7\u00e3o inesperada de c\u00f3digo\/RCE (ASI05)<\/h2>\n

Sistemas ag\u00eanticos frequentemente geram e executam c\u00f3digo em tempo real para realizar tarefas, o que abre espa\u00e7o para a execu\u00e7\u00e3o de scripts ou bin\u00e1rios maliciosos. Por meio de inje\u00e7\u00e3o de prompt e outras t\u00e9cnicas, um agente pode ser induzido a executar as ferramentas \u00e0s quais tem acesso com par\u00e2metros perigosos ou a executar c\u00f3digo fornecido diretamente por um invasor.\u00a0 Isso pode evoluir para o comprometimento completo de um cont\u00eainer ou do host, ou para uma fuga de sandbox, momento a partir do qual o ataque passa a ser invis\u00edvel \u00e0s ferramentas padr\u00e3o de monitoramento de IA.<\/p>\n

Exemplo: um invasor envia um prompt<\/a> que, sob o pretexto de testes de c\u00f3digo, engana um agente de vibecoding<\/a> para baixar um comando via cURL<\/a> e direcion\u00e1-lo diretamente para o bash<\/a>.<\/p>\n

Envenenamento de mem\u00f3ria e de contexto (ASI06)<\/h2>\n

Invasores modificam as informa\u00e7\u00f5es das quais o agente depende para manter a continuidade, como o hist\u00f3rico de di\u00e1logos, uma base de conhecimento de RAG ou resumos de etapas anteriores de tarefas. Esse contexto envenenado distorce o racioc\u00ednio futuro do agente e a sele\u00e7\u00e3o de ferramentas. Como resultado, backdoors persistentes podem surgir na l\u00f3gica do agente e sobreviver entre sess\u00f5es. Diferentemente de uma inje\u00e7\u00e3o pontual, esse risco causa um impacto de longo prazo no conhecimento e na l\u00f3gica comportamental do sistema.<\/p>\n

Exemplo: um invasor insere dados falsos na mem\u00f3ria de um assistente sobre cota\u00e7\u00f5es de pre\u00e7os de passagens a\u00e9reas fornecidas por um vendedor. Como consequ\u00eancia, o agente aprova transa\u00e7\u00f5es futuras a um valor fraudulento. Um exemplo de implanta\u00e7\u00e3o de mem\u00f3ria falsa foi demonstrado em um ataque prova de conceito contra o Gemini<\/a>.<\/p>\n

Comunica\u00e7\u00e3o insegura entre agentes (ASI07)<\/h2>\n

Em sistemas multiagente, a coordena\u00e7\u00e3o ocorre por meio de APIs ou barramentos de mensagens que ainda frequentemente carecem de criptografia, autentica\u00e7\u00e3o ou verifica\u00e7\u00f5es de integridade b\u00e1sicas. Invasores podem interceptar, falsificar ou modificar essas mensagens em tempo real, fazendo com que todo o sistema distribu\u00eddo apresente falhas generalizadas. Essa vulnerabilidade abre espa\u00e7o para ataques do tipo \u201cagent-in-the-middle\u201d, al\u00e9m de outras t\u00e9cnicas cl\u00e1ssicas de explora\u00e7\u00e3o de comunica\u00e7\u00e3o amplamente conhecidas na seguran\u00e7a da informa\u00e7\u00e3o aplicada, como repeti\u00e7\u00e3o de mensagens, falsifica\u00e7\u00e3o do remetente e degrada\u00e7\u00e3o for\u00e7ada de protocolos.<\/p>\n

Exemplo: for\u00e7ar os agentes a mudar para um protocolo n\u00e3o criptografado para injetar comandos ocultos, sequestrando efetivamente o processo coletivo de tomada de decis\u00e3o de todo o grupo de agentes.<\/p>\n

Falhas em cascata (ASI08)<\/h2>\n

Esse risco descreve como um \u00fanico erro, causado por alucina\u00e7\u00e3o, inje\u00e7\u00e3o de prompt ou qualquer outra falha, pode se propagar e se amplificar ao longo de uma cadeia de agentes aut\u00f4nomos. Como esses agentes repassam tarefas uns aos outros sem interven\u00e7\u00e3o humana, uma falha em um \u00fanico elo pode desencadear um efeito domin\u00f3 que leva a um colapso generalizado de toda a rede. O problema central est\u00e1 na velocidade com que o erro se propaga: espalha-se muito mais r\u00e1pido do que qualquer operador humano \u00e9 capaz de acompanhar ou interromper.<\/p>\n

Exemplo: um agente de agendamento comprometido distribui uma s\u00e9rie de comandos inseguros que s\u00e3o automaticamente executados por agentes subsequentes, gerando um ciclo de a\u00e7\u00f5es perigosas replicadas por toda a organiza\u00e7\u00e3o.<\/p>\n

Explora\u00e7\u00e3o da confian\u00e7a humano\u2013agente (ASI09)<\/h2>\n

Invasores exploram a natureza conversacional e a aparente especializa\u00e7\u00e3o dos agentes para manipular usu\u00e1rios. O antropomorfismo leva as pessoas a depositar confian\u00e7a excessiva nas recomenda\u00e7\u00f5es da IA e a aprovar a\u00e7\u00f5es cr\u00edticas sem pensar duas vezes. O agente atua como um mau conselheiro, transformando o ser humano no executor final do ataque, o que dificulta investiga\u00e7\u00f5es forenses posteriores.<\/p>\n

Exemplo: um agente de suporte t\u00e9cnico comprometido faz refer\u00eancia a n\u00fameros reais de chamados para criar empatia com um novo funcion\u00e1rio e, gradualmente, persuadi-lo a entregar suas credenciais corporativas.<\/p>\n

Agentes fora de controle (ASI10)<\/h2>\n

Trata-se de agentes maliciosos, comprometidos ou em estado de alucina\u00e7\u00e3o que se desviam de suas fun\u00e7\u00f5es atribu\u00eddas, operam de forma furtiva ou atuam como parasitas dentro do sistema. Uma vez perdido o controle, um agente desse tipo pode passar a se autorreplicar, perseguir uma agenda oculta pr\u00f3pria ou at\u00e9 mesmo colaborar com outros agentes para contornar mecanismos de seguran\u00e7a. A principal amea\u00e7a descrita pelo ASI10 \u00e9 a eros\u00e3o de longo prazo da integridade comportamental do sistema ap\u00f3s uma viola\u00e7\u00e3o inicial ou uma anomalia.<\/p>\n

Exemplo: o caso mais not\u00f3rio envolve um agente aut\u00f4nomo de desenvolvimento da Replit<\/a> que saiu do controle, apagou o banco de dados principal de clientes da empresa e, em seguida, fabricou completamente seu conte\u00fado para aparentar que a falha havia sido corrigida.<\/p>\n

Mitiga\u00e7\u00e3o de riscos em sistemas de IA ag\u00eantica<\/h2>\n

Embora a natureza probabil\u00edstica da gera\u00e7\u00e3o por LLMs e a aus\u00eancia de separa\u00e7\u00e3o clara entre canais de instru\u00e7\u00f5es e de dados tornem invi\u00e1vel uma seguran\u00e7a totalmente \u00e0 prova de falhas, um conjunto rigoroso de controles, aproximando-se de uma estrat\u00e9gia de Zero Trust, pode limitar significativamente os danos quando algo sai do previsto. Aqui est\u00e3o as medidas mais cr\u00edticas.<\/p>\n

Aplicar os princ\u00edpios do menor grau de autonomia e do menor privil\u00e9gio.<\/strong> Limite a autonomia dos agentes de IA atribuindo tarefas com salvaguardas rigorosamente definidas. Garanta que eles tenham acesso apenas \u00e0s ferramentas, APIs e aos dados corporativos estritamente necess\u00e1rios para cumprir sua miss\u00e3o. Sempre que aplic\u00e1vel, reduza as permiss\u00f5es ao m\u00ednimo absoluto, por exemplo, restringindo o acesso ao modo somente leitura.<\/p>\n

Utilizar credenciais de curta dura\u00e7\u00e3o.<\/strong> Emita tokens tempor\u00e1rios e chaves de API com escopo limitado para cada tarefa espec\u00edfica. Isso impede que um invasor reutilize credenciais caso consiga comprometer um agente.<\/p>\n

Interven\u00e7\u00e3o humana obrigat\u00f3ria<\/strong> para opera\u00e7\u00f5es cr\u00edticas. Exija confirma\u00e7\u00e3o humana expl\u00edcita para qualquer a\u00e7\u00e3o irrevers\u00edvel ou de alto risco, como autorizar transfer\u00eancias financeiras ou excluir dados em massa.<\/p>\n

Isolamento de execu\u00e7\u00e3o e controle de tr\u00e1fego.<\/strong> Execute c\u00f3digos e ferramentas em ambientes isolados, como cont\u00eaineres ou sandboxes, com listas de permiss\u00f5es estritas de ferramentas e conex\u00f5es de rede, a fim de impedir chamadas de sa\u00edda n\u00e3o autorizadas.<\/p>\n

Aplica\u00e7\u00e3o de pol\u00edticas.<\/strong> Implemente mecanismos de valida\u00e7\u00e3o de inten\u00e7\u00e3o para avaliar os planos e argumentos de um agente em rela\u00e7\u00e3o a regras de seguran\u00e7a r\u00edgidas antes que eles entrem em produ\u00e7\u00e3o.<\/p>\n

Valida\u00e7\u00e3o e sanitiza\u00e7\u00e3o de entradas e sa\u00eddas.<\/strong> Utilize filtros especializados e esquemas de valida\u00e7\u00e3o para verificar todos os prompts e respostas do modelo em busca de inje\u00e7\u00f5es e conte\u00fado malicioso. Esse processo deve ocorrer em todas as etapas do processamento de dados e sempre que informa\u00e7\u00f5es forem transferidas entre agentes.<\/p>\n

Registro seguro cont\u00ednuo.<\/strong> Registre todas as a\u00e7\u00f5es dos agentes e as mensagens trocadas entre eles em logs imut\u00e1veis. Esses registros seriam necess\u00e1rios para futuras auditorias e investiga\u00e7\u00f5es forenses.<\/p>\n

Monitoramento comportamental e agentes de vigil\u00e2ncia.<\/strong> Implemente sistemas automatizados para detectar anomalias, como picos repentinos de chamadas a APIs, tentativas de autorreplica\u00e7\u00e3o ou um agente desviando subitamente de seus objetivos principais. Essa abordagem se sobrep\u00f5e, em grande medida, ao monitoramento necess\u00e1rio para detectar ataques de rede sofisticados do tipo \u201cliving-off-the-land\u201d. Como consequ\u00eancia, organiza\u00e7\u00f5es que j\u00e1 adotaram solu\u00e7\u00f5es de XDR<\/a> e est\u00e3o processando telemetria em um SIEM<\/a> ter\u00e3o uma vantagem inicial significativa, pois encontrar\u00e3o muito mais facilidade para manter seus agentes de IA sob controle rigoroso.<\/p>\n

Controle da cadeia de suprimentos e SBOMs (listas de materiais de software).<\/strong> Utilize apenas ferramentas e modelos previamente validados, provenientes de reposit\u00f3rios confi\u00e1veis. No desenvolvimento de software, assine todos os componentes, fixe vers\u00f5es de depend\u00eancias e revise cuidadosamente cada atualiza\u00e7\u00e3o.<\/p>\n

An\u00e1lise est\u00e1tica e din\u00e2mica do c\u00f3digo gerado.<\/strong> Verifique cada linha de c\u00f3digo que um agente escrever em busca de vulnerabilidades antes da execu\u00e7\u00e3o. Pro\u00edba completamente o uso de fun\u00e7\u00f5es perigosas, como eval(). Essas duas \u00faltimas recomenda\u00e7\u00f5es j\u00e1 deveriam fazer parte de um fluxo padr\u00e3o de DevSecOps e precisam ser estendidas a todo c\u00f3digo gerado por agentes de IA. Fazer isso manualmente \u00e9 praticamente invi\u00e1vel; por isso, recomenda-se o uso de ferramentas de automa\u00e7\u00e3o, como as dispon\u00edveis no Kaspersky Cloud Workload Security.<\/p>\n

Prote\u00e7\u00e3o das comunica\u00e7\u00f5es entre agentes.<\/strong> Garanta autentica\u00e7\u00e3o m\u00fatua e criptografia em todos os canais de comunica\u00e7\u00e3o entre agentes. Utilize assinaturas digitais para verificar a integridade das mensagens.<\/p>\n

\u00a0Bot\u00f5es de emerg\u00eancia.<\/strong> Crie mecanismos para bloquear imediatamente agentes ou ferramentas espec\u00edficas no momento em que um comportamento an\u00f4malo for detectado.<\/p>\n

Uso de interfaces para calibra\u00e7\u00e3o de confian\u00e7a.<\/strong> Use indicadores visuais de risco e alertas de n\u00edvel de confian\u00e7a para reduzir o risco de as pessoas confiarem cegamente na IA.<\/p>\n

Treinamento de usu\u00e1rios.<\/strong> Capacite sistematicamente os colaboradores sobre as realidades operacionais de sistemas baseados em IA. Utilize exemplos alinhados \u00e0s fun\u00e7\u00f5es reais de cada cargo para explicitar riscos espec\u00edficos relacionados \u00e0 IA. Dada a velocidade com que esse campo evolui, um treinamento anual de compliance n\u00e3o \u00e9 suficiente; essas capacita\u00e7\u00f5es devem ser atualizadas v\u00e1rias vezes ao ano.<\/p>\n

Para analistas de SOC, tamb\u00e9m recomendamos o curso Kaspersky Expert Training: Large Language Models Security<\/a>, que aborda as principais amea\u00e7as aos LLMs e as estrat\u00e9gias defensivas para mitig\u00e1-las. O curso tamb\u00e9m \u00e9 relevante para desenvolvedores e arquitetos de IA que atuam na implementa\u00e7\u00e3o de LLMs.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Os 10 principais riscos associados \u00e0 implementa\u00e7\u00e3o de agentes de IA aut\u00f4nomos e nossas recomenda\u00e7\u00f5es para mitig\u00e1-los.<\/p>\n","protected":false},"author":2722,"featured_media":24688,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1119,1655],"tags":[1382,1342,3376,40],"class_list":{"0":"post-24687","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-aprendizado-de-maquina","10":"tag-ia","11":"tag-llm","12":"tag-seguranca"},"hreflang":[{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/top-agentic-ai-risks-2026\/24687\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/top-agentic-ai-risks-2026\/30110\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/25171\/"},{"hreflang":"ar","url":"https:\/\/me.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/13142\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/top-agentic-ai-risks-2026\/29988\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/28936\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/top-agentic-ai-risks-2026\/41213\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/top-agentic-ai-risks-2026\/14222\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/55184\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/top-agentic-ai-risks-2026\/33133\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/top-agentic-ai-risks-2026\/30201\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/top-agentic-ai-risks-2026\/35872\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/top-agentic-ai-risks-2026\/35527\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.br\/blog\/tag\/ia\/","name":"IA"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24687","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/comments?post=24687"}],"version-history":[{"count":5,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24687\/revisions"}],"predecessor-version":[{"id":24694,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24687\/revisions\/24694"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media\/24688"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media?parent=24687"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/categories?post=24687"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/tags?post=24687"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}