# Inside AegisLoop (ARTEX-KO Plus): An Autonomous Agent That Turns a Vulnerability Into a Detection

> A plain-English walkthrough of AegisLoop / ARTEX-KO Plus, an open-source (AGPL-3.0) AI-agent security-validation platform: how it goes from an authorized-scope finding to attack/detection scenarios, defense validation against real logs, incident investigation, and autonomous Splunk threat-hunting — and the guardrails that keep it a blue-team tool.

Source: https://playciso.com/blog/aegisloop-artex-ko-plus-autonomous-security-validation · Published: 2026-10-25 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://github.com/bdg9412/artex-ko-plus

---

Most security teams are good at _finding_ problems and fixing them. Far fewer can answer the question that actually decides an incident: **"if someone exploited this, would we have seen it?"** [AegisLoop](https://github.com/bdg9412/artex-ko-plus) — titled **ARTEX-KO Plus** — is an open-source project built to close exactly that gap, from a finding on an authorized asset all the way to a tested detection. Here is how it works, in plain English. _This is an educational explainer of a third-party, open-source project (AGPL-3.0), based on its public README. PlayCISO is not affiliated with AegisLoop, ARTEX, or its authors. Nothing here is a security endorsement or legal advice._ ## What it is, and where the name comes from The name carries its lineage. **ARTEX** is the upstream AI-agent security project; **-KO** is the Korean-language edition it builds on; and **Plus** — branded **AegisLoop** — is this fork’s addition of AI-based incident-response features. The README describes it as a **security-validation platform** with two halves that feed each other: an offensive side that runs diagnostics against authorized targets, and a defensive side that turns the resulting evidence into detections, validates them against real logs, investigates related activity, and can hunt autonomously. The listed topics tell the story — `blue-team`, `detection-engineering`, `siem`, `splunk`, `threat-detection`, `threat-hunting`, `autonomous-agents`. ## The one rule that makes it legitimate Before anything else: the README states plainly that you "run diagnostics and re-validation only against targets you own or have explicit permission to test." That is not boilerplate — it is the line between a purple-team tool and a crime. An autonomous agent that probes systems is only ever pointed at your own lab, your own production (with authorization), or a target where you hold written permission. Everything below assumes that scope. ## How the loop actually runs Think of it as five stages, each one feeding the next: - Authorized discovery. An agent side the project calls ARTEX runs diagnostics inside your authorized scope and records evidence — not conclusions. Crucially, the README notes that finishing a job does not prove a vulnerability exists; the output is material for a human to judge. - Scenario generation. From a specific finding’s evidence, the AI drafts a multi-step attack flow, the detection points along it, and candidate Splunk SPL (Search Processing Language) queries. These are drafts — the README is explicit that they are not run or deployed automatically. - Defense validation. It re-runs the check and links your real audit and alert logs (from file or from Splunk), then judges three things separately: did the behavior reproduce, was it detected, and was it blocked? Keeping those three apart is the whole game — "we have a rule" is not the same as "the rule fired" is not the same as "the control stopped it." - Incident investigation. Point it at an asset, a time range and a path, and it prepares the logs and runs an AI investigation. The result is split into observed, inferred and unverified items, each citing the raw events behind it — so you can tell a fact from a hypothesis at a glance. - Autonomous hunting. A four-stage loop — Research → Scenario → Hunting → Verification — that runs read-only Splunk queries and stores public sources, the AI’s hypotheses, the raw Splunk events, and the final verdict as separate records. ## The agent model under the hood The offensive side is not one monolithic bot. Per the README, a **Planner** queues exploration "intents" while several **Workers** run tools inside the authorized scope and record evidence, all sharing a shared **asset graph** and a per-job **exploration graph**. A human "MainAgent" can drop in hints to steer the exploration. That Planner/Worker split is a common pattern for keeping autonomous agents bounded: the planner reasons about _what to try next_, the workers do narrowly-scoped actions, and the graph is the shared memory that stops them from wandering or repeating themselves. ## Why the guardrails are the interesting part An autonomous agent that touches security tooling is exactly the kind of system that needs **oversight by design**, and AegisLoop’s conservative choices are worth copying even if you never run it: - Evidence over verdicts. A finished job is raw material, not a confirmed vuln. This resists the "the AI said so" failure mode. - Drafts, not deploys. Generated detections are proposals a human reviews and ships — the agent never silently changes your SIEM. - Read-only hunting. The autonomous stage can look but not touch. - Observed / inferred / unverified, with citations. The single most important habit for trustworthy AI investigation: never let a model’s guess render identically to a logged fact. These map directly onto the autonomy-vs-oversight question every team adopting AI agents is wrestling with. An agent with real-world side effects is the textbook case for a [human-in-the-loop gate](/tools/hitl-decision-advisor); we wrote a whole [register of where those gates belong](/blog/human-in-the-loop-and-provenance-where-they-belong), and you can stress-test an agent’s blast radius in the [Autonomy vs Oversight Lab](/tools/autonomy-vs-oversight-lab). ## Before you run it: two practical cautions **Data handling.** The AI features call an LLM _you_ configure, and the README notes that AI investigation can send selected vulnerability evidence and log excerpts to that provider. Security logs are sensitive; choose a provider and a data-retention setting you are willing to send them to, and keep the most sensitive material out of scope if you are unsure. **Licensing and running it.** It is **AGPL-3.0** — if you modify it and offer it as a network service, the license’s source-sharing obligations apply, so loop in whoever owns open-source compliance where you work. The stack, per the README, is a Next.js web UI, a Go server and PostgreSQL, started locally via Docker Compose. Treat the first runs as a lab exercise against systems you own. ## The takeaway The idea worth stealing from AegisLoop, whatever tooling you use, is the **find-to-detect loop**: don’t stop at finding and patching a weakness — turn it into a concrete attack path, a candidate detection, and a test that proves whether your monitoring would actually catch it, judged against your own logs. That is detection engineering grounded in reality instead of generic rules. You can practice the blue-team half of that loop right now in our [Detection Lab](/tools/detection-lab) and the [detection-rule guide](/guides/how-to-write-a-detection-rule) — no agent, no setup, free and in-browser. _Educational explainer of a third-party open-source project, based on its public README. Use any security tool only against systems you own or are explicitly authorized to test._