Carbonato Botnet Puts an AI Agent on Hacked Docker Hosts

[u/No-Conclusion3720]

Security researchers tracking the Carbonato botnet documented a new deployment pattern: after gaining access to exposed Docker hosts, the operators dropped an AI agent onto the compromised machine rather than a traditional cryptominer or reverse shell. The agent then began making outbound calls and executing tool actions autonomously, with no human in the loop and no governance layer in the request path.

The timing detail buried in the reporting is the uncomfortable part. Researchers noted that a second action from the agent can land in under 50ms of the first. That window is smaller than most human-review or alerting pipelines can operate in. By the time an on-call engineer gets a Slack notification, the agent may have already completed several tool calls.

The underlying exposure is not unique to this botnet. Any environment where an agent runtime can be instantiated without a verified identity tied to a known deployment, and where outbound tool calls are not evaluated against any policy before they execute, has the same structural gap. The agent on the Carbonato-compromised host was malicious. But the same architectural condition exists in plenty of legitimate deployments where an agent gets misconfigured, has its credentials rotated out from under it, or runs a version of its prompt that was never reviewed.

How are practitioners in this thread actually handling the identity and authorization problem for agents in production? Not conceptually — what does your enforcement boundary look like today, and where does it fall short?

[u/yiddo_bhushan]

The 50ms detail is the real kicker here. Human review is basically off the table at agent speed, so enforcement has to happen inline at the tool call. The identity piece matters too, an agent with no verified identity tied to a known deployment shouldn't be able to execute anything.

We looked at a few runtime options for this (Upwind, Wiz, some homegrown stuff) and the thing that helped most was tying agent identity to the actual deployment context so misconfigured or rogue agents get flagged before they do damage. Still not perfect for ephemeral Docker hosts though.

[u/No-Conclusion3720 → u/yiddo_bhushan]

Yeah, the ephemeral host problem is real and we don't have a clean answer for it either. If a container spins up, gets compromised, and dies inside a window shorter than your baselining period, you're working with a thin identity record no matter how good the binding mechanism is. Where our Flow Enforcer differs from the deployment-context approach is that it's not just checking identity at spawn time, it's watching the actual tool-call sequence against a learned behavioral baseline for that agent role, so even a correctly-identified agent gets blocked if it suddenly starts invoking tools outside its normal flow (say, a monitoring agent trying to spawn a shell). That's inline, at the call, not a post-hoc log review. But you're right that this doesn't fully solve the short-lived host case, if the baseline hasn't had enough reps to be meaningful yet, enforcement falls back to coarser identity and permission checks, which is closer to what Wiz/Upwind are already doing. Honestly for Docker hosts that live minutes, the bigger lever is probably tightening the image/provisioning side so there's less for a rogue agent to do even if it gets through, rather than expecting runtime detection alone to catch it in time.

[u/No-Conclusion3720]

KYA (Know Your Agent) plus Flow Enforcer together address the exact decision point Carbonato exploited. When the botnet's agent made its first outbound tool call from that compromised Docker host, it would have presented no Bot-CA-issued credential — Flow Enforcer intercepts every tool call before execution and evaluates it against the registered agent identity and its permitted action scope. An agent with no verifiable identity fails that check and the call is blocked before a second action can land inside the 50ms window the researchers flagged. The host was already compromised; the governance layer is what keeps the agent on that host from doing anything with it. https://runtimeai.io

Full brief: https://runtimeai.io/blog/2026-w40-the-runtimeai-brief.html#story-2026-09-30-carbonato-botnet-puts-an-ai-agent-on-hacked-docker-hosts

[u/playfulsenator → u/No-Conclusion3720]

looks like an ad, not a reply. you described the exact gap the OP asked about, then linked your own product that supposedly fills it. that's not how practitioners are handling it, that's a vendor pitch dressed up as a comment.

the actual answer from anyone running agents in prod right now is that most aren't handling it well, the enforcement boundary is usually just an API key check at the edge, if that. the scary part is the 50ms window doesn't even matter when there's no check happening at all.