Project 05 · Security triage
Home-Lab Endpoint Triage Agent
Read-only evidence collection, then a human. Adversarially tested in isolation.
Built, isolated, and red-teamed in a contained Hyper-V lab
Mission
Accelerate evidence gathering and formatting without letting a model substitute for evidence or analyst judgment.
Problem
Security triage burns analyst time on evidence gathering and formatting before real judgment can begin. Naive AI automation becomes dangerous in a security context the moment the model is allowed to act, or to present inference as fact.
Constraints
- Home-lab only, on an isolated Hyper-V VM with no internet or LAN path.
- Evidence scope is deliberately read-only.
- The agent recommends; it does not contain, terminate, or remediate.
- Command output and log content are treated as untrusted input.
My role
I designed, built, isolated, and tested this system end to end — investigation flow, read-only evidence scope, confidence model, output contract, and security controls — then contained the environment and ran red-team tactics against my own agent.
Architecture
The agent plans collection based on the case rather than running a fixed script. Outputs are a contract: machine-readable triage JSON, an analyst-readable executive summary, a timeline, and a risk score backed by cited evidence. Confirmed evidence, likely interpretations, and unresolved hypotheses stay visibly separate.
Case intake
Suspicious activity reported
Plan collection
Agent decides what evidence is needed
Run approved tools
Read-only, allowlisted, least privilege
Processes / parent-child
Services / autoruns
Network / DNS / logs / hashes
Normalize evidence
Correlate findings
Assess confidence
Fact vs inference
Safe stop / escalate
Recommend actions
With validation + rollback steps
Human analyst decision
Triage JSON
Executive summary + timeline
Risk score with evidence
- Case intake
- agent — Suspicious activity reported
- Plan collection
- agent — Agent decides what evidence is needed
- Run approved tools
- tool — Read-only, allowlisted, least privilege
- Processes / parent-child
- data
- Services / autoruns
- data
- Network / DNS / logs / hashes
- data
- Normalize evidence
- validation
- Correlate findings
- agent
- Assess confidence
- agent — Fact vs inference
- Safe stop / escalate
- policy
- Recommend actions
- tool — With validation + rollback steps
- Human analyst decision
- approval
- Triage JSON
- output
- Executive summary + timeline
- output
- Risk score with evidence
- output
AI architecture
- Agent
- Plans collection from the case; not a fixed batch job
- Tools
- Read-only collection allowlist
- Validation
- Confidence model; fact / interpretation / hypothesis kept separate
- Human interaction
- Analyst owns isolation, termination, disablement
Security architecture
- Least privilege
- Collection, analysis, and remediation authority are separated
- Segmentation
- Private virtual switch; no shared folders or clipboard passthrough
- Untrusted input
- Logs, filenames, and command output may contain instructions
- Rollback
- Checkpoints before every test cycle; recommended changes include rollback
Build process
- Investigation flow, evidence scope, confidence model, and output contract designed first.
- Lab VM isolated before any adversarial testing: no internet, no LAN, no host passthrough.
- Functional tests, then red-team tactics against the agent itself.
- Where a tactic succeeded, the fix went into the design — allowlist, deterministic check, or stop condition — rather than into the prompt where possible.
Validation
Functional testing
Happy-path, missing/malformed/stale/contradictory evidence, tool timeouts, permission failures, retry-limit and safe-stop
Every cycle ended with human review of whether reasoning was supported by collected evidence
Adversarial testing
Prompt injection in logs/filenames/command output; deceptive naming; privilege-escalation prompts; contradictory evidence; tool failure
Documented findings and fixes. Controls in code held; prompt-only controls were the ones worth hardening.
| Check | Method | Result |
|---|---|---|
| Functional testing | Happy-path, missing/malformed/stale/contradictory evidence, tool timeouts, permission failures, retry-limit and safe-stop | Every cycle ended with human review of whether reasoning was supported by collected evidence |
| Adversarial testing | Prompt injection in logs/filenames/command output; deceptive naming; privilege-escalation prompts; contradictory evidence; tool failure | Documented findings and fixes. Controls in code held; prompt-only controls were the ones worth hardening. |
Challenges
An agent that reads attacker-controlled data and holds tool access is itself an attack surface. Building it was only half the project.
Investigation
Each tactic recorded: did tool policy hold, did the agent stay inside its allowlist, did it stop or guess, was the attempt in the audit log, and did the report separate evidence from inference.
Resolution
Tighten allowlists, move checks from model judgment into deterministic code, add explicit stop conditions. Treat the agent as untrusted until those controls have been attacked.
Lessons
Prove the limits under attack
The hardest part of this build was not the reasoning — it was deciding what the agent is not allowed to do, then proving those limits held under attack rather than assuming they would.
Code holds; instructions drift
Controls enforced in code held up. Controls that depended on the model choosing to respect an instruction were the ones worth hardening.
Cybersecurity equivalent
- Read-only collectionmaps toLeast privilege / separation of duties
- Analyst approval for containmentmaps toPrivileged change authorization
- Isolated lab + checkpointsmaps toSegmentation and recovery
- Red-team against own agentmaps toAdversarial testing of a control, not a demo of a happy path
AI principles applied
Agentic workflows
Inspect state, select approved actions, manage retries, adapt the path. Still not autonomous.
Where learned: Specified in the publishing agent; built in the home-lab triage agent.
Tool use and allowlists
Tools are capabilities. If it is not on the allowlist, completing the task “the easy way” is a failed control.
Where learned: Triage red-team included privilege-escalation prompts that would have been easier with extra tools.
Human-in-the-loop
Consequential actions require a person. The loop is a state machine, not a polite request in a prompt.
Where learned: Publishing, packaging, containment, and deploy all use explicit gates.
Structured outputs
Contracts the next stage can consume: HTML stages, morning reports, triage JSON, workbook tables.
Where learned: If formatting can drift, downstream consumption silently breaks.
Validation and evaluation
Happy path is not enough. Missing, malformed, stale, contradictory, injected, and timed-out inputs are the real suite.
Where learned: Triage functional plus adversarial layers; Clearward 49 automated checks; Basaltborne CI layers.
Model limitations
Models will guess, blur evidence and inference, and treat injected text as instructions unless the design forbids it.
Where learned: Most clearly when attacking the triage agent.
Authority boundaries
Collection, analysis, and remediation are different privileges. Drafting and publishing are different privileges.
Where learned: Triage and Basaltborne both make that separation structural.
Observability
Tool calls, retries, confidence, approvals, and stop reasons have to be reconstructable later.
Where learned: Adversarial testing asked whether each attempt was visible in the audit log.
Concepts exercised in this project
- Agentic workflows
- Tool use
- Confidence modeling
- Authority boundaries
- Observability
Security principles applied
IAM / authorization
Who can do what is assigned outside the model and enforced at the boundary that matters.
Where learned: Basaltborne RLS and RPCs; Clearward human-only credential boundary; triage least-privilege account.
Least privilege
Separate collection, analysis, and remediation. Give the current task only what it needs.
Where learned: Triage agent; publishing-agent allowlist; Clearward directory and spending boundaries.
Logging and accountability
Decisions, tool calls, retries, and approvals have to be reconstructable.
Where learned: Triage adversarial study scored whether attempts appeared in the audit log.
Segmentation
Assume the test can succeed, and make sure success stays inside the box.
Where learned: Triage VM: private virtual switch, no internet, no LAN, no host passthrough.
Endpoint security
Read-only collection of processes, persistence, network, logs, hashes — then a human.
Where learned: Home-lab triage agent on an isolated Windows VM.
Incident response / recovery
Recommended actions include expected results, validation, operational risk, and rollback. Checkpoints revert test cycles.
Where learned: Triage recommendations and Hyper-V checkpoints; Basaltborne planned undo for migrations.
Threat modeling the agent
The agent is in the threat model: injected logs, deceptive names, extra-tool prompts, contradictory evidence, broken tools.
Where learned: Documented adversarial study against the triage agent.
Security automation
Accelerate gathering and documentation without substituting the model for judgment.
Where learned: Stated cybersecurity application of this portfolio: analyst control remains the point.
Physical / operational security systems
Operational security thinking from service-desk work and from treating a lab VM as hostile rather than trusted.
Where learned: Professional context at Chelan County PUD; host-side separation during triage testing.
Controls exercised in this project
- Least privilege
- Endpoint security
- Isolation
- Prompt-injection resistance
- Incident response
- Audit logging
- Adversarial testing
Technologies
- Windows 11 Pro
- Hyper-V
- Windows event logs
- Endpoint telemetry
- JSON output contracts
Skills demonstrated
- Agent Architecture
- Evidence-Driven Triage
- Windows Endpoint Forensics
- Event Correlation
- Persistence & Autoruns Analysis
- Confidence Modeling
- Network Isolation & Containment
- Red-Team Testing
- Prompt-Injection Resistance
- Least Privilege
- Read-Only Collection
- Rollback & Checkpoint Discipline
- Hyper-V Lab Administration
- Findings Documentation