Project Aegis

Prototype

Developed as my Computer Science final project, Project Aegis is my attempt at a cybersecurity AI product. The idea is simple: a company starts an assessment session, connects a scoped network tunnel, and watches an AI agent work inside an isolated environment while every action is visible, logged, and bounded.

The part I cared about most was the boundary between “AI assistant” and “security tool.” A prompt is not a sandbox, and a model should never be the thing that decides what it is allowed to touch. Aegis is built around the opposite assumption: the agent can suggest and request actions, but the platform itself owns scope, policy, execution, and audit history.

The Product Shape

From the customer’s side, Aegis should feel like starting a focused security review rather than running a raw terminal. You create a session, provide the connection details for the environment you want assessed, and then follow the agent’s activity as it works. The UI is meant to show what is happening now, what evidence has been collected, what findings are forming, and what still needs approval.

Admins get the operational view: active sessions, stage health, user management, manual termination, and enough telemetry to understand whether a session is healthy or drifting into something unsafe.

The Stage Runtime

The core of Aegis is the “stage”: a disposable assessment environment created for one customer session. The production design uses a Firecracker microVM per active session, with a Kali-based image inside the VM and an Aegis stage service running alongside the security tooling.

Firecracker is a good fit here because the stage needs stronger isolation than a normal process but less overhead than a full general-purpose VM stack. Each session gets its own kernel, root filesystem, network device, resource limits, and lifetime. When the session ends, the orchestrator can destroy the microVM and its scratch disk instead of trying to clean up a long-lived worker.

The intended stage model looks like this:

• A read-only base image provides the scanner environment.
• A per-session scratch disk stores temporary artifacts, logs, and tool output.
• CPU, memory, disk, and runtime are capped by the orchestrator.
• The microVM has no customer credentials baked into the image.
• Tunnel material is injected only for the active session.
• Session teardown destroys the stage and removes temporary state.

I expect the agent to operate in a security-sensitive space, therefore, all reasonable measures were taken to make sure a session can never interfere with something out of its scope.

Networking Subsystem

The networking design is where most of the safety work lives. Aegis should never give the agent general internet access and hope that a prompt keeps it honest. The stage network is meant to be deny-by-default, with only a small set of permitted paths:

• control traffic between the orchestrator and the stage service,
• tunnel setup traffic to the customer’s VPN endpoint,
• assessment traffic that routes through the customer-provided tunnel,
• telemetry and artifact upload back to Aegis.

In practice, the stage would boot with a narrow management interface for health checks and tool control. Once the customer tunnel is accepted, the stage service brings up the VPN connection inside the microVM and installs the session routes. Customer CIDRs go through the tunnel interface; everything else is dropped unless it is explicitly part of the Aegis control plane interface.

That gives the platform a real enforcement point. If a tool tries to scan outside the approved network, the packet should not leave the VM. If the tunnel drops, the stage should stop assessment traffic instead of falling back to the public internet. DNS should either be routed through the tunnel or pinned to an allowlisted resolver, because DNS leaks are still network access.

Orchestrator And Shim

The orchestrator is the source of truth. It owns sessions, users, stage lifecycle, events, admin actions, and the policy decisions around what the agent is allowed to do. It is also the part of the system that can terminate a stage when it times out, goes unhealthy, or crosses a policy boundary.

Inside the stage, the Shim is the controlled bridge between the agent and the machine. The agent does not get raw, invisible shell access. It asks the Shim to run a tool, and the Shim can reject it, time-box it, capture output, redact sensitive data, and report the event back to the orchestrator.

For local development, the Shim currently exposes health reporting, tool listing, and a guarded shell endpoint. Shell execution is disabled by default, destructive command patterns are blocked, and commands have a timeout. That is not a complete security model, but it proves the direction: every capability should be explicit, mediated, and observable.

Reporting And Oversight

Aegis is also designed around the audit trail. A useful cybersecurity agent is not just something that runs commands; it needs to explain what it did, why it did it, what it found, and which evidence supports the finding.

The product model includes live activity streaming, session events, stage health, tunnel state, tool output, artifacts, and final reports. Admins need a higher-level view over all running stages, including the ability to terminate a session manually. Customers need enough detail to trust the final report without reading an unstructured terminal transcript.

Current State

Project Aegis is still an MVP, but the current prototype has the shape of the full system: a customer/admin web app, a backend that owns sessions and stage lifecycle, and a stage-side service that represents the isolated workspace where agent actions would run. It can create a session, attach a tunnel profile, start the stage flow, and stream basic status back to the interface.