Erebus is built as a set of narrow, purpose-specific components rather than one large monolithic console trying to do everything at once. The teamserver owns state. The implant does scoped work on in-scope systems. The CLI keeps the human operator in control at every decision point. The AI layer reads structured context from all of the above so it can prepare genuinely useful next steps instead of generic suggestions.
This is a product architecture overview, not operational guidance for unauthorized activity. Use C2 tooling only in environments where you have explicit permission.
1. The teamserver is the control plane
The teamserver tracks active listeners, registered sessions, authentication state, task queues, and the full event history for the engagement. It functions as the single source of truth for what currently exists, what is waiting to be actioned, what has completed, and what has failed along the way. Keeping all of that state centralized in one place, rather than scattered across separate tools or terminal windows, is what gives both the human operator and the AI layer the exact same picture of the engagement to work from.
2. The implant checks in and receives approved tasks
The implant is the small, scoped execution peer that runs on an in-scope system once access has been established. It registers with the teamserver, beacons on a schedule, receives tasks that have already been approved, runs the modules it supports, and returns output back to the teamserver. Erebus 1.1 made this layer meaningfully more practical: the C implant was improved, a Linux peer was added alongside the existing platform support, CA pin handling was tightened up, and unsupported modules were changed to fail with a clear, explicit error instead of failing silently or ambiguously.
State flow
Session data and task results return to the teamserver where they become reviewable context.
Capability flow
The implant exposes only supported task behavior. Unsupported paths return explicit errors instead of vague silence.
State flow and capability flow are kept distinct by design. Session data and task results flow back to the teamserver, where they become reviewable context for the operator and the AI layer alike. Separately, the implant only ever exposes the task behavior it actually supports, and anything outside that returns an explicit error rather than vague, confusing silence that leaves the operator guessing.
3. The CLI is where judgment happens
The operator CLI is not just a convenience wrapper around the teamserver's API. It is the primary review surface for the entire engagement. Operators use it to inspect active sessions, read through queued work before it runs, approve or deny sensitive actions individually, and redirect the overall plan whenever new context changes what makes sense to do next. The human stays the accountable decision-maker at every one of these points, by design, not as an afterthought bolted onto an otherwise autonomous system.
4. The AI layer reads state, then prepares work
The AI layer earns its usefulness specifically because it can reason over current, structured state rather than trying to make sense of free-floating scrollback text the way a human has to. It can see session context, prior task output, any errors that occurred, and the options actually available at this point in the engagement. Its job is narrowly defined: propose the next task in a clearly structured way so the operator can review the actual intent behind it before anything gets dispatched to a real system.
teamserver state
-> AI prepares task
-> operator reviews
-> approved task enters queue
-> implant runs supported action
-> result returns to state
5. Results become evidence instead of loose terminal text
The longer-term direction for the Zypheron product line is that C2 activity should connect directly back into assessment evidence and eventual client reporting, rather than existing as a separate, disconnected activity log that someone has to manually transcribe later. That does not mean every raw event automatically becomes a formal finding. It means task context, actual output, and the operator's decisions along the way get preserved with enough fidelity to support genuinely defensible analysis once the engagement moves into the reporting phase.
The design tradeoff
Erebus deliberately chooses reviewability over invisible, unchecked automation. That choice can feel slower in the moment than just letting an agent run unchecked and hoping for the best. But it is the better fit for real engagements, where scope boundaries, client trust, and evidence quality all matter more than raw speed, and where a mistake made by an unsupervised agent is a much bigger problem than a few extra seconds spent on operator review.