This week feels like Cyber AI builder galore. Not another round of vague predictions about AI replacing security teams, but concrete write-ups from people trying to build systems that actually work: AI-assisted patching, AI pentesting infrastructure, AI application testing, disposable tooling, and the security problems created when coding agents drive developer tools. The common thread is that the model is rarely the whole story. The useful work happens around it: the harness, the tests, the validation, the accounts, the logs, the cleanup, the guardrails, the patches, and the human review. That is what I liked about this week’s links. They are less about "look what the models can do" and more about what you need to build around the model before the output becomes reliable, useful, or safe.

Such a catchy name for a great initiative.

Trail of Bits published Patch the Planet, an initiative with OpenAI where their engineers spent a week using AI to help secure critical open source projects.

The numbers are impressive: hundreds of bugs discovered, 64 pull requests, 51 issues, and 37 pull requests already merged across 19 projects.

But the key point for me is not the number of bugs. It is how they found some of them. One of the most interesting parts is the use of historical CVEs to find variants of old bugs. I have said it many times, and I will keep saying it: "Those who don’t learn from CVEs are doomed to rediscover them" (https://www.youtube.com/watch?v=_s2KmPVH5SQ).

Past vulnerabilities are not just history. They are patterns. They tell you where developers make mistakes, where APIs are confusing, where assumptions break, and where similar projects are likely to fail in the same way. AI makes this much easier to scale. Instead of reading one CVE and manually checking one codebase, you can start building pipelines that look for the same bug shape across many projects.

The other interesting part is that Trail of Bits brought patches, not just bug reports. A bug report still leaves a maintainer with work to do: understand the issue, reproduce it, assess the severity, write the fix, write the tests, and make sure the vulnerability does not come back later. A good patch changes that dynamic. It makes the issue easier to review, easier to merge, and easier to keep fixed because the pull request can include the regression tests, fuzzing harnesses, or CI changes needed to prevent the same class of bug from returning. AI security work should not stop at “we found a bug.”

The real value is going from old CVEs, to new variants, to accepted patches, to tests that make the project better after you leave.
Introducing Patch the Planet.

The most interesting takeaway from this talk was not a specific vulnerability or model capability. It was how much of the system was dedicated to operational problems rather than better prompts.

The team seemed to approach the problem by asking: what would an army of pentesters need to operate effectively?

That led to a lot of practical infrastructure: separate accounts, shared state, agent coordination, email inboxes, 2FA, phone-based authentication, VPN access, outbound containers, external payload hosting, and file uploads.

This is the part people often underestimate. Humans coordinate around these things naturally. Agents do not. If multiple agents share an account, one may change the password, another may trigger rate limits, and a third may break the session everyone else was using.

The most interesting design decision was implementing guardrails in code, not prompts. Instead of only telling the model “do not attack third-party systems,” traffic was routed through a forward proxy that enforced scope programmatically. The system distinguished between targets that were accessible and targets that were attackable.

That is a much stronger model than relying on prompt instructions alone, but it also raises interesting questions. How do they decide whether a request is an attack? How does this work with redirects, callbacks, webhooks, OAuth flows, and external payload hosting?

I also liked their use of skills instead of fine-tuning. When the team found gaps in model knowledge, they created specialized skills based on internal security expertise and only loaded them into the agents that needed them. That avoids unnecessary context pollution.

My main takeaway: building an AI pentester is less about one magical model and more about recreating the infrastructure, coordination, constraints, and specialist knowledge that a real pentesting team already relies on.

In many ways, this looked less like prompt engineering and more like building an operating system for a team of security researchers. Building an AI pentesting platform.

Doyensec published an interesting comparison of AI application security testing platforms, looking at Aikido and XBOW on two real open source web applications. The study was sponsored by Aikido, but Doyensec notes that Aikido was not involved in collecting or presenting the results.

Both tools found real vulnerabilities, which is already interesting, but for me the most useful part is not the leaderboard. It is the operational mess around the testing.

Authentication matters. Multiple users matter. Social login matters. Rate limits matter. Test accounts get modified or deleted. Agents generate thousands of emails. Findings need to be deduplicated, and severity still needs human judgement.

This is where a lot of the real work seems to be, and it links nicely with the AI pentesting platform talk above. AI pentesting is not just "give the model a browser and ask it to hack". You need safe test environments, seeded data, multiple accounts, communication between agents, cleanup, guardrails, and human validation.

The tools are getting useful, but the boring parts are still the hard parts. Comparing AI Application Security Testing Platforms.

Metnew published a great write-up on a Claude Code sandbox escape using Git worktrees.

The short version is that Claude Code allowed the creation of a worktree named `.git`. That sounds like a small edge case, but `.git` is not a normal directory name in Git. It has special meaning, and letting an attacker-controlled repository influence where `.git` appears creates room for confusion between the working tree, Git metadata, and the tool managing both.

The bug was triggered through prompt injection, but I don’t think prompt injection is the most interesting part here. The prompt injection is the way the attacker gets the agent to perform the actions. The actual bug is in the assumptions around Git worktrees, path handling, symlinks, and where the tool is allowed to write.

The clever part is the chaining. The malicious repository is shaped so that it can be interpreted as Git metadata in the right context. Claude Code is then convinced to create and move between worktrees, including one named `.git`. Once Git and Claude Code disagree about what is a repository, what is a worktree, and where metadata should live, the attacker gets writes outside the expected project directory. From there, the PoC abuses shell startup behavior to get code execution outside the sandbox.

I like this bug because it is not only relevant to Claude Code. It is a good trick to keep in mind when auditing anything that hosts, clones, imports, or manipulates Git repositories: GitHub-like platforms, GitLab, Gogs, CI systems, code review tools, internal developer portals, and now AI coding agents.

Anywhere a product takes an attacker-controlled repository and then runs Git operations around it, you should be thinking about special names, worktrees, submodules, symlinks, hooks, config, alternate object directories, and metadata confusion.

The broader lesson is that agents do not make these old bug classes disappear. They often make them more interesting, because the agent becomes a layer that turns text instructions into filesystem operations, Git commands, and tool invocations.

A lot of the security work around AI coding tools will not be about the model itself. It will be about the tools the model is allowed to drive, and whether those tools were designed to be safely driven by untrusted input.
Claude Code: unsandboxed code execution from prompt injection via .git worktree confusion.

SpecterOps published a really interesting article on disposable tooling and LLM-generated Mythic agents. The obvious headline is that they were able to generate small, throwaway agents in different languages, but I think the more interesting part is the method they used to make the output reliable.

The first attempt was basically “prompt and pray”. The result had the right shape and looked plausible in places, but it did not actually work. There were missing packages, wrong paths, hallucinated APIs, and misunderstood protocol details. This is the classic problem with LLM-generated code: it often looks close enough to be convincing, while still being far enough from working that you need real expertise to debug it.

The lesson from the article is not to write a better prompt. It is to build a better environment around the model. They added documentation as a skill, a mock server, local validation, real integration testing, debugging tools, a deployment wrapper, and eventually a separate QA step with a fresh context window to test the result independently.

That is the part I find interesting. A lot of AI reliability work seems to come down to the same pattern: do not trust the model when it says it is done. Give it a harness, give it tests, give it logs, give it a way to reproduce failures, and force it to validate against the real system. Ideally, have something else check the work with a fresh context.

This links back to the other AI security pieces in this issue. The hard part is not only getting the model to produce something. The hard part is building the loop around it so the output becomes usable.
Disposable Tooling: Building LLM-Generated Mythic Agents from Prompt to Deployment.