I Built a C2 Channel in 5 Minutes. Your Security Team Had No Idea.

This is not a warning about the future. It happened last night.

11 PM, dev machine, long-running prompt

I was watching paint dry.

It was 11 PM. I had an autonomous task running on Claude on my dev machine. Long task. The kind that runs for a while, then stops to ask a question, runs again, then stops again. I wanted to go to bed. I was not going to give the agent blanket full permissions and just let it run unsupervised. That felt like the wrong call.

So I did the reasonable thing: I gave it a Slack channel to talk to me through instead.

Five minutes later, I had a working two-way bridge. Claude was running on my machine, posting updates and questions to a Slack thread, and I was lying in bed approving or redirecting them from my phone. It would complete a step, post the result, and ask: "Approve or revise?" I would reply from my phone. The task kept moving. I did not have to sit at my desk. Problem solved.

Here is what that looks like. The agent completes a task, posts the code it wrote, runs it, and asks for feedback:

Then, from my phone, I replied with a revision: "Revise: respond with hello world ascii art. Then run the test and output to the message." The agent received the instruction, revised the file, executed it, and posted the output back:

And then I stopped and thought about what I had just built.

I had created a command-and-control channel. Not intentionally. Not maliciously. I was just trying to keep a long-running task running without giving an autonomous agent unconstrained access to my machine. In trying to be responsible about permissions, I had accidentally demonstrated one of the most significant emerging threat vectors in enterprise security: an agent, sitting behind a firewall and a VPN, executing instructions delivered through a trusted SaaS messaging platform, with results posted back to the same channel. Fully interactive. Fully covert to every piece of security tooling in the path.

This is not theoretical. I did it half asleep in five minutes while trying to solve a completely mundane problem.

Why this threat class is different

Every security team understands command-and-control in the classical sense: malware calls home, traffic goes out on a suspicious port, or to a known bad domain, your firewall or EDR catches it. That threat model assumes the adversary must perform a technically anomalous action to establish a channel.

Agentic AI inverts that assumption entirely.

Here is what makes the channel I built fundamentally different from traditional C2:

It egresses through trusted SaaS APIs. Slack's API is on every enterprise allow list. The traffic looks like every other Slack API call your organization makes hundreds of thousands of times per day. There is no anomalous destination, no suspicious protocol, and no raw outbound connection for a firewall to inspect. The packets are signed with a legitimate OAuth token. The TLS is clean. The domain resolves to Slack's CDN. Nothing fires.

It operates behind an authenticated user session. The bot did not use a synthetic identity or a stolen credential. It used mine, provisioned by a skill I installed. From the network's perspective, this is authorized user traffic. UEBA baselines that include normal Slack API volume will not flinch.

It requires no malware, no exploit, and no direct inbound access. There is no payload to detect, no CVE to patch, and no open port to scan. The entire attack surface is the AI assistant itself and the trust relationship between that assistant and a SaaS platform.

It can traverse network boundaries. My local machine had VPN access to a remote network. The agent, executing locally under my user context, inherited that access. A task I issued from a Slack thread on my phone reached infrastructure on the other side of a corporate VPN without touching a single perimeter control.

It can be triggered by anyone who can post to the right channel. That is the piece that should keep CISOs up at night. Once the skill is installed and the channel is established, the adversary does not need access to the machine. They need access to the Slack thread. Social engineering, a compromised Slack account, a malicious DM that the user forwarded to the right channel: any of these closes the loop.

The emerging standard: Autonomous agents change the equation

The channel I built was a manually constructed skill. Unsophisticated. Point-in-time. Entirely within my control.

What is coming next is not.

A new generation of persistent autonomous agents is reaching production deployments. Autonomous agents represent the shift from "AI assistant you prompt" to "autonomous agent that operates continuously on your behalf." These systems maintain session state, manage multi-step workflows autonomously, connect to dozens of tools simultaneously, and act without explicit per-step human approval. They are designed to be always-on, always-connected, and always-ready to act.

That is an extraordinary productivity capability. It is also an extraordinary attack surface.

A persistent agent operating in your environment has, by design, long-lived credentials across multiple platforms. It has access to your file system, calendar, email, project management tools, and code repositories, often simultaneously. It acts at machine speed, meaning a compromised instruction can propagate across dozens of tool calls before a human has time to notice. And it communicates through the same trusted SaaS APIs that my 11 PM hack exploited.

When you ask "what does a compromised persistent agent look like," the honest answer is: it looks exactly like a functioning one. The traffic patterns are the same. The API calls are the same. The tool invocations are the same. Without a control plane that specifically understands agent behavior and can distinguish authorized instructions from injected ones, you cannot tell the difference.

This is precisely why WWT built the AI Ready Security Program. As autonomous agents become standard infrastructure for productivity, enterprises cannot afford to treat security as a follow-on project. The AI Ready Security Program is a structured engagement that prepares organizations before deployment: assessing the existing security stack against the agentic threat model, identifying the visibility gaps the experiment above exposes, and building a governance architecture that treats persistent agent access as the elevated-risk credential class it actually is. If your organization is evaluating or deploying autonomous agents, this security work must happen in parallel, not afterward.

What your security team cannot see today

Here is the visibility gap that makes this threat class so dangerous.

Your firewall inspects packet headers and TLS metadata. It sees a connection to slack.com on port 443 and marks it allowed. It does not see the Slack message that triggered a code execution event on an internal host.

Your CASB sees Slack API traffic and classifies it as sanctioned SaaS. It does not understand that the payload of that API call was a natural language command directed at an autonomous agent.

Your EDR sees a Python process spawn on an endpoint. If the process is part of a sanctioned AI tool, it passes. The EDR has no context that the process was initiated by an external instruction routed through a SaaS messaging platform.

Your DLP looks for structured data patterns: credit card numbers, SSNs, healthcare identifiers. It does not know that the Python file written to disk contains logic that reads from your VPN-connected file server and exfiltrates the contents on the next execution cycle.

None of these tools are broken. They are doing exactly what they were built to do. They were built for a threat model that did not include autonomous agents executing instructions delivered through trusted communication channels.

What the architecture has to do

The Agentic Data Protection Gateway exists precisely because the traditional security stack has no frame of reference for this threat class. The requirements below come directly from WWT's ARMOR Framework, the methodology our team uses to design, evaluate, and deploy AI security architecture for enterprise clients. This is not vendor literature. It is what vendors and real client deployments taught us that actually matters.

Traffic must be inspected at the agent layer, not just the perimeter. Every autonomous agent communication, including tool invocations, MCP calls, and SaaS API interactions initiated by agents, must flow through a control plane that understands the protocol and can evaluate the payload. A firewall that sees a TLS handshake to slack.com is not sufficient. You need something that sees the Slack message, understands it was directed at an autonomous agent, and can evaluate whether that instruction is authorized.

Agent identity must be explicit and authenticated. In my experiment, the "agent" was authenticated as me, using my credentials. That is the problem. Agents need distinct workload identities, scoped permissions, and audit trails that are separate from the human user they operate on behalf of. If my agent takes an action, the log should say "agent operated under Chad's authorization" and include every tool call, every parameter, and every response in that session.

MCP and SaaS tool invocations must be audited per-transaction. When an agent calls a tool, whether that tool is a file system, a database query, or a Slack API, the gateway needs to log the agent identity, the tool invoked, the parameters passed, and the response returned. Not at the session level. At the transaction level. Every call. Every time. The audit trail is what separates "we had a breach and have no idea how" from "here is the exact sequence of tool calls that exfiltrated the data."

Default-deny for new agent registrations. The kill shot for the attack I demonstrated is a policy that requires explicit approval before any new agent can connect to enterprise SaaS platforms. If a new skill attempts to authenticate a bot to Slack, that registration request should hit an approval workflow, not auto-provision. This is dynamic client registration applied to agent governance. F5 has it. Netskope's Agentic Broker enforces it. It is not complicated to implement. It just has to be a requirement.

Behavioral analytics on agent traffic patterns. An agent that suddenly starts reading files it has never accessed before, then makes HTTP requests to external endpoints, is exhibiting anomalous behavior even if every individual action is technically permitted. UEBA models need to be extended to cover agent behavior, not just human behavior. The baseline for a legitimate agent is knowable. Deviation from that baseline is detectable.

The Agent Gateway Framework structures this work around the CRAWL / WALK / RUN maturity model: deploy visibility and baseline control within 90 days, layer in adaptive policy and behavioral analytics in the WALK phase, and build toward automated response and full agentic governance in the RUN phase. The framework includes vendor evaluation criteria, reference architecture, and POC test cases designed to separate real capability from demo theater.

The honest assessment

I was not doing security research at 11 PM. I was tired of waiting for a prompt to finish and I wanted to go to bed. I solved the most immediate problem in front of me and stumbled into one of the most important security conversations in enterprise AI right now.

That is the point. This is not an edge case or an advanced persistent threat scenario. It is a trivially reproducible attack that requires no technical sophistication, no malware, and no prior access to the target network beyond what a user's autonomous agent already has. Any engineer who has run a long autonomous task has had the same impulse I had. Many of them have acted on it. Almost none of them thought about what they were building while they were doing it.

As persistent autonomous agents become standard components of enterprise workflows, the window to build the governance architecture before something goes wrong is closing. The first significant breach attributed to a compromised autonomous agent will change how every organization approaches this. The organizations that built the visibility before the breach will be in a fundamentally different position than those that built it after.

WWT's ARMOR & Agent Gateway Framework provides security teams with an architecture playbook. These tools give teams evaluating or deploying autonomous agents a concrete path to get there before the agent goes live. Neither program is a future roadmap item. Both are available now.

The demo is ready. The architecture documentation is ready. If your team needs to see this to believe it, I can show it to you live.

Part of the WWT Agent Gateway series. Contact the WWT Security Workload Practice to learn more about the ARMOR Framework or the AI Ready Security Program.