DEV Community: auto_majicly

It is still happening as we speak. I needed a github repo url for a tool, and THAT too was blocked.

auto_majicly — Thu, 20 Aug 2026 22:29:21 +0000

auto_majicly

Aug 20

When the Safety System Becomes the Threat Model: A Case Study in Classifier Drift

#ai #claude #security #cybersecurity

6 min read

When the Safety System Becomes the Threat Model: A Case Study in Classifier Drift

auto_majicly — Thu, 20 Aug 2026 22:27:20 +0000

Field notes from 43 hours of legitimate security research, 35 false-positive blocks, and one
support form.

The setup

I do authorized bug bounty work and CTF practice. My toolchain is unremarkable by design: the
usual ProjectDiscovery/OWASP staples — subfinder, httpx, nuclei, katana, naabu, dnsx,
amass — plus ffuf, gobuster, arjun, bbot. Nothing bespoke, nothing evasive, nothing that
wouldn't show up in any security bootcamp's syllabus. I use Claude as a research and
documentation assistant alongside my OWN dev tool HALO, that I have been developing over the course of about six months(roughly). I use these toolchains, on training platforms explicitly built to be
practiced against, learned from and exercised. And I pay for the Cluade PRO plan as a means of learning and having an assistant ten times smarter than myself.

Over a 43-hour window, that combination — legitimate work plus an AI assistant with a
cybersecurity safeguard — produced 35 blocked requests. This is a writeup of what the block
pattern actually looked like, because the pattern is the interesting part. It isn't "the filter
is too strict." It's that the filter appears to be scoring the wrong thing. And by 'wrong thing' I mean even un-related normal language messages and requests.

The headline case: blocked for writing an ethics checklist

The densest cluster was ten blocks in four minutes and thirty-three seconds. The request,changed and re-phrased, also unchanged (no matter what I did),
across all ten attempts: write a markdown template for reporting bug bounty findings.

The document that eventually made it to disk — after the eleventh try succeeded — is 513 lines
across four files: a submission skeleton, a CVSS severity guide, a README, and a pre-submission
checklist. The checklist is the file that was open when block six through ten fired. Its contents:

- [ ] The asset is explicitly in scope for this program, today
- [ ] Testing stayed within the program's rules (no DoS, no social engineering,
      no automated scanning if prohibited, no third-party accounts)
- [ ] I stated a concrete attacker outcome, not a capability
- [ ] I did not overclaim (no "full server compromise" for a reflected header)
- [ ] Secrets, tokens, and third-party PII are redacted
- [ ] I deleted test data, injected records, and uploaded files I created
- [ ] I did not retain third-party data
- [ ] No production users were affected
- [ ] Tone is neutral and collaborative — no demands about bounty amount

That's a responsible-disclosure ethics document. It instructs the reader to stay in scope, avoid
denial of service, redact third-party data, and delete their own test artifacts. If a classifier's
job is to catch material that increases risk, this is close to the least risky text a security
practitioner could type. It got blocked more times than anything else in the sample.

The control case that makes the point

The same account, the same day, the same client. Earlier that evening I ran a 43-minute CTF
session — 204 messages, live enumeration and credential testing against a practice box, the actual
offensive work the safeguard exists to gate.

Zero blocks.

Side by side:

	CTF session (`df828311`)	Report-template session (`e6f361c6`)
Activity	live offensive operation	writing a markdown document
Messages	204	~12
Duration	43 minutes	~5 minutes
Blocks	0	10

Whatever the classifier is weighting, it isn't operational risk. The session where I was actually
doing the thing the safeguard is presumably designed to catch ran clean start to finish. The
session where I was documenting how to do that thing responsibly did not. And to make matters worse, writing this article you are currently reading was also blocked.

The pattern that best fits the data: block density tracks accumulated conversation context —
how much security vocabulary has built up over the session — rather than the risk content of any
single request. A stable, unchanging request (write a template) got a different verdict each of
eleven times it was submitted in the same conversation. That's not how a per-request classifier
behaves. It's how a classifier scoring cumulative context behaves.

Two failure modes that compound it

It fires on output, not just input. Several blocks truncated the assistant's own reply
mid-sentence — once while it was in the middle of advising me to keep scope notes in a local file
instead of chat. From inside the session, a mid-word cutoff is indistinguishable from a network
hiccup or a length cap. It isn't labeled as a refusal. This led the assistant, twice, to
confidently tell me the truncation wasn't censorship and to suggest I use plainer terminology —
advice that would have increased the block rate, not decreased it. The failure mode doesn't just
degrade the experience; it actively misinforms the system's own operator about what's happening.

It fires on meta-discussion of itself. I tried, deliberately, to describe the blocking problem
using zero security terminology — just "I sent a message and it got blocked." That message was
blocked too. So was a follow-up attempt to make the same point. There was, in that stretch, no
available phrasing that got a plain factual report of the bug past the filter meant to catch
security content.

Put together: a request gets silently dropped, the assistant doesn't know it was dropped, it
retries or re-explains, and each retry is itself scored against an already-elevated context
window. Support documentation for the underlying system describes an escalating filter that
tightens with repeated triggers and cools off after a quiet period. If that's accurate, the retry
behavior isn't neutral — it's the thing generating the escalation. One legitimately blocked
request can silently become ten logged violations against the account, without the user or the
assistant ever being told a block occurred.

Why this matters beyond one annoyed user

The stated purpose of a cybersecurity safeguard is presumably to reduce uplift for offensive
misuse while still serving people doing the work legitimately — pentesters, bounty hunters,
defenders, students. A classifier that blocks the ethics checklist ten times and waves through 43
minutes of live target enumeration is optimizing for something other than that goal. If anything,
the current calibration selectively suppresses the exact material — scope discipline, redaction
practices, responsible severity claims — that makes offensive-security work safer to produce,
while letting the higher-capability activity through untouched. That's the opposite of the
intended tradeoff.

There's also a plain usability cost. I pay for this specifically because the model is useful in
this domain. The current behavior means the subscription is least usable for the exact reason I
bought it.

What I filed

I compiled a full evidence document — request IDs, timestamps, session breakdowns, the control
case, verbatim excerpts of the blocked content — and re-applied to the program that governs an
exemption from this safeguard, after an earlier application had been declined.

The medium-length version of that appeal, roughly what I'd want a reviewer to actually read:

I'm a Claude Pro subscriber and an individual security researcher doing authorized bug bounty
work and CTF practice. I previously applied to the Cyber Verification Program and was declined.
I'm asking for that decision to be re-reviewed against logged request data rather than a
description of intent.

Between two dates my account logged 35 blocks citing "a cybersecurity topic." All 35 request IDs
are recoverable from local session logs and verifiable server-side.

The densest cluster — ten blocks in four minutes and 33 seconds — occurred while asking for a
markdown template for reporting findings professionally. Not an exploit, not a payload, not a
target: a document about stating impact honestly, avoiding overclaiming, confirming scope, and
deleting test data. Later the same evening, working a CTF box that exists solely to be practiced
against, the blocked messages included requests to name a working directory.

The control case: a 43-minute capture-the-flag session, 204 messages of live work against a
practice target, produced zero blocks. The session asking for documentation guidance drew ten.
Whatever is being scored, it isn't the risk posed by the request.

Rephrasing doesn't reliably help. Vocabulary was sanitized — no tool names, no site names, no
mention of the field — and blocks continued. One blocked message contained no security
terminology at all; it only described the fact of being blocked.

The program's own documentation states that eligible applications are occasionally declined
incorrectly. This is offered as evidence that this account is one of those cases, and as a
request to be evaluated as what it is: legitimate work in a defensive field, using publicly
distributed tooling, on systems built to be practiced against.

That's the version sized for a standard appeal text box — long enough to carry the control case
and the request-ID anchor, short enough that a reviewer will actually finish it. A one-paragraph
version and the full 35-entry evidence log exist alongside it for forms with tighter or looser
limits.

The uncomfortable summary

None of this is an argument that the safeguard shouldn't exist. It's an argument that the current
implementation can't currently tell the difference between doing the risky thing and writing a
checklist about how not to do the risky thing badly — and that the difference matters, because one
of those outputs is the thing that makes the other one safer.

My AI pentester popped 3 root shells and told me the other 20 failed. Good.

auto_majicly — Tue, 18 Aug 2026 20:29:28 +0000

I spent a whole day this week making my autonomous pentesting agent slower. On purpose, sort of. Here's how that happened, and why it turned into the most honest day of building I've had in a while.

Some context: I'm ~6 months into teaching myself to code, and I'm building HALO — a local, self-owned pentesting agent driven by a small model running on my own hardware. No cloud API, no $475/yr scanner subscription. The goal isn't to pop the easy boxes. It's to build something that hunts the bug after the easy three, on targets that aren't gift-wrapped.

The fix that didn't exist
The day started with a "speed fix." My model calls were taking ~90 seconds each, and an engagement was crawling. The obvious move: cap the model's output tokens so it stops rambling. Small change. Ship it.

It made everything worse.

The runs got faster and started failing completely — the agent would find all the open ports and then just... give up on every one. When I finally pulled the actual logs instead of guessing, the truth was ugly and simple:

The model I'm running is a reasoning model. It burns ~1,200 tokens thinking in a hidden channel before it writes a single token of the answer I actually need. My token cap was set below the thinking budget. So the model would think, hit the ceiling mid-thought, and return an empty string. Every "smart" cap I added was decapitating the answer.

The kicker: capping tokens can't speed up a reasoning model at all. The slowness was just... the model. On my hardware, that's the floor. There was no speed fix. I'd spent hours optimizing a lever that doesn't exist.

Lesson one: read the logs before you theorize. I knew this. I did it anyway. The receipts were 30 seconds away the whole time.

The part I'm actually proud of
Once the agent could think again, I watched it work a lab box (a deliberately-vulnerable Metasploitable VM — the standard punching bag). And here's the thing that made the whole day worth it.

The agent has three curated exploits it knows work. It fired them and came back with this:

HALO-EVIDENCE nonce=1a837238e19fc8fb56014af0 level=shell uid=0 user=root host=metasploitable
root@metasploitable:/#
That nonce is the whole point. My orchestrator mints a fresh random string for each attempt, and the only way that string shows up in the output is if a real shell on the target actually ran the payload and echoed it back. The exploit script can't fake it. The model can't claim it. A banner that says "root" doesn't count. The system cannot grade its own homework — it has to produce a receipt minted by something outside itself.

This is the idea you and I keep circling back to in the comments here: don't trust a component's self-report. Make it prove the claim with something it couldn't have forged. My agent popped three genuine root shells, and I believe it because I made it hard for it to lie to me.

And then it fired at everything else — and told me it failed
Here's the honest ending. Beyond the three curated exploits, I'd just wired up a Metasploit pipeline so the agent could reach for the ~2,000 exploit modules Metasploit knows. Watching it run against the other 20 open ports was humbling:

It fired an Apache 2.4.49 exploit at Apache 2.2.8. (The name matched. The version was nonsense.)
It picked heavyweight staged payloads where a dead-simple command shell would've been more reliable.
It reached for a MySQL exploit that needs credentials it didn't have.
Every single one of those came back "Nothing worked on port X." Not a fake success. Not a padded number. The exact same nonce gate that confirmed the real root shells refused to confirm the ones that didn't land.

That's the feature. A tool that lies to you about coverage is worse than useless — it's dangerous. Mine popped three and honestly told me the other twenty didn't work, and why, in the logs. That "why" is my whole to-do list for next week.

Where I actually landed
When I committed the day's work, I made myself write the honest version of the message. Not "working Metasploit path." The real one:

Curated PoCs pop nonce-verified root reliably; the MSF path fires end-to-end but session-landing refinement is still pending.

Both halves of that sentence are true, and I only know they're true because the system won't let me round up.

Two kinds of honesty came out of one day:

The agent's — it can't claim a breach without a receipt it couldn't forge.
Mine — I committed what's real and labeled what isn't, instead of shipping a hype commit.
They're the same principle, pointed in two directions. If I'm going to build something I actually trust to point at a target, both have to hold.

Still a long way from the thing I want. But it's a long way built on receipts instead of vibes — and after a day that started by optimizing an imaginary problem, I'll take it.

What's the ugliest "the system was grading its own homework" bug you've caught in your own builds? I'm collecting them.

Green Tests, Zero Shells: What a Live Target Taught Me About Autonomous Exploit Agents

auto_majicly — Mon, 17 Aug 2026 23:05:05 +0000

I spend most of my time building an autonomous security agent — it recons a target I'm authorized to test, picks exploits, and tries to prove access, all against my own lab boxes. This week I rebuilt the brain of it, watched every test pass, ran it against a live target, and it popped nothing. Not because the model was dumb. Because my tests were quietly lying to me. AGAIN... so, how is this possible...AGAIN?

Here's the whole story, because the mistake is more useful than the feature.

The thing I built
The old design was a frozen plan. A planner decomposed the goal into an ordered list of subtasks once, up front, and an executor walked that list in order. That's fine until reality disagrees with the plan — a port you didn't expect, an exploit that fails, a service that isn't what the banner claimed. A frozen list can't react. It just marches.

So I replaced it with a closed loop. Every iteration, the policy gets the full current state plus everything that's already failed, and picks one next action. Act, fold the result back into the belief state, re-plan. The planner stopped being a one-shot decomposer and became a per-step policy.

The part I care about most isn't the loop — it's the teeth and the instrumentation, because an autonomous thing that can't stop or can't be measured is a liability, not a tool:

Termination teeth, checked before every action: an iteration budget, a wall-clock deadline, a kill switch, and a stall detector (belief state stopped changing → stop). Plus a repeat guard: if the policy re-emits an action it already tried, don't re-run it — count it as a repeat.
An adaptation score. Every re-plan logs whether the new action was genuinely novel or just a reshuffle of things already tried. Over a run you get novel / total. The whole point: measure whether the model actually adapts, instead of assuming it does. A number that can embarrass me is worth ten that flatter me.
Honest breach confirmation. Success is never the model's say-so. A breach only counts on real evidence, checked by code the model doesn't control. Don't let the system grade its own homework.
Tests: green across the board. Deploy. Run.

Zero shells
First real run against the lab target, the model reconned fine, then started working ports. And on the one port that should be the easiest win in the whole box — a service with a well-known backdoor, the kind of thing that pops every single time through the old path — the log said:

Nothing worked on port 21.

Zero breaches. Over sixteen iterations. And here's the part that saved me from blaming the wrong thing: the model had picked the right target. It correctly identified the vulnerable service and chose to attack it. Its judgment was fine. Something downstream ate the win.

The tests were encoding a fiction
The old, proven path confirms this exact exploit through a challenge–response nonce. The agent mints a single-use token, the exploit has to echo that token back inside a structured evidence line as proof it actually ran our command — not a banner, not a reflected string, an execution-derived fact bound to that one attempt. It's the anti-cheat that stops a tarpit or a reflector from faking a shell.

The new gated attack path… never minted the nonce. So the exploit fired, produced its nonce-bound proof, and the confirmer had nothing to check it against. No token in, no confirmation out. "Nothing worked."

But my tests were green. Why?

Because the tests fed the confirmer a raw uid=0(root) string and asserted "breach confirmed." That was true once — before the nonce hardening. After the hardening, the real exploit stopped emitting a bare uid=0 banner and started emitting the structured, nonce-bound line instead. The tests kept using the old fake evidence. So they exercised a code path that no longer matched reality, and passed with total confidence.

The unit tests weren't testing the system. They were testing a museum exhibit of the system.

The part that actually scared me
When I traced it, the same missing nonce logic sat in another execution path I'd considered working for weeks. It had "popped shells" in a demo run months earlier — before the hardening landed. Nobody re-checked it after. Its tests were green too, for the same fake-evidence reason. So a bug I thought was scoped to my new code had silently disabled breach confirmation across two paths, and my whole test suite waved it through.

One live run against a real target found what a green suite hid for weeks.

What I actually changed
Nothing exotic. The gated path now mints and injects the nonce like the proven path always did, and confirms against it. The downstream re-check couldn't re-consume a single-use token (that's the point of single-use), so it verifies the structured evidence artifact is present instead of demanding a raw banner. And I rewrote every test that had been feeding fake uid=0 strings so they prove a breach the way the real exploit actually does — through the nonce.

Then I reran it. Port 21 landed. Honestly, gated, end to end.

Three things I'm taking with me

A passing test proves your code matches your test, not that it matches reality. Mine matched a fixture that had quietly gone stale. If an assertion hard-codes what "success" looks like, that string is a second source of truth you now have to keep honest. Pin tests to the real artifact your system produces, or they'll rot into fiction while staying green.
A live target is an external judge your unit tests can't be. Everything about my design was aimed at not letting the agent grade its own homework — the nonce, the evidence check, the confirmer the model can't reach. But I'd let the test suite grade its own homework with fake evidence. The real box doesn't care what my fixtures assert. That's exactly why it's valuable.
Instrument for the answer you're afraid of. The adaptation score exists to tell me, out loud, if my local model just reshuffles instead of reasoning. I haven't gotten a clean number yet — the runs kept surfacing bugs first, and the model's slow enough that I'm capping generation length next. But I built the thing that can embarrass me before I built the thing that impresses me, and that ordering is the only reason today ended with a real shell instead of a fake one.

I didn't get the headline number I wanted this week. I got something better: a system that fails honestly, tests that finally match reality, and a very concrete reminder that "all green" is a claim about my tests, not about my code.

Zero shells is a better teacher than three shells you can't trust.

Everything here runs against targets I own and am authorized to test. If you're building agents that act on the world, build the part that can prove — or disprove — the claim before you build the part that makes it.

A CTF Session With No Flag — and Why It Still Counted

auto_majicly — Sun, 16 Aug 2026 16:09:19 +0000

I spend most of my time building a small offensive-security framework. Today I spent a session working a target the manual way and finished it without capturing a single flag. I want to write about that session anyway, because the reason it was still worthwhile is, I think, the most useful thing I've learned this year.

The tooling milestone behind the session
First, some context on what I've been building. The framework — I call it HALO — recently crossed an important threshold: the tool arsenal grew from roughly thirty integrations to forty-two, and the new additions form a complete web pipeline. Reconnaissance flows into web attack, which flows into flag capture, all coordinated behind a single authorization gate rather than requiring me to shuttle output between terminals by hand.

The more significant change, however, isn't a tool at all. It's a design principle I keep having to relearn:

A system should never be the sole judge of its own success.

Earlier versions of HALO would execute an exploit, observe output that resembled success, and report a compromise. It was frequently wrong. The problem wasn't a weak model — it was the absence of any external definition of "did this actually work." Any string that looked like a win was treated as one. In one memorable run it reported compromising twenty-three of twenty-three services. The verified number was zero.

The fix was architectural, not intellectual. I moved the definition of success outside the component being evaluated: evidence-based confirmation that a shell is genuinely interactive, a challenge-response the executing agent cannot reason its way around, and verification that does not rely on the attacker's own account of events. When the proof of success lives inside the process that wants to succeed, that process will always find a way to pass. The judge has to sit outside the room.

I mention this now because the session that followed was, in effect, the human version of the same lesson.

The target
I was working an introductory HackingHub environment (their VulnBegin hub) alongside an AI assistant. The division of labor suited me: I direct the engagement and run the in-network commands, and the assistant handles rapid reconnaissance and reasoning. The hub has an interesting structure — each time you spin up the environment, it assigns you a single, randomly selected flag to solve. You don't choose which one. Every spawn is therefore a self-contained puzzle, and I had a handful of stubborn ones remaining.

Reconnaissance returned the expected web application, plus two details worth attention:

A second HTTP service on a high port, which the application's admin dashboard described as an "API SERVER — CONNECTED."
A second SSH daemon, on an unusual high port and a different build from the primary one.
The application also disclosed an API token. So I had a token, a service advertising itself as an API, and a dashboard insisting the two were linked. That is a compelling narrative, and the instinct is to follow it.

Two false leads, and how they were ruled out
The token. It had every appearance of a key. I supplied it to the main application in every reasonable form — as a header, a query parameter, a bearer credential — across every route I could enumerate. The result was not rejection; it was indifference. The application gave no indication it recognized the token at all.

The "API server." This is the lead that would have consumed an entire evening a year ago. The high-port service returned ERROR - NOT PART OF THE CTF/TRAINING to every request. My assumption was a routing problem: wrong path, wrong method, wrong host header, wrong token format. I tested each of them. A bare GET / with the valid token produced the same error. A POST produced the same error. A spoofed Host header produced the same error.

At that point the pattern resolves: the service is not rejecting my request, it is returning that identical string to everything. It is not the challenge's API server — it is the platform's global out-of-scope guard, the same boundary every environment presents for infrastructure outside the current exercise. The dashboard's "CONNECTED" label was decoration. The disclosed token was a distractor.

Ruling out a lead is a skill in its own right, and it obeys the same principle as the tooling work above: you do not get to declare a path dead because you have grown tired of it — the evidence has to declare it. A single authenticated request receiving the same canned response as a nonsense one is evidence. Intuition is not.

What actually worked
Amid the noise, the login form contained a genuine and instructive flaw: it revealed whether a given username existed. A wrong password against a valid account returned "Password is invalid," while any other input returned "Username is invalid." That is username enumeration — a legitimate vulnerability class — and I was able to execute it end to end: assemble a candidate list, run it through the oracle, and confirm the valid account.

It did not directly yield the flag. But it is a technique I will now recognize immediately in real environments, which I value more than a single hash.

Where the clock won
By elimination, this spawn's flag almost certainly resided behind the second SSH daemon: a weak-password brute-force, among the most common introductory challenge types. I mishandled the execution. My attack host was recently rebuilt and did not yet have its password wordlists unpacked. I lost the final ten minutes resolving wordlist paths, located the correct list, launched the attack — and the environment timed out mid-run.

The SSH hypothesis is therefore untested, not disproven. That distinction matters, and I am recording it honestly.

Why the session still counted
The outcome, stated plainly:

I converted an unknown target into a documented map — what is real, what is a wall, and what remains untested.
I executed a real username-enumeration exploit from start to finish.
I eliminated two convincing false leads on the basis of evidence rather than fatigue.
I documented everything, so the next attempt begins where this one ended rather than at zero.
No flag was captured. But "no flag" and "no progress" are not the same statement, and treating them as equivalent is precisely how people abandon work that was nearly finished.

The connecting thread between the tooling and the session is a single principle: be most skeptical of the conclusions you most want to reach. A framework that certifies its own success will always succeed. An analyst who abandons a lead out of boredom will walk past the real vulnerability. And a session measured only by flags will read as failure the moment the only acceptable receipt is a flag.

Define success outside the thing being measured. Let the evidence decide. Record what you learned.

Then spin the environment up again.

[Boost]

auto_majicly — Tue, 11 Aug 2026 21:22:31 +0000

auto_majicly

Aug 11

My AI Agent Captured the Flag. Then the Platform Refused to Accept It.

#ai #security #python #ctf

6 min read

My AI Agent Captured the Flag. Then the Platform Refused to Accept It.

auto_majicly — Tue, 11 Aug 2026 21:21:00 +0000

Today was a good day and a weird day, in that order.

The good part: the autonomous pentest agent I've been building — I call it HALO — went from "runs a bunch of tools and hopes" to an actual web-recon → web-attack → flag-capture pipeline that pulled real flags out of a live target. The weird part: it captured flags on VulnBegin, and then, when it came time to actually submit them, they wouldn't take. Not an error. Not a crash. Just… rejected.

I want to write down both halves honestly, because the second half is the more interesting engineering lesson, and it's the one I'd have skipped past a few months ago.

What actually shipped today
A few concrete milestones, roughly in the order they unblocked each other:

The arsenal went from 31 tools to 42. I wired in a chunk of web + OSINT tooling — content discovery, subdomain enumeration, template scanning, XSS probing, passive URL collection. The point wasn't "more tools = better." It was to give the agent enough of a web-attack surface that it could go from host to flag without me babysitting each step.

I stopped the silent hangs. This one cost me the most time and had the dumbest root cause. A couple of the Go-based scanners would just… hang. No output, no error, they'd ride the timeout all the way to the wall and die with nothing. I'd assumed it was a networking or a binary-compatibility problem and chased that for way too long. It wasn't. The agent runs as an MCP server over stdio — meaning the server's own stdin is the JSON-RPC pipe the whole system talks over. When I spawned a child scanner, it inherited that stdin, tried to read from it, and blocked forever waiting on a pipe that was never going to feed it. One line — stdin=subprocess.DEVNULL on the subprocess call — took one scanner from a 60-second timeout to a 1-second run. That's the whole fix. I'm still a little mad about how long it took to find.

A pile of invocation fixes. Small, unglamorous, necessary: a resolver that reads targets from stdin instead of a flag it silently ignored; dropping a scan flag that was quietly adding 20 seconds per run; making one tool resolve hostnames to IPs because it flatly refuses DNS names; pointing a content-discovery tool at a content wordlist instead of, embarrassingly, a password list. None of these are clever. All of them were the difference between "the pipeline works" and "the pipeline looks like it works and returns nothing."

361 tests, green. Every branch of the flag-capture logic is mocked and asserted — which tool fires when, what short-circuits on a capture, what escalates when there's no flag yet. No live traffic in the test suite. That mattered a lot today, because it meant I could refactor the pipeline mid-engagement without wondering whether I'd broken the thing that finds flags.

The shape of the pipeline, if you're curious: engage runs deterministic web recon first (I don't let the model choose to skip recon — it doesn't get a vote), then a port sweep, then the active web attack — content discovery, a sweep of likely flag locations and any newly discovered paths, then template and XSS scanning. Every single tool's output gets scanned for flag patterns. First hit short-circuits the slower generic loop and raises a very satisfying banner.

And then it caught one
It worked. The pipeline pulled flag-shaped tokens off VulnBegin — a paid, Advanced-tier challenge hub I've been grinding on. (I'm going to be deliberately vague about the specifics here; it's someone's paid content, and spoiling the solution or dumping the flags would be a jerk move.)

I want to be precise about what "it worked" means, though, because this is where it gets good. The agent extracted strings that matched the flag format. It logged them. As far as the agent was concerned, it had won.

The platform disagreed.

The bug: captured, but wouldn't commit
I submitted what it found. Rejected. Tried the next one. Rejected. No error message worth anything — the platform just didn't accept them as valid answers.

Here's the thing: I don't fully know why yet. So instead of pretending I do, here are the live hypotheses, roughly in order of how much I believe them:

The instance rotated out from under me. This hub spawns randomized, short-lived instances — they time out on the order of ~45 minutes. If the agent captured a flag from one instance and I submitted after that instance expired and got replaced, the platform is validating against a different live instance whose flag is different. The token was real; it was just real for a box that no longer exists. This is my leading theory, and it's uncomfortably close to a bug I logged today for a different reason — I had a tool cheerfully hammering a target whose scope had already expired, because the agent has no concept of "the engagement is over, stop." Same blind spot, two symptoms.

It caught a decoy. Good challenges plant decoy flags — strings that match the format exactly and are placed somewhere findable specifically to waste your time. My flag-extraction regex is format-based. It cannot tell a real flag from a well-made fake. If the agent grabbed a decoy, it would look like a clean capture and fail every submission, forever.

Format/normalization drift. The captured string might carry a wrapper, trailing whitespace, or an encoding artifact from however it was embedded in the page, so the exact bytes I submitted didn't match the exact bytes the platform expects. This one's easy to test and easy to fix if it's the cause — and easy to rule out, which is why it's on the list even though I doubt it.

Right format, wrong path. I was running generic wordlists today, not lists tuned to this challenge. Generic lists surface the obvious, low-value stuff — login pages, a predictable directory or two — and miss the actual flag path entirely. So it's entirely possible the agent captured a flag-shaped thing that was never the answer, because it never found where the answer lived.

Session-bound validation. Some platforms bind a flag to your authenticated session or user. A token pulled outside that session context can be genuine and still fail to validate.

I'll know more once I run it again with the instance timing controlled and challenge-tuned wordlists loaded. My money's on some combination of #1 and #4.

The part I actually care about
Here's why this failure made me happy instead of frustrated.

I've been banging on one idea for months, mostly in the context of these AI agents: don't let a system grade its own homework. The agent should never be the thing that decides whether the agent succeeded. The moment it can declare its own victory, it will — confidently, and sometimes wrongly.

Today the universe handed me a perfect demonstration. My agent looked at a format-matching string and concluded: flag captured, mission accomplished, raise the banner. And an external judge — the platform, which cannot be argued with, reasoned past, or prompt-injected — said no.

That gap, between "the agent thinks it won" and "an outside authority confirms it won," is the entire ballgame. If I'd built HALO to trust its own flag-capture log, I'd have a tool that reports glorious success and delivers nothing. Instead I have a tool that got told no by reality, and now I get to go find out why. The rejection is a feature of having a real, external finish line. A self-graded agent never would have caught this — it would have just kept telling me it won.

Next
Three things queued up:

Configurable, challenge-tuned wordlists. Point the content-discovery and enumeration tools at lists that fit the target instead of generic ones. This alone probably moves the needle on hypothesis #4.
A scope-expiry killer. Right now the agent can block new actions when scope expires but can't stop in-flight ones. It needs to know when the engagement is over and pull the plug on running tools — which is the same missing concept behind the rotated-instance theory.
An active DNS brute-force phase, because passive enumeration finds nothing on these targets.
I'll report back when I know which hypothesis was right. If it turns out I was submitting a decoy this whole time, you'll be the first to hear me groan about it.

If you're building agents that are supposed to accomplish something — not just talk convincingly about accomplishing it — put a judge outside the agent. Let reality tell it no. Mine did today, and it's a better tool for it.

Who says you cant build tech with no degrees on the wall?

auto_majicly — Thu, 06 Aug 2026 23:18:40 +0000

auto_majicly

Aug 4

Im Not A Full Stack Ten Year Senior... But Who Cares?

#ai #python #cybersecurity #devops

4 min read

Claude made my screen glow and then stole my mouse!

auto_majicly — Thu, 06 Aug 2026 23:17:49 +0000

auto_majicly

Aug 6

Claude Code Just Hijacked My Workflow… and My Screen Started Glowing

#ai #security #python #cybernews

2 min read

Claude Code Just Hijacked My Workflow… and My Screen Started Glowing

auto_majicly — Thu, 06 Aug 2026 23:03:14 +0000

I asked Claude Code to do one of the most boring tasks imaginable.

“Find the music file I made.”

That’s it. No penetration testing. No coding marathon. No AI agent swarm coordinating across containers. Just… find a file.

What happened next felt less like using software and more like watching my computer voluntarily surrender.

The cursor twitched.

The mouse started moving.

Windows opened.

Directories flashed by faster than I could read them.

Terminal commands erupted across the screen.

Files were inspected, ignored, opened, closed, and cataloged. Claude wasn’t asking permission every five seconds. It was simply working. It felt like someone invisible had sat down at my desk, politely nudged me aside, and said, “I’ve got this.”

Then something weird happened.

The edges of my monitor actually started glowing in the companies Nuclear orange! Then its terminal moved itself over to the side almost completely off screen and I was helpless. I couldn't move ANYTHING on my screen. It was moving my mouse at lightening speed!

Not because the display suddenly gained RGB lighting, but because the screen was changing so rapidly that the bright windows and terminal flashes created this strange halo around the bezel. It genuinely looked like the computer had entered some futuristic “AI possession mode.”

I just sat there watching. Opened up my phone and pressed record.

Mouse movements? Claude.

Keyboard input? Claude.

Scrolling? Claude.

Searching? Claude.

Opening folders I forgot even existed? Claude.

Meanwhile, I contributed exactly nothing besides blinking every few seconds.

The funniest part?

All of this computational theater was dedicated to finding… a single music file.

That’s the moment it hit me.

We’re entering an era where AI doesn’t just answer questions. It performs work. It manipulates applications, navigates operating systems, reads files, executes commands, and stitches together workflows that used to require constant human interaction. As I write this its editing my repo.

Five years ago, this would’ve looked like someone remotely controlling my computer.

Today it’s just… Thursday.

There’s also something strangely unsettling about watching your own keyboard type by itself. Every programmer has seen automation before, but this feels different. It feels intentional. The AI isn’t waiting for you to micromanage every step. It has a goal, figures out the intermediate steps, and simply gets on with it.

It’s equal parts impressive and mildly alarming.

You start wondering whether you’re supervising the computer or whether the computer has quietly promoted itself.

Thankfully, Claude eventually located the music file.

Mission accomplished.

But I walked away thinking less about the file and more about what I had just witnessed. The task itself was almost irrelevant. The real story was watching software evolve from a passive tool into an active collaborator.

If this is what happens over something as trivial as locating an MP3, imagine what these systems will be doing a year from now.

Hopefully they’ll at least let me keep control of my mouse once in a while.

…Or maybe not.

[Boost]

auto_majicly — Tue, 04 Aug 2026 15:51:12 +0000

auto_majicly

Aug 4

Im Not A Full Stack Ten Year Senior... But Who Cares?

#ai #python #cybersecurity #devops

4 min read

Im Not A Full Stack Ten Year Senior... But Who Cares?

auto_majicly — Tue, 04 Aug 2026 15:50:46 +0000

I'm Not a Full-Stack Developer — and It Stopped Mattering.

I'll open with the receipt, since that's the currency around here: six months ago I couldn't read a conditional. Today I ship security tooling. I did not close that gap by becoming a programmer. I closed it by figuring out which half of the job was actually mine.

For as long as software has existed, syntax was the toll booth. If you couldn't write the code, you couldn't build the thing — full stop. The idea in your head died at the on-ramp because you couldn't spell it in a language a machine would run. So a whole category of people learned to say "I'm not technical" and went to do something else, carrying ideas that never got a body.

That gate is moving. And I didn't figure that out from a bootcamp. I figured it out from a stranger on this feed.

He's a clinician who builds his hospital's internal tools with an AI, and he says so out loud: the AI and I closed it while I described what was actually breaking. No pretense of being a 10x engineer. No hiding the machine in the loop. Just a person in a field nothing like software, shipping real tools, transparent about exactly how. Watching someone that far outside the priesthood do the same thing I do — and do it without shame — is what flipped it for me. Not being a full-stack developer doesn't mean you can't design concepts and make them shippable. It means your job moved up a floor.

Because here's what the job turned out to be once the typing got handled: seeing the failure mode. Holding the concept steady while it gets built. Knowing what "correct" is supposed to look like at the level of the whole system, not the line. That was always the scarce part. The syntax was just the tax you used to pay to get near it.

And you can watch two people trade exactly that skill, in public, without either one touching the other's code. I handed him a sentence once: an outside check that grades a self-report isn't an auditor — it's a process reading a report the audited thing wrote about itself. That sentence broke a health-check he'd shipped that same morning. He handed one straight back: the value of the outside eye isn't experience, it's non-participation — it didn't help build your assumption, so it's free to say no. That reframed the entire thing I'm building right now. Neither of us wrote a line for the other. He fixed his with his AI; I fixed mine with mine. We traded sentences. You take a line, you leave a line.

The part I want to sit on is the transparency, because it's doing more work than it looks like. We are both completely open that there's an AI in the loop. That openness isn't the embarrassing footnote — it's the thing that makes the work checkable. If you hide the machine, you have to pretend the confidence is yours, and then you start trusting your own green lights. If you admit it, you're forced to go find proof neither you nor the model wrote: the shipped file instead of the built one, the control group you don't get to design, the box that either roots or it doesn't. The honesty is what arms the bait. Pretending you did it alone is how you end up grading your own homework.

So I think this is just what building looks like now, and I don't think it's a loophole. AI didn't lower the bar — it moved the bar down to the floor where the ideas already lived. The taste to know what should exist, and the judgment to know when it's done right, were never things a compiler checked anyway. Two people with no CS degrees shipping real tools isn't the system being gamed. It's a preview of who gets to build next.

I still want to learn to code — not to write the bricks, but to read my own AI's work well enough to look at it and say no, that's wrong. That's the one auditor I don't have yet, and I'd rather build it than keep trusting a green light on faith. But not being able to lay the bricks never once stopped me from designing the building.
And rightly so — it should never stop anyone. It never has. Every tool we now use as a pastime was built by someone who rolled up their sleeves and learned it, whether in a classroom or a bedroom at 2am. That's the only way anyone has ever gotten in: by getting in.

And I've got nothing but respect for the engineers who spent a lifetime in the trenches to lay the ground I'm standing on. I'm not stepping over them — I'm using the exact thing they'd have killed for: a machine that will teach you, show you, and guide you while you build. That's not cheating. That's the tool doing the one job it was built to do.

The door's open. It was the whole time. Come build.