{"id":55184,"date":"2026-01-26T10:26:26","date_gmt":"2026-01-26T15:26:26","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=55184"},"modified":"2026-01-26T10:26:26","modified_gmt":"2026-01-26T15:26:26","slug":"top-agentic-ai-risks-2026","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/55184\/","title":{"rendered":"AI agents in your organization: managing the risks"},"content":{"rendered":"

How to protect an organization from the dangerous actions of AI agents it uses? This isn\u2019t just a theoretical what-if anymore \u2014 considering the actual damage autonomous AI can do ranges from providing poor customer service<\/a> to destroying corporate primary databases<\/a>.\u00a0 It\u2019s a question business leaders are currently hammering away at, and government agencies and security experts are racing to provide answers to.<\/p>\n

For CIOs and CISOs, AI agents create a massive governance headache. These agents make decisions, use tools, and process sensitive data without a human in the loop. Consequently, it turns out that many of our standard IT and security tools are unable to keep the AI in check.<\/p>\n

The non-profit OWASP Foundation has released a handy playbook on this very topic. Their comprehensive Top 10 risk list for agentic AI applications<\/a> covers everything from old-school security threats like privilege escalation, to AI-specific headaches like agent memory poisoning. Each risk comes with real-world examples, a breakdown of how it differs from similar threats, and mitigation strategies. In this post, we\u2019ve trimmed down the descriptions and consolidated the defense recommendations.<\/p>\n

\"The<\/a>

The top-10 risks of deploying autonomous AI agents. Source<\/a><\/p><\/div>\n

Agent goal hijack (ASI01)<\/h2>\n

This risk involves manipulating an agent\u2019s tasks or decision-making logic by exploiting the underlying model\u2019s inability to tell the difference between legitimate instructions and external data. Attackers use prompt injection or forged data to reprogram the agent into performing malicious actions. The key difference from a standard prompt injection is that this attack breaks the agent\u2019s multi-step planning process rather than just tricking the model into giving a single bad answer.<\/p>\n

Example: An attacker embeds a hidden instruction into a webpage that, once parsed by the AI agent, triggers an export of the user\u2019s browser history. A vulnerability of this very nature was showcased in a EchoLeak<\/a> study.<\/p>\n

Tool misuse and exploitation (ASI02)<\/h2>\n

This risk crops up when an agent \u2014 driven by ambiguous commands or malicious influence \u2014 uses the legitimate tools it has access to in unsafe or unintended ways. Examples include mass-deleting data, or sending redundant billable API calls. These attacks often play out through complex call chains, allowing them to slip past traditional host-monitoring systems unnoticed.<\/p>\n

Example: A customer support chatbot with access to a financial API is manipulated into processing unauthorized refunds because its access wasn\u2019t restricted to read-only. Another example is data exfiltration via DNS queries, similar to the attack on Amazon Q<\/a>.<\/p>\n

Identity and privilege abuse (ASI03)<\/h2>\n

This vulnerability involves the way permissions are granted and inherited within agentic<\/a> workflows. Attackers exploit existing permissions or cached credentials to escalate privileges or perform actions that the original user wasn\u2019t authorized for. The risk increases when agents use shared identities, or reuse authentication tokens across different security contexts.<\/p>\n

Example: An employee creates an agent that uses their personal credentials to access internal systems. If that agent is then shared with other coworkers, any requests they make to the agent will also be executed with the creator\u2019s elevated permissions.<\/p>\n

Agentic Supply Chain Vulnerabilities (ASI04)<\/h2>\n

Risks arise when using third-party models, tools, or pre-configured agent personas that may be compromised or malicious from the start. What makes this trickier than traditional software is that agentic components are often loaded dynamically, and aren\u2019t known ahead of time. This significantly hikes the risk, especially if the agent is allowed to look for a suitable package on its own. We\u2019re seeing a surge in both typosquatting, where malicious tools in registries mimic the names of popular libraries, and the related slopsquatting<\/a>, where an agent tries to call tools that don\u2019t even exist.<\/p>\n

Example: A coding assistant agent automatically installs a compromised package containing a backdoor, allowing an attacker to scrape CI\/CD tokens and SSH keys right out of the agent\u2019s environment. We\u2019ve already seen documented attempts at destructive attacks targeting AI development agents<\/a> in the wild.<\/p>\n

Unexpected code execution \/ RCE (ASI05)<\/h2>\n

Agentic systems frequently generate and execute code in real-time to knock out tasks, which opens the door for malicious scripts or binaries. Through prompt injection and other techniques, an agent can be talked into running its available tools with dangerous parameters, or executing code provided directly by the attacker.\u00a0 This can escalate into a full container or host compromise, or a sandbox escape \u2014 at which point the attack becomes invisible to standard AI monitoring tools.<\/p>\n

Example: An attacker sends a prompt<\/a> that, under the guise of code testing, tricks a vibecoding<\/a> agent into downloading a command via cURL<\/a> and piping it directly into bash<\/a>.<\/p>\n

Memory and context poisoning (ASI06)<\/h2>\n

Attackers modify the information an agent relies on for continuity, such as dialog history, a RAG knowledge base, or summaries of past task stages. This poisoned context warps the agent\u2019s future reasoning and tool selection. As a result, persistent backdoors can emerge in its logic that survive between sessions. Unlike a one-off injection, this risk causes a long-term impact on the system\u2019s knowledge and behavioral logic.<\/p>\n

Example: An attacker plants false data in an assistant\u2019s memory regarding flight price quotes received from a vendor. Consequently, the agent approves future transactions at a fraudulent rate. An example of false memory implantation was showcased in a demonstration attack on Gemini<\/a>.<\/p>\n

Insecure inter-agent communication (ASI07)<\/h2>\n

In multi-agent systems, coordination occurs via APIs or message buses that still often lack basic encryption, authentication, or integrity checks. Attackers can intercept, spoof, or modify these messages in real time, causing the entire distributed system to glitch out. This vulnerability opens the door for agent-in-the-middle attacks, as well as other classic communication exploits well-known in the world of applied information security: message replays, sender spoofing, and forced protocol downgrades.<\/p>\n

Example: Forcing agents to switch to an unencrypted protocol to inject hidden commands, effectively hijacking the collective decision-making process of the entire agent group.<\/p>\n

Cascading failures (ASI08)<\/h2>\n

This risk describes how a single error \u2014 caused by hallucination, a prompt injection, or any other glitch \u2014 can ripple through and amplify across a chain of autonomous agents. Because these agents hand off tasks to one another without human involvement, a failure in one link can trigger a domino effect leading to a massive meltdown of the entire network. The core issue here is the sheer velocity of the error: it spreads much faster than any human operator can track or stop.<\/p>\n

Example: A compromised scheduler agent pushes out a series of unsafe commands that are automatically executed by downstream agents, leading to a loop of dangerous actions replicated across the entire organization.<\/p>\n

Human\u2013agent trust exploitation (ASI09)<\/h2>\n

Attackers exploit the conversational nature and apparent expertise of agents to manipulate users. Anthropomorphism leads people to place excessive trust in AI recommendations, and approve critical actions without a second thought. The agent acts as a bad advisor, turning the human into the final executor of the attack, which complicates a subsequent forensic investigation.<\/p>\n

Example: A compromised tech support agent references actual ticket numbers to build rapport with a new hire, eventually sweet-talking them into handing over their corporate credentials.<\/p>\n

Rogue agents (ASI10)<\/h2>\n

These are malicious, compromised, or hallucinating agents that veer off their assigned functions, operating stealthily, or acting as parasites within the system. Once control is lost, an agent like that might start self-replicating, pursuing its own hidden agenda, or even colluding with other agents to bypass security measures. The primary threat described by ASI10 is the long-term erosion of a system\u2019s behavioral integrity following an initial breach or anomaly.<\/p>\n

Example: The most infamous case involves an autonomous Replit development agent<\/a> that went rogue, deleted the respective company\u2019s primary customer database, and then completely fabricated its contents to make it look like the glitch had been fixed.<\/p>\n

Mitigating risks in agentic AI systems<\/h2>\n

While the probabilistic nature of LLM generation and the lack of separation between instructions and data channels make bulletproof security impossible, a rigorous set of controls \u2014 approximating a Zero Trust strategy \u2014 can significantly limit the damage when things go awry. Here are the most critical measures.<\/p>\n

Enforce the principles of both least autonomy and least privilege.<\/strong> Limit the autonomy of AI agents by assigning tasks with strictly defined guardrails. Ensure they only have access to the specific tools, APIs, and corporate data necessary for their mission. Dial permissions down to the absolute minimum where appropriate \u2014 for example, sticking to read-only mode.<\/p>\n

Use short-lived credentials.<\/strong> Issue temporary tokens and API keys with a limited scope for each specific task. This prevents an attacker from reusing credentials if they manage to compromise an agent.<\/p>\n

Mandatory human-in-the-loop<\/strong> for critical operations. Require explicit human confirmation for any irreversible or high-risk actions, such as authorizing financial transfers or mass-deleting data.<\/p>\n

Execution isolation and traffic control.<\/strong> Run code and tools in isolated environments (containers or sandboxes) with strict allowlists of tools and network connections to prevent unauthorized outbound calls.<\/p>\n

Policy enforcement.<\/strong> Deploy intent gates to vet an agent\u2019s plans and arguments against rigid security rules before they ever go live.<\/p>\n

Input and output validation and sanitization.<\/strong> Use specialized filters and validation schemes to check all prompts and model responses for injections and malicious content. This needs to happen at every single stage of data processing and whenever data is passed between agents.<\/p>\n

Continuous secure logging.<\/strong> Record every agent action and inter-agent message in immutable logs. These records would be needed for any future auditing and forensic investigations.<\/p>\n

Behavioral monitoring and watchdog agents.<\/strong> Deploy automated systems to sniff out anomalies, such as a sudden spike in API calls, self-replication attempts, or an agent suddenly pivoting away from its core goals. This approach overlaps heavily with the monitoring required to catch sophisticated living-off-the-land network attacks. Consequently, organizations that have introduced XDR<\/a> and are crunching telemetry in a SIEM<\/a> will have a head start here \u2014 they\u2019ll find it much easier to keep their AI agents on a short leash.<\/p>\n

Supply chain control and SBOMs (software bills of materials).<\/strong> Only use vetted tools and models from trusted registries. When developing software, sign every component, pin dependency versions, and double-check every update.<\/p>\n

Static and dynamic analysis of generated code.<\/strong> Scan every line of code an agent writes for vulnerabilities before running. Ban the use of dangerous functions like eval() completely. These last two tips should already be part of a standard DevSecOps workflow, and they needed to be extended to all code written by AI agents. Doing this manually is next to impossible, so automation tools, like those found in Kaspersky Cloud Workload Security, are recommended here.<\/p>\n

Securing inter-agent communications.<\/strong> Ensure mutual authentication and encryption across all communication channels between agents. Use digital signatures to verify message integrity.<\/p>\n

\u00a0Kill switches.<\/strong> Come up with ways to instantly lock down agents or specific tools the moment anomalous behavior is detected.<\/p>\n

Using UI for trust calibration.<\/strong> Use visual risk indicators and confidence level alerts to reduce the risk of humans blindly trusting AI.<\/p>\n

User training.<\/strong> Systematically train employees on the operational realities of AI-powered systems. Use examples tailored to their actual job roles to break down AI-specific risks. Given how fast this field moves, a once-a-year compliance video won\u2019t cut it \u2014 such training should be refreshed several times a year.<\/p>\n

For SOC analysts, we also recommend the Kaspersky Expert Training: Large Language Models Security<\/a> course, which covers the main threats to LLMs, and defensive strategies to counter them. The course would also be useful for developers and AI architects working on LLM implementations.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

The top-10 risks of deploying autonomous AI agents, and our mitigation recommendations. <\/p>\n","protected":false},"author":2722,"featured_media":55185,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3051],"tags":[1140,4642,1876],"class_list":{"0":"post-55184","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-ai","10":"tag-llm","11":"tag-machine-learning"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/top-agentic-ai-risks-2026\/55184\/"},{"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":"es","url":"https:\/\/www.kaspersky.es\/blog\/top-agentic-ai-risks-2026\/31801\/"},{"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":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/top-agentic-ai-risks-2026\/23537\/"},{"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\/blog\/tag\/ai\/","name":"AI"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/55184","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=55184"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/55184\/revisions"}],"predecessor-version":[{"id":55187,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/55184\/revisions\/55187"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/55185"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=55184"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=55184"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=55184"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}