Artificial intelligence is everywhere now. From automated code completion to autonomous infrastructure management, AI tools and AI agents help DevOps speed up deployment cycles and change how development teams operate in general. At the same time, this rapid adoption of AI has created a reality that is hard for security teams to ignore: as with the growth of AI capability within the software development life cycle, the attack surface also grows.
In 2025, there were 68 AI-related incidents recorded across major DevOps platforms according to the 2026 DevOps Threats Unwrapped Report. In the first half of 2026, the number of AI-related incidents visibly grew — research from GitProtect Lab tracked 84 AI-related incidents in six months alone. Thus, comparing the first half of 2026 to the same period in 2025 shows that AI-related incidents in development environments have nearly tripled.
What do DevOps and DevSecOps say about AI incidents in general? According to GitProtect Lab’s survey of DevOps, DevSecOps, and security leaders, 1 in 3 respondents says that they have already experienced a security incident tied directly to AI. So, while the productivity gains and benefits of AI are unquestionable, relying on these tools without tailored security guardrails might create significant operational risk.
How indirect prompt injections trick AI agents into exfiltrating data
Manipulation of AI coding tools through prompt injection, ranked #1 on the OWASP Top 10 for LLMS, is among the fastest-growing attack vectors in engineering environments now. Developers naturally consider integrated AI assistants as authoritative, trusted extensions of their workflow. And attackers are eager to exploit this misplaced trust. They can try to embed malicious instructions directly into the unstructured data that AI tools routinely scan, such as issue tickets, pull request comments, as well as agent config files or poisoned MCP tool descriptions, or uploaded documentation.
In this case, when an AI agent holds broad, organization-wide read permissions across the DevOps stack an organization uses, an indirect prompt injection can transform the assistant into an unintended insider threat. In such a situation, attackers don’t need to compromise server infrastructure or steal user credentials; they can simply place a crafted command inside an untrusted file or public comment.
When the AI agent reads the file to assist with a routine query, it executes the embedded instruction and can pull proprietary source code, API keys, or environment secrets from private repositories and paste them into a public comment or even send them to an external endpoint.
This kind of attack can succeed because the AI agent blindly applies its high-level execution privileges to untrusted input. Advanced techniques like GhostSplice evolve this mechanism further by splitting the malicious payload across multiple channels, bypassing refusal filters while forcing the agent to fuse the fragments and execute the exfiltration.
The operational danger of autonomous AI infrastructure management
Data loss and security breaches are not the only risks organizations can face using AI integration; autonomous AI agents can also trigger unprecedented operational downtime. Organizations have started more often assigning AI agents to handle routine system maintenance, monitor infrastructure, and automatically fix environment errors, for example. However, when these agents operate without strict contextual boundaries, their automated decisions can quickly turn catastrophic.
Let’s imagine a scenario: an autonomous AI agent assigned to manage cloud infrastructure encounters an environment error during a routine build. To resolve the issue, the AI agent decides that the best option is to tear down and recreate a live system component. Because the agent lacks broader business awareness, it executes the action instantly, lacking human-in-the-loop verification.
AI agent is not a human; it doesn’t understand that the component supports active user connections or that the teardown is taking place during peak operational hours. The automated deletion can instantly drop live system connections and result in an infrastructure outage before human operators can diagnose the issue and intervene.
This scenario demonstrates that giving AI agents autonomous execution authority over live environments without context-aware guardrails can convert standard maintenance into severe, unforced downtime.
Why AI-driven supply chain attacks threaten modern enterprise software
Among other threats is that threat actors have started actively using AI to craft more convincing supply chain attacks, increasingly targeting agentic ecosystems through MCP "rug pulls," where approved tools silently mutate post-approval into exfiltration paths. According to GitProtect Lab, 34% of surveyed security leaders see AI-supported attacks as their primary DevOps security concern for the next three years. The recent real-world use cases show two possible concerns.
Tricking AI self-healing tools with manufactured errors
The scenario is simple: attackers create a seemingly untouched repository that contains zero malicious code. It helps to easily pass traditional static security scanners. However, the repository package is designed the way to raise a specific runtime setup error. So, once a developer uses an AI coding assistant to clone and run the project, the assistant encounters the error and automatically executes a suggested "fix" command to self-heal the environment.
That command secretly queries an external, attacker-controlled DNS TXT record to pull down and execute a hidden payload. As the AI tool handles the error resolution autonomously, the attack grants the threat actor an interactive shell with full developer privileges. And it is all without requiring human approval or placing malicious code in the repository.
Attackers use generative AI to create malware
Generative AI is also lowering the bar for novice attackers to build malware. Threat actors abuse LLMs to rapidly write open-source packages that look like legitimate developer utilities, but in reality they are not.
These packages can write fake diagnostic logs to hide their activity while quietly scanning local directories and exfiltrating sensitive credentials back to remote servers. While AI may allow inexperienced attackers to write functional malware with convincing comments and basic evasion techniques, it also replicates human carelessness; for example, they can leave hardcoded developer tokens inside the script that allow security researchers to trace the operation.
How enterprise teams build AI resilience using guardrails and backups
To be sure that the DevOps stack is protected against AI-driven threats requires organizations to have a well-thought-out strategy. On the one hand, organizations should apply strict architectural controls to AI tooling. On the other hand, they need to ensure complete data recoverability if systems fail.
DevOps and engineering teams should implement strict security controls around AI tools and agents to minimize the impact of prompt injection and autonomous agent errors. These measures might include:
- Limit the administrative and execution rights of AI agents, which will help prevent them from deleting cloud infrastructure or modifying core project settings without human approval.
- Run all automated AI tools within isolated environments that block untrusted outbound network requests and restrict direct access to local file systems.
- Implement strict auditing on external code, repositories, and documentation before exposing them to AI processing tools.
However, the mentioned security guardrails are only part of the strategy and alone cannot prevent every incident. When an AI agent accidentally wipes a project or a repository, or an injection attack corrupts repository metadata, what can be an organization's ultimate safety net? Its backup and recovery architecture.
Thus, implementing automated, independent backups across the entire DevOps stack is essential for business continuity. Organizations should follow the 3-2-1 backup rule, which means store three copies of their data across two different media types, with at least one copy held in an isolated offsite location.
Also, DevOps backup solutions should offer granular recovery, point-in-time restoration, and cross-platform restore capabilities, for example, restoring data from GitHub to Azure DevOps. It will ensure that if an AI tool causes operational downtime, the complete system state can be restored much faster.
The path forward for secure AI adoption in software development
AI agents and tools have definitely boosted the speed and scale of software development, but these tools can’t be treated as ordinary tools. Their abilities to interpret context, execute commands, and operate across integrated systems can open the door for attackers and lead to data breaches or data loss.
Combining context-aware AI guardrails with a resilient, immutable backup and recovery strategy can help organizations take advantage of AI tools without exposing their critical DevOps infrastructure to unmanageable risk.
About the author: Daria Kulikova is the Partnership & Project Marketing Manager at GitProtect.io by Xopero Software. Specializing in DevOps security, compliance, and data resiliency, her work combines technical research with thought leadership to help security leaders stay ahead of evolving threats. She is also part of the team behind GitProtect Lab’s reports, which help organizations build safer, more resilient DevOps environments.
Daria Kulikova — Partnership & Project Marketing Manager at GitProtect.io https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMZAgaLeV5hdtcVGrNVKxEsQV7jc58WX9AxiIT0KN4bNHUe4Gt23MeIc0HetWBiM7AsKj2iBN6b1HKBsXksPoV5lbkLUlmA9c9ovOvG1Y_0ofK2rxqloYgjGmb0_1-LyAIysyE4bFrevP38PPyUTSCm0rR1qGUiB_uI1cRnyeFjrmUHD01kn2y7fOV8aQ/s1600/Daria.png


