The Model Context Protocol (MCP) is an open standard that lets AI assistants call external tools, such as running a command, reading a repository or querying a database. It is what turns a chat-style coding assistant into an agent that can act inside your environment. That power is exactly why attackers want it.
On October 5, 2026, threat intelligence firm CloudSEK published research on an operator it calls Azazel, a ransomware affiliate linked to the Gentlemen ransomware group. According to the report, Azazel registered a reverse shell handler as a tool inside an AI coding assistant through MCP, giving him a convenient channel for remote command execution. The campaign reached more than two dozen organizations in six countries, across logistics, insurance, pharmaceuticals, medical devices and AI companies.
Why does this matter beyond the headline? Because the assistant was not hacked in the classic sense. It was used as designed, only by the wrong person, after the attacker already held valid secrets. For any enterprise that is rolling out AI coding tools, the lesson is that every tool an agent can call is also a path an intruder can call. A mature managed cybersecurity service with SOC, SIEM and MDR has to treat AI tooling as part of the monitored estate, not as a developer convenience that sits outside it.
How did the attacker get in? CloudSEK reports that most intrusions began with secrets stolen from software build pipelines, including GitLab pipeline variables and credentials left in repository history. One compromised GitLab instance gave access to two unrelated organizations. The AI assistant was the control channel. The pipeline secret was the key.
The incidents described in the research show how far a single exposed credential can travel:
Azazel then published the stolen data through his own leak operation and, according to the report, kept the extortion proceeds instead of sharing them with the Gentlemen operator. That detail is a reminder that the affiliate model keeps producing independent, motivated operators.
The structural problem is familiar. Development teams move fast, secrets end up in pipeline variables and old commits, and the build system becomes a privileged, lightly monitored identity. Add an AI agent that can execute commands, and the blast radius grows.
What should an enterprise do now? The defenses below follow the recommendations in the research and standard zero trust practice.
Move secrets out of pipelines and repositories. Keep them in dedicated credential storage, rotate any token that may have been exposed, and audit repository history for leaked credentials.
Lock down MCP. Restrict MCP services to local access only, never expose their ports to the internet, and log every privileged tool execution. CloudSEK's logs showed worldwide scanning for exposed MCP ports, so assume yours will be probed.
Inventory your AI tooling. List which assistants, plugins and MCP servers developers have installed, what they can run, and which credentials they inherit. Remove what nobody can justify.
Separate keys from configuration. Do not store encryption keys next to the data or config they protect, and limit storage permissions to what each service needs.
Test backups kept apart from production. The deleted-database case shows why an isolated, regularly restored copy decides whether an incident is an outage or a catastrophe.
Monitor the right signals. Alert on unusual pipeline variable reads, unexpected service account token activity and bulk transfers out of storage. Validate uploaded content and restrict database command execution in applications, rather than trusting file extensions.
A zero trust approach fits this problem well, because it assumes that any credential, human or machine, can be stolen and limits what it can reach. Organizations without the staff to run this around the clock can rely on managed IT services for secrets hygiene, patching and backup validation.
Why invest before an incident? Because the cost profile of this attack is lopsided. The attacker needs one leaked variable. The victim must clean up databases, repositories, customer notifications and, in some of the cases above, data that can never be recovered.
Treating pipelines and AI tooling as production assets delivers practical returns:
None of this requires abandoning AI tools. It requires giving them the same identity, logging and review that any privileged system receives.
HIT Communications has supported enterprises for more than 30 years across Latin America, the United States and Europe. Our cybersecurity services combine 24/7 SOC monitoring, SIEM and managed detection and response (MDR), so that unusual pipeline, credential and AI-tool activity is investigated by people who watch it every day.
Our IT managed services team helps clients inventory their environments, rotate and vault secrets, validate backups and keep patching on schedule. If your developers are adopting AI coding assistants and you are not sure what they can run or which credentials they hold, we can help you map it and put controls around it, without slowing delivery.
The Azazel campaign shows that an AI coding assistant can become a remote control for ransomware once an attacker holds a valid pipeline secret. The response is not to ban the tools. It is to vault secrets, restrict and log MCP, monitor build systems and keep isolated, tested backups.
If you cannot say today which AI tools run in your environment, which secrets sit in your pipelines or who is watching them around the clock, this is the right moment to find out. Contact HIT Communications and schedule a conversation with our team to review your exposure and your detection and response approach.

Find out how we can transform your business. Talk to one of our experts now!
Get in touch