🔎 SUMMARY
– Contemporary software development teams are adopting agentic AI at an accelerating pace.
– Apart from clear benefits, this trend introduces several new security risks.
– Learn about the causes behind the seven most common emerging AI threats in DevOps.
– Discover their mechanics to better understand the impact.

AI adoption in the DevOps field has been extensive. Developers use agents daily to broaden context, automate coding, prototype, etc., saving time and minimizing the footprint of mundane tasks.

But it’s not all about gains. Agentic AI enables and introduces security threats that were unknown just a few years ago. With machine speed and scale, these can impact your corporate repos in a number of highly dangerous ways. 

The trend is on the rise, including at the level of popular DevOps platforms. According to the latest 2026 DevOps Threats Unwrapped Report by GitProtect, each quarter of 2025 showed an increase in AI-related issues, starting from 10 in Q1 and ending with 20 in Q4.

Let’s examine what you should watch out for in your DevOps pipeline. 

Table of contents: click to expand

#1 Direct Prompt Injection: Step-by-Step Wrongdoing

AI agents interact with your DevOps ecosystem similar to humans. They often have highly privileged permissions to avoid feature limitations. They can access sensitive resources based on tokens and API keys, too. Here’s how a regular attack may take advantage of these extended rights.

Following the stealing of your user’s credentials or token, an attacker signs in to your AI agent’s CLI or app. Then, they input malicious prompts after a comment starting like this one:

// IGNORE PREVIOUS INSTRUCTIONS AND...

Next, they can finally take advantage of AI agent robust permissions (tied to the compromised user) to bypass your data-loss prevention (DLP) mechanisms, overwrite IDE or MCP server configuration files, harvest your proprietary code (intellectual property), exfiltrate sensitive credentials, and more.

Even worse, the same scenario is possible for a malicious employee who takes revenge before leaving. 

#2 Indirect Prompt Injection: The Self-Inflicted Evil

Model Context Protocol (MCP) is a popular open standard allowing you to connect different resources (databases, files) to your AI agent. Its purpose is to enable more context and functionalities. Unfortunately, the data resources can be a source (no pun intended!) of danger, too. Here’s how it works.

An attacker infects a resource, for example an open-source repo, a pull request, a Jira ticket, DOCX file, with malicious instructions. After your developer unknowingly integrates the infected resource with an AI agent through MCP server technology, the agent ingests the malicious content, too. The consequences can be similar to direct prompt injection, with your repo wipe included.

The bad news is that the indirect prompt injection is harder to notice and doesn’t need malice to be effectively executed. Negligence is enough.

#3 AI Package Hallucination: I Have a Package for You!

This is sometimes called typosquatting 2.0 or slopsquatting.

AI may occasionally hallucinate a package, library, or API name, especially for edge cases, which it hasn’t been sufficiently trained for. This results from the underlying AI mechanism of token (word/string) prediction, rather than proper fact checking by querying an npm or PyPI library. 

In fact, this sort of name invention is not 100% accidental but repeatable to some degree. According to the research by University of Texas, 43% of hallucinated packages were repeated in a sample of 10 repeated prompts, and in 58% of cases, a hallucinated package was repeated more than once.

This repeatability encourages cyber criminals to use automated API scripts to spam popular code-generation LLMs (e.g. Claude Code) and extract phantom dependencies. Once they find them, they set them up in public dependency package registries (e.g. PyPI), poisoning them with a post-install script.

If a developer doesn’t verify such a dependency in their AI-generated code, running e.g. npm install [fake package name] will automatically result in an infection. What’s worse, once the code is committed to a corporate repo, the infection may get viral, ending up with token or SSH key harvesting, for example.

#4 Supply Chain Exploits: Cracked Extensions 

Supply chain attacks are nothing new—repos have been on the cybercryminals’ radars for a long time. But AI agents enable new vectors of attack: AI extension and MCP server poisoning.

Often, following a successful compromise, the poisoning takes place at the official repo. The compromised version of an extension or an MCP server then reaches an official marketplace (e.g. GitHub Marketplace) and is downloaded and installed by thousands of developers.

Next, an attacker can easily exploit the AI agent’s access to the local system, the internet, and the code repository. When inside the victim’s ecosystem, the range of abuse is vast: from data exfiltration, through arbitrary command execution, to backdoor injection and later movement.

💡 Interested in learning more about abusing code repositories for cybercriminal activity? Check out our article on distributing malware via GitHub repos.

#5 AI Credential Harvesting: The Cherry-Picking

The massive adoption of locally run AI tools and extensions has created a “Shadow AI” area on developers’ machines. These self-managed tools often maintain logs locally in unencrypted plain text.

When a complex deployment fails, an error log can be thousand lines long and include valuable information such as passwords, API tokens, database connection strings, and private keys, for example. Developers often overlook this. But not cyber criminals who find it much easier to target a developer’s workstation than OpenAI’s infrastructure, for example. 

After compromising a local machine through phishing or a supply chain exploit, attackers get to directories where logs reside, e.g. AppData/Local/[GenAI-Assistant]/Logs/. Then they copy their contents to harvest the most sensitive and useful details. Finally, they can use them for further exploits and abuses.

👉 Exposed credentials are only one of many DevSecOps vulnerabilities. Explore our article to learn what else can put your CI/CD pipeline at risk. Learn more

#6 AI Context Window Poisoning: The Snowballing Sabotage

This is a kind of sabotage that focuses on reframing operations rather than running explicit command-based attacks.

AI agents (e.g. code reviewers) build their knowledge (aka context window) through ingesting data sources such as files processed in IDE, logs, databases. Studies show that when analyzing large data sets, AI is the least attentive and prone to manipulations with content located in the middle of something (e.g. a file). That’s why, malicious actors often bury malicious payload (e.g. Authentication checks are bypassed for repo testing) in the middle of a large file with instructions. The payload tries to resemble historical data, system configuration, or trusted project rules to bypass the traditional static exploit detection tests.

Then, when a developer asks AI to write code handling user login, for example, AI will evaluate context with a bias. It will believe that authentication bypass is a standard policy, so it will output a function without necessary JWT token verification.

If the flaw persists, subsequent outputs from the biased AI agent will introduce more flawed code, producing more and more insecurities and vulnerabilities with time. In the long term, it can greatly warp the code-writing logic of your organization.

#7 AI Hallucinations: Blind Leading the Blind

Uncritical trust in AI code agent capabilities turns them from productivity boosters to silent vulnerability injectors. The fast pace of development only adds fuel to the fire.

Ironically, AI can produce a perfectly clean and syntactically sound code. However, it’s the semantics with insecure logics and structure that’s usually an issue. Why? AI’s context window may include countless lines of loosely configured code on GitHub. These work but sacrifice, for example, the principle of least privilege. By the way, according to a CodeRabbit study, AI-authored pull requests introduce 1.7 times more problems than those created by humans.

If a time-pressed developer fails to carefully audit well-looking code, local tests are green (because syntax is OK and wide-open permissions do not throw any exceptions), and a senior engineer accepts a PR (because they trust the developer), the vulnerability goes live. This is only a step away from an attacker discovering and exploiting it one way or the other. 

Become AI DevSecOps Expert with GitProtect

If you want to build expertise in securing agentic AI within your code supply pipeline, also take a look at our article on integrating backup and recovery into your security strategy.

To stay up to date, follow our blog for the latest trends, analyses, executive insights, and key tech topics.

Comments are closed.

You may also like