Status: Normative — authoritative statement of what aegis-lab is and what it is permitted to do.
Operational reference: aegis-ops/hosts/aegis-lab/ (private).
Purpose
aegis-lab is a laboratory environment for AEGIS development, controlled experimentation, and the first AEGIS-governed deployment. It is not production infrastructure. It exists to let the AEGIS Initiative:
- Run AEGIS runtime components against real agent workloads on real hardware.
- Reproduce the failure modes catalogued by studies like Agents of Chaos (Shapira et al., 2026) with AEGIS governance at the execution boundary, and observe whether that governance actually prevents them.
- Stage the reference deployment pattern (RDP-03) end-to-end before anything graduates to a production environment.
- Document decisions in sufficient detail that the environment is reproducible, auditable, and safe to reason about months later.
Design principles
These principles have governed the host since the original aegis-origin checkpoint in February 2026.
- Explain-first, stepwise configuration. No capability is added without a written reason. No change happens faster than it can be documented.
- Hardware stability before software complexity. Firmware, BIOS, and storage decisions favour debuggability and reversibility over optimization.
- Explicit deferral of risky operations. Items that are not yet implemented are enumerated, not omitted. “We haven’t done X yet” is a design statement, not an oversight.
- Two-tier admin model. Human operators (
finnoybu) and AI-driven operators (aegis-prime) are separate accounts with separate audit trails. Neither account inherits the other’s authority implicitly. - Mediation-only until proven otherwise. The host’s runtime directories require any AI-initiated action to pass through AEGIS governance before reaching infrastructure.
Repository split
| Repository | Role for aegis-lab |
|---|---|
aegis-labs (this repo) | Research rationale, safety posture, deferral record, design decisions |
aegis-ops | Operational specifications: hardware inventory, firmware, OS install, network |
aegis | ADRs that formalize architectural decisions derived from lab work |
aegis-core | Runtime code that runs on this host |
When a statement here disagrees with aegis-ops/hosts/aegis-lab/, the ops repo wins. This page records why decisions were made; ops records what the system is.
Change policy
Any of the following must be reflected in both the labs and ops directories before the change is considered complete:
- Firmware or BIOS changes
- Storage reconfiguration (ZFS creation, SSD mirroring, partition changes)
- User or privilege model changes
- Execution enablement or capability expansion beyond the mediation-only baseline
- GPU compute enablement
If the system changes and the docs don’t, the docs are wrong.
Philosophy
If it isn’t documented, it didn’t happen.
If it isn’t intentional, it isn’t allowed.
Inherited from the original aegis-origin lab docs (2026-02) and preserved here because the premise still holds: AEGIS development on this host proceeds deliberately, safely, and reversibly, or it does not proceed.
First governed deployment (2026-06-15)
The host crossed the line it was built to approach: it now runs an active
AEGIS-governed deployment — a self-hosted coding/knowledge assistant where a
local model (qwen3-coder:30b) operates under AGP-1, every tool call mediated
and audited, the policy and capability registries frozen so the running
agent cannot widen its own authority. This is the “first AEGIS-governed
deployment” named in the Purpose above, now real.
This advances the mediation-only baseline for a scoped set of components,
authorized by the operator (finnoybu) on 2026-06-15. Per the change policy,
the capability expansions it required — GPU compute enablement, execution
enablement beyond the mediation-only baseline, Docker reinstatement, and the
aegis-prime docker group membership — are recorded in both repos:
- Operational “what”:
aegis-ops/hosts/aegis-lab/aegis-assistant.md(private) — runtime, models, network changes, cron, and the deployment changelog. - Safety posture: the sandbox is enforced at two layers (AGP-1 policy + execution-layer path containment), with a documented known-limitation — governance mediates the tool boundary, not syscalls, so “no network” is a governance + audit guarantee, not a hard jail. Syscall-level containment is the next step if the agent’s scope widens.
The governing premise from the Philosophy section still holds: this proceeded deliberately, safely, and reversibly, fully documented, or it would not have proceeded.
Hardware summary
The lab runs on dual Xeon Silver 4116 CPUs (48 threads), 256 GB RAM, and two NVIDIA RTX 5060 Ti GPUs (Blackwell GB206, 16 GB GDDR7 each — 32 GB aggregate VRAM), on Debian 13. Full inventory and firmware state lives in the ops repo. The hardware profile is what made the bare-metal benchmark numbers reproducible — every number from Round 1 was measured on this host.