agent-lab · NetState Data

AI agents are only useful in operations if you can trust what they do. This lab sets up local models next to the network lab and starts with one agent that can only watch, so trust is earned before anything can act.

[Placeholder: this project is being planned. The intent is set; the content, code and evidence are not written yet. Name is provisional.]

What it is

Local AI models running on my own hardware, so no logs or network data leave the lab, and a first agent that works on The NetState Lab Network.

Agent	Job	Access
Monitor	Watches the lab network’s logs, captures and web server, and flags what looks wrong	Read-only

Rules detect, AI judges

Simple checks don’t need AI. Is the site up, is the service running, did Fail2Ban just ban someone: plain scripts answer those instantly and reliably, and there is nothing in them to trick. The AI is kept for what rules can’t express: patterns, judgment, and explaining what happened in plain language.

Why start with one agent

The same rule I use for people applies to agents: least privilege, documented, and nothing changes without a check. The first agent can only watch. Once the setup is proven and the monitor’s reports can be trusted, the next project adds agents that alert, troubleshoot, communicate and write code, and ties them together into one workflow.

Tools

[TBD: model runtime and how the monitor reads the lab’s logs and captures.]

How it runs

It starts from The NetState Lab Network’s own Compose file, alongside the network: docker compose --profile agents up -d. One file runs the whole lab.

The pieces

Each project is laid out in the same order: the problem that started it, the documents that plan it, what was built, and the proof that it works. Open any card to read it.

document · 2 · document & propose agent-lab: setup and guardrails planned How the local models are set up in the lab, what the monitor is allowed to see, and how its read-only access is enforced and logged. read →

evidence · 4 · verify The models run locally not captured yet The model runtime answering inside the lab, with no logs or network data leaving it.

evidence · 4 · verify The monitor catches an event not captured yet The monitor spots a problem in the lab network and reports it, with the log lines it saw.

evidence · 4 · verify Read-only, proven not captured yet The monitor tries to change something and is refused, showing its access is limited to watching.

How it connects

The projects build on each other, in order. Each one starts from what the one before it produced.

builds onThe NetState Lab NetworkA firewall between a LAN and a DMZ, on one PC. Five phases: see what crosses the wire, a legacy port knock, fix the leaks, modern remote access, traffic shaping.open → leads toagent-workflowA junior admin team of local AI agents, each with one job, that finds problems, explains them and routes them to the right person. The agents change nothing; a person decides every action.open →

Phases

Phase	Scope	Status
v1	Local model runtime set up in the lab, next to the lab network, running on the processor alone. The start of measuring the smallest machine it works on.	planned
v2	Rule layer, no AI: health checks, known events from the logs (bans, failed logins, a service down) and a dated local copy of the vulnerability databases.	planned
v3	Monitor agent: read-only access to the lab network's logs, captures and web server. It watches and reports, and cannot change anything, including when a log line tries to tell it to.	planned