Meet the Eidolon Framework

*There is a video demo at the end of this blog post if you don’t want to read it and would prefer to skip to the end.

I built something I care about and I want to tell you why it exists.

This is not a claim that I invented the idea. Teams and projects like PentAGI and others walked similar paths long before I showed up. They proved the appetite for serious operator tooling around security agents. I took my own swing at the same problem space with a few principles I would not compromise on.

The Eidolon Framework is a cybersecurity AI agent platform with a web control plane. You pick a named agent. You attach a real authorization record. You dispatch a task. Then you watch the run unfold live: transcripts, tool calls, and files written into an artifact folder you can audit later.

Under the hood the product name is Eidolon. Some paths still say chimera in code and on disk on purpose. That is a result of me changing the name of the project halfway through. It was initially called Project Chimera due to the multi-faceted nature of the platform. Having project in the title though made it feel incomplete so I created a new name.

What I was trying to solve

Offensive security work wants leverage. It also wants judgment. Models can draft plans and commands faster than most people can type. They are not a substitute for a signed engagement letter or a clear scope boundary. Nothing replaces a human who says yes to the scary step.

My goal was simple to say and careful to build. Give agents access to real tooling on a real operator host while keeping humans in charge of the moments that matter.

I split ownership cleanly in the repo. The agent runtime and skills live in Agents/. The panel lives in WebApp/. Both sides follow the same written contract so the system does not drift into two private languages.

How a run actually works

You open the panel. You register a scope of work. That record carries targets, rules, allowed action classes, an expiry, and a signer. You create a task with an agent, a prompt, a scope id, a model choice, and optional extra constraints. When you dispatch, the API starts a fresh sub-process for that task. The browser talks to the API over Web-sockets. Events stream in ordered frames. SQLite holds jobs and transcript rows. Files land under artifacts/<task_id>/.

If you reload mid-run you should not lose the story. The contract includes replay semantics so the UI can catch up after a disconnect.

You can interrupt softly or cancel hard. You can answer when an agent asks a question. You can approve or deny when a gated action needs a human. The panel is not a movie you watch. It is a cockpit.

Scope of work is the spine

A scope is not flavor text. It is the authorization record the task must reference.

Targets can be hosts, CIDRs, URLs, or domain globs depending on how you model the engagement. Rules are human readable lines your team can argue about before anything runs. Allowed actions are explicit classes like recon versus exploit class work. The record expires. Someone signs it.

Dispatch is blocked unless the back-end can prove the scope is valid and unexpired for that task. That gate is boring engineering and I love it for that.

Enforcement does not rely on vibes in the system prompt alone. Shared tools like shell, HTTP, and filesystem helpers take the Scope object at construction and fail closed. If a command points outside the authorized target set the tool layer should stop it. That is how you keep "please stay in scope" from becoming a suggestion the model can negotiate with itself.

Strict personas on purpose

Each agent ships a persona.md file: a small front matter block for name, codename, role, voice, and how it refuses work. Then a free form body that reads like a briefing you would give a senior consultant.

The framework composes a final system prompt from several parts. It pulls in the persona body and voice cues. It adds a summary of the active scope. It appends a block of framework rules.

Those framework rules are non negotiable. They apply to every agent. The persona cannot override them. That split matters. You get character and consistency for product feel. You still get a floor on safety behavior that every agent shares.

I want operators to recognize Cerberus or Argus or the next specialist the same way they recognize a teammate’s style. I also want every one of them to cite the same refusal logic when someone asks for an out of scope target.

Human in the loop is the product

This is the heart of the design.

Risky or credentialed work routes through an approval request that blocks until the operator answers or a timeout denies by default. Lower risk work can auto approve for speed while still emitting observability frames.

High risk approvals expect more than a click. The operator should leave a short written reason. That sounds like paperwork. It is really a forcing function for the second of mindfulness before something destructive runs.

There is also a live operator feed on the task screen. Messages there are treated as authoritative guidance mid run. Think of it less like chat stickers and more like a senior operator leaning in with a correction while the junior is mid command.

The philosophy I keep in front of this project is blunt. Power through tooling. Safety through humans. A Kali native agent that cannot touch Kali tools is not useful. An agent that can touch everything without a pause is not acceptable. The compromise is gates you can see, transcripts you can replay, and artifacts you can hand to a reviewer.

Why I am still excited

I am not claiming a miracle. I am claiming a shape that fits how security teams already think. That means authorized targets and explicit ROE. It means named roles and evidence on disk. It means humans who remain accountable.

If you have been following this space you have seen other stacks chase the same north star. I am glad they exist. They validate the need. I hope Eidolon adds another credible option for people who want the same ingredients. The mix I care about centers on sub-process isolation and strict personas. It centers on scope first tooling. It centers on a panel that expects an operator in the loop from day one.

Watch it Work

If you’re just interested in watching the framework run then this video is for you. I logged into a old HackTheBox account, picked a easy Linux box to start and booted the target machine up. I fed the scope of work a per-written rule of engagement and then passed a pre-made operator prompt to the task. This video is only a partial recording and won’t show everything the platform did to exploit the box because the target is a seasonal machine. The video will show off the ability for the operator to adjust the scope live. Please note this video also shows a build several versions out-of-date and is from a draft round of testing.

Demo of the Eidolon Framework being used to target a intentionally vulnerable machine

This was a slow test run and subsequent runs and machines proved to be much faster. At the time of writing this the fastest solve Eidolon’s agents have performed was a 28 minute recon to root of the Medium Difficulty Box - Principal. However the run of the facts box above came in at 48 minutes total with the flags being verified.