DEV Community: auto_majicly

From Tool-Runner to Decision Engine: Upgrading an Autonomous Security Agent's Harness

auto_majicly — Sat, 18 Jul 2026 15:28:12 +0000

Yesterday I did something that sounds like paperwork and is actually the whole point: I graduated a batch of next-gen modules out of a staging package and into the running harness of HALO, the local, autonomous offensive-security agent I've been building. "Graduated" is the operative word. These weren't new files landing in a repo — they were designs that had earned their way from a shelved halo-nextgen/ package into the live agent loop, each one wired to the parts of the system it was always meant to touch.
The interesting part isn't the diff. It's what the batch was for. Taken together, these upgrades push HALO across a line I've been circling for months: from a tool-runner to a decision engine.

The reframe

A tool-runner is what most "AI hacking" demos actually are. You give it a target, it runs nmap, it runs sqlmap, it greps the output for the word "found," and it reports back. It's a shell with a language model taped to the front. It doesn't know whether the thing it found is exploitable here, in this environment, and it cheerfully forgets everything the moment the session ends.
The characterized goal for HALO is the opposite of that: a fully-local operator that decides which exposures are genuinely exploitable in a given environment, proves it with evidence, and never re-learns the same dead end. Every module in yesterday's batch is measured against that one sentence. Here's the before/after that the redesign is chasing:

Old loop - Next-gen loop

Goal framing static tool-manual prompt goal-first ("decide, don't just run")
Success detection substring grep ("found") evidence-based validator
Memory negative-only; deletes successes tiered: negative + positive + environmental
Engagement state re-derived every call persistent case file (read/write)
Prompt injection tool output re-enters raw trust-tier guard on every output
Autonomy all-or-nothing per-action-class policy
Substring grep versus an evidence-based validator is the entire distance between a script and an operator. Everything else is in service of making that judgment reliable, safe, and repeatable.
The spine comes first
You don't get to build an autonomous offensive agent and bolt safety on at the end. The arsenal does genuinely sensitive work, and the difference between "professional weapon" and "liability" is entirely one layer: the engagement spine. So it's the first thing every action passes through, not the last.
The spine gives four guarantees, and they're enforced by construction rather than by good intentions:

Authorization — you cannot construct an engagement context without a written-approval reference and a non-empty scope. Miss either, and it throws at construction time. There is no "just this once."
Scope guard — every target is matched against an allowlist of hosts and CIDRs. Out of scope is refused and logged.
Kill switch — one call halts all further authorized action mid-run.
Chain of custody — every decision, authorized or blocked, is appended to a custody log you can export for the client. One gate answers one question — is this actor allowed to take this class of action against this target, right now? — and it answers "yes" only when the run isn't halted, the target is in scope, and the autonomy policy permits it. Either way, it writes down what it decided. An offensive agent that can't produce that log has no business in front of a client. Three upgrades, at the architecture level With the spine in place, three of yesterday's modules are worth describing — in terms of shape, not offensive specifics. Self-audit: the agent refusing to rot. You run an agent like this on a security distro that ships tool upgrades constantly, while the model labs ship technique advances on their own cadence. Left alone, any agent decays: its tools fall behind, an upgrade silently breaks one before an engagement, and its architecture drifts toward obsolete. The self-audit module is HALO turning its eyes inward on a schedule — checking tool currency, arsenal integrity (did an upgrade break something?), framework currency, and its own module health. It rolls up to one verdict: current, updates-available, or attention-needed. The deliberate line here matters more than the checks. Tools may auto-update under policy — bumping a scanner is low-risk and reversible. Architecture is never auto-changed. Frontier advances are surfaced as a backlog for me to approve, and that boundary is enforced in code: the update path touches tools only; backlog items have no auto-apply route. A security agent that silently re-architects itself is a liability, full stop. Debug mode: separate, bridged, sandboxed. A debugger's whole job is to freely write and run code. A security loop's whole job is to gate everything. Those instincts are opposites, so the design keeps them apart. Debug mode is a standalone mode behind an explicit toggle, off by default, with its own state — it doesn't run inside the attack loop or share its gating. But the engagement can still borrow it mid-run to repair a broken proof-of-concept, without flipping the whole system into debug mode. And every execution goes through a sandbox: no sandbox, no run, enforced in code. Writing-and-running code is the same risk class as the arsenal's most sensitive actions, and it's treated that way. Continuous attack-surface awareness. The scanner that keeps a live picture of a target's exposure draws its authorization from exactly one place — the engagement scope. There's no second definition of "what am I allowed to touch" to drift out of sync. Findings flow into a structured inventory the report builder can read later. Single-sourcing authorization sounds like a footnote; it's the difference between one guardrail and two guardrails that disagree. The honest part Here's where I'll disappoint anyone hoping for self-evolving-AI mythology: the "stay current with the frontier" capability is semi-automated, not magic. When online, a feed pulls changelogs and release notes, diffs them against what HALO already uses, and produces a prioritized backlog. Then I decide what to adopt. The agent can be told to implement an approved item; it does not perform structural self-surgery on its own. That's not a limitation I'm apologizing for — it's the design. Unsupervised self-modification in an offensive tool is precisely the thing you don't want. Every collaborator in the loop — model client, tool executor, control oracle, approver — is injected, which means the whole thing runs and is testable offline with stubs. The next-gen loop exercises end to end without touching a network, including a simulated prompt-injection attempt in tool output that gets caught and quarantined. If it can't be verified on my laptop with no target in sight, it isn't done. The takeaway A while back I wrote up Jason Haddix's forecast for where autonomous pentesting is heading: a small pool of elite humans on genuinely novel work, and a much larger layer of continuous agents absorbing the well-documented bug classes. Nothing in yesterday's batch changes that picture — it's an attempt to build the responsible version of the second layer. An agent that decides instead of greps, that starts from authorization instead of ending at it, that keeps itself current without letting itself off the leash. The worst-case use of a tool like this is real. But worst-case is also a spec: the same reasoning that lets you imagine the misuse is the reasoning that builds the guardrails before it's a live problem. That's the work. Purposeful risk analysis, hard boundaries in code, and a chain of custody for every decision — not panic, and not hype.

Anatomy of a Pentest Dropbox: How Remote Internal Assessments Actually Work

auto_majicly — Mon, 13 Jul 2026 13:16:16 +0000

When people imagine a penetration test, they picture someone on-site — badge on a lanyard, laptop open in a conference room. That still happens, but a large share of internal assessments now run remotely, and the device that makes it possible is the humble dropbox. It is one of the more elegant ideas in the field, and worth understanding whether you run these engagements or defend against the techniques they simulate.

The core idea

A dropbox is a small computer that lives, temporarily, inside the target's network. The client plugs it into an Ethernet port and power; from there it becomes the tester's foothold on the inside. This lets an internal assessment — the scenario where we simulate an attacker who is already past the perimeter — happen without a person physically on-site for the entire engagement window.

The hardware is deliberately unremarkable: a Raspberry Pi for a cheap, disposable unit; an Intel NUC when the work needs real horsepower; or a purpose-built commercial appliance. Whatever the form factor, it runs a standard offensive toolkit and does its work quietly.

The clever part: it calls you

The instinct is to imagine connecting into the dropbox. In practice, the client's firewall blocks inbound connections — that is its job. So the dropbox does the opposite: it makes an outbound connection to a server the tester controls, and the tester rides that tunnel back in.

This works because firewalls are strict about traffic coming in and permissive about traffic going out. Employees browse the web all day, so outbound connections look normal. A well-built dropbox blends into that traffic — a tunnel over a common port, or wrapped in ordinary-looking protocols — and re-establishes itself automatically if it reboots or the link drops. That persistence matters; a power blip should not end the engagement.

If this "phone home to my server" pattern sounds familiar, it should. It is the authorised, physical cousin of the command-and-control technique that real intrusions rely on. The difference is entirely one of permission.

Where the actual work happens

A common misconception is that the dropbox is just a doorway. It is better thought of as the workstation. Because it sits inside the network, it is the right place to run the scanning and enumeration — traffic stays local and fast, rather than crawling back and forth through a tunnel. The tester connects in to drive it, but the tooling executes where the targets are. Design the device as the machine that does the job, not merely a relay.

Why clients like it

Remote internal assessments cut travel cost and scheduling overhead, and — this is the part that matters most — they are a more honest simulation. A real attacker does not stand in your server room. They establish a foothold and operate remotely, patiently, over an encrypted channel. A dropbox mirrors that threat model precisely, which makes the findings more representative of an actual breach.

The part that comes before the cable

None of this begins until the paperwork is signed. A dropbox is inert without a Rules of Engagement document that names the exact IP ranges, hosts, and time windows in scope, states what is explicitly off-limits, and lists an emergency contact. That authorisation is not bureaucratic friction; it is the line between a professional assessment and a crime, and it is also what tells you which segments of the network you are even permitted to touch.

The defender's takeaway

If you protect a network, the dropbox is a useful lens. It thrives on two assumptions: that anything already inside is trusted, and that outbound traffic is benign. Both are worth challenging. Network segmentation limits how far a foothold reaches. Egress filtering and monitoring for anomalous outbound connections — beaconing to unfamiliar hosts, tunnels over odd ports — turn the dropbox's quietest advantage into its loudest tell. The same visibility that would catch an authorised tester's device is exactly what catches the real thing.

# Online vs. Offline Password Attacks: A Field Guide

auto_majicly — Sun, 12 Jul 2026 14:51:09 +0000

Password attacks are one of the first things people learn in offensive security, and one of the most commonly muddled. The confusion usually comes down to a single distinction that determines which tool you reach for, how fast you move, and how much noise you make: is the attack online or offline? Getting this wrong wastes hours and, in a real engagement, can lock accounts and blow your cover. Here is the field guide I wish I had early on.

Online attacks: guessing against a live service

An online attack throws credentials at a running service — SSH, RDP, a web login, a database — and waits to see what sticks. Tools like Hydra, Ncrack, and Medusa live here. You use them when you do not yet have valid credentials and you are trying to find some against a service that is actually listening.

The defining traits of online attacks are their constraints. They are slow, because every guess is a full network round-trip. They are loud, generating authentication logs with every attempt. And they are fragile, because account lockout policies, rate limiting, and fail2ban-style tooling will stop you — or worse, lock out the very accounts you are testing. In practice this means being surgical: a short, high-probability wordlist against a high-value service beats blindly hammering everything. Telnet and other slow protocols are rarely worth the time.

Offline attacks: cracking captured hashes

An offline attack works against password hashes you have already obtained — from a dumped database, a captured /etc/shadow, a network capture, or a memory dump. Tools like John the Ripper and Hashcat own this space. Here there is no live service in the loop at all; you are running computation against data you already hold.

That changes everything. Offline attacks are fast, bounded only by your hardware — a GPU can try billions of candidates per second against a weak hashing scheme. They are silent, because the target sees nothing; there is no service to log your attempts. And they are unlimited, with no lockout to stop you. The catch is that you had to obtain the hashes first, and the difficulty scales enormously with the hashing algorithm: a fast, unsalted hash falls quickly, while a modern, deliberately slow scheme can resist cracking indefinitely.

The decision that trips people up

The mistake I see most often is reaching for an online brute-forcer when the situation calls for offline cracking, or vice versa. Three cases make it clear:

You have no credentials and a live service is exposed. This is online territory — Hydra, Ncrack, Medusa — used carefully and sparingly.
You found password hashes. These go straight to offline cracking with John or Hashcat. Do not point an online tool at anything.
You found actual plaintext credentials. You do not brute-force at all. You reuse them — credential stuffing and password spraying across other systems — because people recycle passwords everywhere, and one valid pair is often the key to many doors.

Knowing which of these three you are in tells you exactly which tool to open, before you waste a cycle.

The defender's mirror

Every property that makes these attacks work is something a defender can take away.

Against online attacks: enforce rate limiting and sensible lockout thresholds, monitor authentication logs for spikes, prefer key-based authentication over passwords where possible, and put multi-factor authentication in front of anything that matters. These measures turn a slow attack into an impractical one.

Against offline attacks: assume your hash store will eventually be exposed and design for that day. Use a modern, deliberately slow, salted hashing algorithm — the kind built to resist GPU cracking. Salting defeats precomputed tables; slowness defeats brute force. And enforce password length, because length is the single factor that scales cost fastest for the attacker.

The through-line is simple. Offensive and defensive password work are two views of the same mechanics. Understand which attack applies to which situation, and you will not only choose the right tool as a tester — you will know exactly where to spend a defender's budget.

[Boost]

auto_majicly — Fri, 10 Jul 2026 21:03:56 +0000

auto_majicly

Jul 10

# Getting Listed: Publishing an Offensive-Security Agent to the MCP Registries

#ai #mcp #python #cybersecurity

3 min read

# Getting Listed: Publishing an Offensive-Security Agent to the MCP Registries

auto_majicly — Fri, 10 Jul 2026 21:02:46 +0000

The Model Context Protocol ecosystem has grown fast, and with it a handful of registries that have become the front door for discovery. If you have built an MCP server and nobody can find it, you have built half a product. This week I took HALO — my local, autonomous security agent — through the full listing process across every major registry. Here is the practical walkthrough, in the order that actually works.

Step 0: Make it a real MCP server first

This is the step most people skip, and it is the one that gates everything else. It is not enough to call something an MCP server. The registries inspect your repository, launch the server, and enumerate its tools. If it does not speak the protocol, it fails silently and you never understand why.

The cleanest architecture separates transport from execution. I moved my tool logic into a single transport-agnostic engine, then put two thin layers on top: a spec-compliant MCP server that speaks JSON-RPC over stdio using the official SDK, and the existing local interface my agent already used. Defining the tool schemas once, in one registry, means both layers stay in sync and there is no drift.

I also added a server.json manifest at the repository root. Several registries read it directly, and it signals that you know what the ecosystem expects.

The test that matters: a real MCP client should be able to initialize, call tools/list, and get back your full arsenal with valid input schemas. If that round-trip works, you are ready to submit. If it does not, no registry will save you.

Step 1: Glama

Glama indexes MCP servers directly from GitHub and assigns each a quality score. Once your repository is a genuine server, sign in, submit the repo, and let its inspector do the work. The payoff is a live score badge you can embed anywhere — and, more importantly, that badge is what several other directories validate against. Glama is the keystone; get it green first.

Step 2: awesome-mcp-servers (punkpeye)

The largest community list. Contribution is a straightforward pull request: find the correct category, match the existing entry format exactly — repository link, score badge, language and scope emoji, then a one-line description — and add your line. An automated check validates the submission against Glama. Because I had already earned a Glama score, that check passed cleanly, and the PR dropped into the merge queue.

Two details save time: match the neighbours' formatting precisely, and do not fight the review automation. A skipped "welcome" workflow is not a failure; the submission check is the one that counts.

Step 3: awesome-mcp-servers (TensorBlock)

A different list with a different process. Instead of hand-editing a giant README, TensorBlock offers an "Add MCP server" issue form and drafts the pull request for you from the fields you provide. Lower friction, fewer formatting mistakes. Pick your category, describe the server plainly, and submit.

Step 4: mcpservers.org

A hosted directory with a simple submission form: name, description, link, category, contact email. Free listings are the default; ignore the paid "premium" upsell unless speed genuinely matters to you. Choose the most honest category available — a precise "Other" beats a wrong label that buries you under the wrong search.

What I would tell my past self

The engineering comes before the marketing. A registry submission is only as good as the server behind it.
Glama first. Its score is the currency the other lists trade on.
Match each destination's format on its own terms; they are not interchangeable.
Be accurate in your metadata. Miscategorising to chase visibility costs you the audience you actually want.

None of these steps is hard on its own. The discipline is doing them in the right order, and refusing to submit anything until the thing you are submitting is real. Do that, and a project goes from invisible to discoverable in an afternoon.

I Built a Fully Local, Autonomous AI Pentesting Agent — Now I’m Teaching It to Speak MCP

auto_majicly — Thu, 09 Jul 2026 20:26:24 +0000

⚠️ Everything here is for authorized security testing and research only — systems you own or have explicit written permission to test.

A few months ago I set myself a stubborn goal: build a penetration-testing agent that runs entirely on my own machine — no cloud, no API keys, nothing leaving the laptop — that could plan an engagement, run its own recon, chain attacks based on what it finds, and write up the findings on its own.

That project became HALO (I ship it as GEMMA-by-GOOGLE). It’s driven by a local Gemma model in LM Studio and a Python agent loop that calls out to a server exposing ~29 security tools. It’s fully offline, and it’s the thing I’ve learned the most from this year.
This post is about the part I got wrong first, and the standard I’m now rebuilding it around: the Model Context Protocol (MCP).

What HALO actually does

The design is a small crew of specialist agents passing a shared message format:
• a planner turns a goal into an ordered plan
• an orchestrator routes each task to the right specialist
• a vuln-discovery agent surfaces candidates
• an attacker branches into vuln-class specialists (SQLi, brute force, IDOR, SSRF, XSS, auth)
• a validator confirms findings against real evidence before they count
• a debugger diagnoses failed tool runs and adjusts

One of my favorite pieces is a persistent negative-experience cache. Every tool call gets fingerprinted. Fail once → one retry. Fail twice → it’s blacklisted, and the agent moves on to a better tool for the job. Over an engagement it stops wasting cycles on dead ends it has already proven don’t work — trial-and-error that persists across sessions.

At the end, everything compiles into an HTML report. One command starts the whole thing: engage .

The wall I hit: my tools were bolted on

Here’s the honest part. When I wired those ~29 tools in, I did it the fastest way I knew: a Flask HTTP server with a couple of routes. The agent POSTs {tool, params}; the server runs the tool and returns the result. It works. It’s been working for months.

But it’s bespoke. My agent is the only thing that knows how to talk to it. If I wanted to use those same tools from another client — say, a desktop AI app or an editor — I’d have to reimplement the glue every time. The tools were locked inside my one custom protocol.

That’s exactly the problem MCP was built to solve.

What MCP is (the 60-second version)

The Model Context Protocol is an open standard for connecting LLM applications to external tools and data. Instead of every app inventing its own way to expose “here are my tools, here’s how to call them,” MCP defines a common one:
• a server exposes capabilities — tools, resources, prompts
• a client (the LLM app) connects, calls tools/list to discover what’s available, and tools/call to run them
• it speaks JSON-RPC over a transport like stdio or HTTP/SSE

The payoff is interoperability. Write your tools as an MCP server once, and any MCP-aware client — Claude Desktop, Cursor, Cline, and a growing list of others — can use them without custom glue. Your capability becomes portable.

When it clicked for me, it was obvious: my Flask server is a worse, private version of a thing that already has an open standard.
Why I’m rebuilding HALO’s tool layer as a real MCP server

So that’s the next build. Concretely:
1. Wrap the existing tools with the MCP SDK. Each of my run_* functions becomes a registered MCP tool with a typed schema, exposed via tools/list / tools/call — instead of my ad-hoc POST /.
2. Serve over stdio so any MCP client can launch and introspect it.
3. Ship a Dockerfile so it starts in a clean environment and can be verified.
What this unlocks:
• Plug HALO’s arsenal straight into Claude Desktop / Cursor / Cline — the same recon and analysis tools, now usable from any MCP client, not just my agent loop.
• Keep it local. MCP doesn’t mean cloud. The server still runs on my machine; the model still runs in LM Studio. Nothing about adopting the standard changes the “fully offline” promise — it just standardizes the interface.
• Portability. I do this work on a travel VM that goes with me. A standard interface + a Dockerfile means “it runs the same everywhere” stops being a hope.
Lessons so far
• “It works” and “it’s reusable” are different milestones. My Flask server passed the first bar for months while quietly failing the second. Standards are how you cross the second one without a rewrite every time.
• Adopt the protocol, keep your architecture. My multi-agent crew, the negative-experience cache, the reporting — none of that changes. MCP is about the tool interface, not the brain.
• Local-first and standards-based aren’t in tension. MCP over stdio is arguably more local than my HTTP server was.
• Name things honestly. I’d been loosely calling my Flask layer an “MCP server.” It wasn’t one. Fixing that — making the name true — is half of why this next build matters.

Follow along

HALO is open source (MIT). The multi-agent code, the tool server, and the docs are all in the repo, and the real MCP interface is the next thing landing:
👉 https://github.com/XenoCoreGiger31/GEMMA-by-GOOGLE

If you’re building local-first AI tooling — security or otherwise — I’d love to hear how you’re thinking about MCP. And if you want the follow-up (“here’s exactly how I converted a Flask tool server into a spec-compliant MCP server, with a Dockerfile”), that post is coming once the build lands.
Build for systems you’re allowed to touch. Stay legal, stay curious.

[Boost]

auto_majicly — Wed, 08 Jul 2026 22:43:24 +0000

auto_majicly

Jul 8

Your autonomous agent will lie to you about success

#discuss #cybersecurity #ai #llm

4 min read

[Boost]

auto_majicly — Wed, 08 Jul 2026 22:36:02 +0000

auto_majicly

Jul 8

Your autonomous agent will lie to you about success

#discuss #cybersecurity #ai #llm

4 min read

Your autonomous agent will lie to you about success

auto_majicly — Wed, 08 Jul 2026 22:35:32 +0000

I’m building an autonomous pentesting agent. Last week it told me an attack succeeded. It hadn’t. The bug that let it lie is one every agent builder will hit eventually, so here’s the story and the fix.
The setup
The agent can write and run custom Python when its standard tools fall short. Running model-authored code on your host is obviously a bad idea, so that path goes through a sandbox: a rootless Podman container with two phases. A test phase with no network at all (--network=none) to prove the script runs, then an attack phase with networking enabled to run it against the real target. Each phase is behind a human approval gate.
I gave it a simple goal to smoke-test the whole thing: connect to an FTP server on my lab target and print the banner.
The thing that looked like success
Both phases printed the banner:

Both phases printed the banner:

--- TEST PHASE OUTPUT (isolated, no network) ---
220 (vsFTPd 2.3.4)

--- ATTACK PHASE OUTPUT (target: 10.x.x.x:21) ---
220 (vsFTPd 2.3.4)

[GATE] Attack phase succeeded
--- TEST PHASE OUTPUT (isolated, no network) ---
220 (vsFTPd 2.3.4)

--- ATTACK PHASE OUTPUT (target: 10.x.x.x:21) ---
220 (vsFTPd 2.3.4)

[GATE] Attack phase succeeded

--- TEST PHASE OUTPUT (isolated, no network) ---
220 (vsFTPd 2.3.4)

--- ATTACK PHASE OUTPUT (target: 10.x.x.x:21) ---
220 (vsFTPd 2.3.4)

[GATE] Attack phase succeeded

Looks great. It’s also impossible.
The test phase runs with no network. A socket connect to a remote FTP server from inside that container cannot succeed — it should throw “network unreachable.” But it printed a live banner, identical to the attack phase. If the sealed room and the open room both report “I can see outside,” either the room isn’t sealed or someone taped a photo to the wall.

Two bugs wearing one costume

Bug one: the sandbox wasn’t running. The service was launching from a stale copy of the code — an older path left over from a refactor. That copy predated the sandbox entirely, so “test phase, no network” was just a label being printed. Both phases were running the same unsandboxed code on the host, twice. The banner was real; the isolation was fiction.
Fixing the service to point at the current code brought the actual sandbox online. Now the test phase correctly failed with Network is unreachable, and only the attack phase got the banner. Good.
Bug two, the interesting one: the success check was a lie detector that always said “truth.” The gate decided success like this:

ok = result.get("status") == "success"

And status was set from the exit code of the sandbox runner — not the script inside it. The runner can exit 0 (it did its job: it ran the container) while the script inside printed nothing, threw an exception, or ran against a placeholder target the model forgot to fill in. Exit 0 meant “I successfully ran something,” not “the something worked.”
This is the trap. An agent’s tools report on themselves, and they’re generous. Left alone, the agent banks these false successes as progress and moves on, building a plan on top of steps that never happened.
The fix: trust the output contract, not the exit code
The sandbox already emits a structured block for every run:

=== STDOUT ===

=== STDERR ===

=== EXIT ===

So instead of trusting the runner’s exit code, parse the sandbox’s own contract and judge the inner result:

raw = result.get("stdout", "")

inner_exit = None
for line in raw.splitlines():
t = line.strip()
if t.startswith("=== EXIT ") and t.endswith("==="):
n = t[9:-3].strip()
if n.isdigit():
inner_exit = int(n)

inner_stdout = ""
if "=== STDOUT ===" in raw and "=== STDERR ===" in raw:
inner_stdout = raw.split("=== STDOUT ===", 1)[1].split("=== STDERR ===", 1)[0].strip()

if inner_exit is None:
fail("no exit marker from sandbox")
elif inner_exit != 0:
fail("script exited non-zero")
elif not inner_stdout:
fail("no output; no-op treated as failure")
elif "TARGET_IP" in code: # model left a placeholder
fail("placeholder target, not a real run")
else:
succeed()

Note there’s no regex here. My first version used one, and a stray trailing newline in the output made the pattern miss, which flipped the guard to a false negative — now it failed real successes. Plain string splitting on the markers is boring and it doesn’t care about whitespace. Boring won.

The takeaways

If you’re wiring tools into an agent, three things earned their keep:

Exit code 0 is not success. It means a process ended without crashing. Whether the task succeeded is a separate question your tool has to answer explicitly. Define what “worked” means — non-empty output, an expected marker, a parsed field — and check for it.
A test that can’t fail isn’t testing anything. The whole bug was invisible until the isolated phase started correctly failing. If your “isolated” mode never errors, it isn’t isolated.
Watch for placeholder output. Models will happily hand you TARGET_IP or example.com and a green checkmark. Treat obvious placeholders as failure, not success.

The guard is deliberately strict: no-op, error, empty output, or placeholder all report failure. I’d rather the agent retry a real success it undercounted than march forward on a fake one it believed.
Verified end-to-end against a local lab target: test phase blocks the network, attack phase returns the real banner, and a deliberately empty script now correctly reports failure instead of success.
If you’re building in this space, I’d genuinely like to hear how you’re validating tool results — the exit-code trap feels like something a lot of people hit quietly.

[Boost]

auto_majicly — Wed, 08 Jul 2026 16:58:52 +0000

auto_majicly

Jul 8

# Wiring Real Agents Into Halo: From Stub Orchestrator to a Working Multi-Agent Pentest Pipeline

#discuss #ai #programming #cybersecurity

2 min read

# Wiring Real Agents Into Halo: From Stub Orchestrator to a Working Multi-Agent Pentest Pipeline

auto_majicly — Wed, 08 Jul 2026 16:58:41 +0000

Yesterday I had five agent roles sketched out on paper. Today I actually wired them together and watched them run a real engagement against a live target — and immediately hit (and fixed) the kind of bug you only find by running the thing for real.

The Starting Point

Halo's orchestrator has existed for a few days, but it was routing tasks to stub agents — fake stand-ins that printed a success message and moved on. That was intentional: prove the routing logic works before wiring in real specialists. Today was "swap the stubs for the real thing" day.

What Got Built

wafw00f integration. Added WAF/security-solution fingerprinting as tool #25, slotted into the recon workflow right after initial HTTP probing — check for a WAF before throwing aggressive scans at a target, not after.

Attacker as a router, not a monolith. The Attacker agent now branches into vuln-class specialists — SQLi, credential brute-forcing, IDOR, SSRF, XSS, and auth/session issues — instead of one generic "go attack it" prompt. Each branch maps to the tool actually suited for that vuln class.

A real Validator stage. This is the piece that was missing entirely. Attacker's claimed findings now get checked against confirmation signals before they're counted — a "confirmed vulnerable" result requires the actual evidence (e.g. sqlmap explicitly confirming an injectable parameter), not just "a tool ran and returned some text." Unconfirmed findings get flagged for manual review instead of silently disappearing or silently passing as real.

Real reporting. Confirmed and unconfirmed findings now compile into a client-readable markdown report, written per-engagement.

The Bug That Made It Real

First live run against my own router: Attacker fired off searchsploit — with the target's raw IP address as the search keyword. Of course it found nothing; searchsploit needs a product/service name, not an IP.

The fix: pass Vuln Discovery's actual findings (service banners, versions) into Attacker as context, then extract just the relevant service string before it ever reaches searchsploit. Second bug surfaced immediately after: a later, empty recon result was overwriting an earlier good one before Attacker got to use it — classic last-write-wins. Fixed by only updating captured context when the new result is non-empty.

End state: Attacker correctly searched dnsmasq 2.83, searchsploit correctly returned "No Results," and Validator correctly logged it as unconfirmed. Not a flashy win — but an honest one. The pipeline reported the true state of the target instead of a hallucinated finding.

Why This Matters More Than It Sounds

A pentest agent that never says "no exploit found" isn't trustworthy. Building the validation and honest-negative-result path in from day one, rather than bolting it on later, was the actual point of today's work — not just to get more findings, but to get correct ones.

What's Next

Sandbox execution for agent-written PoC/exploit code, so Attacker can go beyond canned tools when a target calls for something custom.

SkillCloak Exposes a Dangerous Blind Spot in AI Security

auto_majicly — Tue, 07 Jul 2026 16:36:36 +0000

As AI coding assistants continue to grow in popularity, so does the attack surface surrounding them. A newly disclosed technique known as SkillCloak demonstrates how malicious AI “skills” can bypass traditional static security scanners while still executing harmful code once installed.

Researchers from the Hong Kong University of Science and Technology found that attackers can disguise malicious skills by hiding their payloads in locations that many scanners ignore or by slightly altering their structure without changing their functionality. The result is alarming: these modified skills were able to evade detection in more than 90% of the scanners tested.

The bigger concern is that AI agent skills often execute with the same permissions as the user. That means a malicious skill could potentially access sensitive files, steal credentials, exfiltrate source code, or even establish persistence on a system without raising immediate suspicion.

The research also highlights an important shift in defensive strategy. Instead of relying solely on static analysis, security tools should increasingly monitor a skill’s behavior at runtime. Observing what a skill actually reads, writes, and transmits provides a much stronger indication of malicious activity than simply inspecting its contents before installation.
As AI ecosystems continue to expand, this serves as another reminder that trust should never be based on appearance alone. Whether you’re using AI coding agents in development or production, installing skills only from trusted sources, limiting their permissions, and adopting runtime monitoring will be essential steps in reducing risk.
This article is based on reporting by Swati Khandelwal at The Hacker News and research published by the Hong Kong University of Science and Technology.