A financial crime group active since 2012 just showed developers what their everyday agent stack looks like in the wrong hands.
New research from Straiker shows how CyberCartel built a multi-agent attack system called CARLIY0S and aimed it at more than 400 banks, payment providers, and other financial organizations across Latin America. The system ran on commercial models, including Anthropic's Claude and xAI's Grok, with Moonshot AI's Kimi in the mix.
The tools will look familiar. Cursor. MCP servers. API keys in .env files. Playwright. That's the part developers should sit with.
How Straiker Got Inside
CyberCartel made an operational security mistake. That gave Straiker a snapshot of the group's working environment. The September 24, 2026 snapshot captured the group's stolen-credential database, called "FinancialSoft." It held 4,493 records, including passwords and API keys.
Could it have been a decoy? Vinay Pidathala, vice president of AI security research at Straiker, doesn't think so. The team tied the environment to more than 270 pentest reports against real organizations. "The volume and specificity across hundreds of entities is inconsistent with a honeypot," he said.
Straiker attributes the work with high confidence to Tr4nsHack Team, which operated under the front name Hexagon Security Labs Mexico. Operator handles in the source code and reports matched known CyberCartel operators.
The irony: the group's rule files told the models never to output the Tr4nsHack alias. The name showed up in its own reports and code anyway.
Four Agents and an Arbiter
Here's how the system worked, based on the group's own scripts and configuration. Straiker notes it did not validate the outcome for any individual target.
A commander, Claude running in Cursor, sets a high-level objective. It delegates through the Anthropic API to four role-based agents:
- A recon agent maps the target's infrastructure and looks for ways to avoid detection.
- An exploit agent writes the attack code and automation.
- A third agent suggests lateral and unconventional attack paths.
- An arbiter weighs the debate among the other three and returns a single decision.
Five Grok "miners" analyzed the collected data and posted it to the attackers' dashboard.
Execution ran through a headless browser routed over residential proxies, so traffic looked like it came from domestic Mexican IP addresses. Once the system gained code execution through a target's web admin panel, it dropped the browser for a faster, quieter scripted session. Automated payloads then scanned databases, hunted for credentials and SSH keys, and mapped internal networks.
Why the debate format? Straiker doesn't know, and it didn't test whether four agents beat one.
Getting Past the Guardrails
The operators framed their requests as authorized red-team engagements or academic penetration tests. Straiker calls this dual-use contextual framing.
It didn't work on every model. Refusals varied inside the same system, and Straiker says it has no visibility into why. When a model refused, the orchestrator fell back to a local file of pre-written attack code, so the operation kept moving.
So how much did AI actually add? According to Pidathala, all 270+ attack reports were AI-generated. "We did not see evidence of manual efforts," he said. The local script was a fallback, not the main engine.
The configuration also listed claude-fable-5. Straiker can't confirm it ever ran. "A configuration entry is not evidence of successful execution," Pidathala said.
What We Don't Know
Quite a bit. Straiker isn't sharing how many of the 400+ targets were compromised or how much money was lost. It cites responsible disclosure while affected organizations and providers work through the fallout. The 400 figure counts targets, not confirmed breaches.
According to The Information, Anthropic investigated after Straiker shared its findings and blocked the group's access to Claude. Straiker reported that xAI was notified and is investigating the use of Grok.
What Developers Should Take From This
The core lesson is that this tooling is dual-use. "The same agent stack that builds software can run an offensive operation," Pidathala said.
That isn't a reason to stop building agents. They do a lot of good work. It's a reason to own what your agents can reach. Whoever builds an agent is responsible for what it does. So is the company that deploys it.
Straiker's guidance for teams building agents:
- Test agents against real attack techniques before production. Pidathala calls this the single highest-value action a team can take this week.
- Rotate agent credentials often and scope them tightly.
- Add observability and guardrails to detect and stop abuse at runtime.
- Treat .env API keys and MCP server access as high-value assets to secure and monitor.
That last point is easy to skip. An API key in a .env file feels routine. In CARLIY0S, API access is what let one commander direct a team of agents across hundreds of targets.
Where This Goes Next
Pidathala expects these operations to grow in sophistication and scale as models get more capable, compute gets cheaper, and attackers build AI skills. Defenders, he said, will need to continuously test their infrastructure and be ready to "detect and respond to AI-powered attacks at machine speed."
That's not hype. It's a small team, a familiar toolchain, and more than 400 financial targets. The gap between the agents developers build and the agents attackers build is mostly intent. Security has to cover the rest.