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

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 — 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:

1. 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.
2. 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.
3. 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."
4. 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.
5. 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; we wrote a whole register of where those gates belong, and you can stress-test an agent’s blast radius in the 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 and the detection-rule guide — 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.