Another week in AI security news...

Anthropic gave 45 agents their own machines, a shared forum, and the same goal of finding vulnerabilities across 15 open-source projects, then measured what happened.

The coordinating swarm kept finding vulnerabilities at a roughly constant rate and found many issues that independently assigned agents missed. The interesting part is not just that a bigger budget found more bugs. Coordination changed the search strategy. The agents could decide where the interesting work was, specialise, share tooling, peer-review findings, and follow promising paths instead of staying inside a pre-assigned part of the codebase.

The two approaches found surprisingly little overlap, so they are complementary. That is the useful lesson for anyone building an AI code-review system: do not ask whether you need one agent or many. Decide what needs broad independent coverage, what benefits from shared context, and where agents should be able to challenge each other.

One last interesting takeaway is that agents converge far too easily, fail to share decisive evidence, and can make the same mistake at scale. A multi-agent system needs ways to create independence and disagreement. Otherwise, you have not built a team of researchers. You have built 30 copies of the same person confidently agreeing with themselves. Patterns and problems in multiagent systems \ Anthropic.

Mandiant published a detailed look at its Agentic Vulnerability Discovery Harness. What I found most interesting is that it tries to make agentic code review look very much like human code review.

It maps the workflow into stages: understand the application, build a threat model, identify entry points, enrich each one with the relevant context, generate vulnerability hypotheses, validate or disprove them, then have a human reproduce the exploit. It also encodes consultant knowledge as domain, language, framework, and vulnerability rules so the agents are not starting from a blank page.

I am not sure this is necessarily the right destination. Agents can read more code, pursue more weird paths, and try far more ideas than a human reviewer. If we force them to follow our familiar process too closely, we may lose some of the advantages that make them interesting in the first place.

But the hypothesis-generation stage really stood out to me. That is very close to how I review code: form an idea about what could go wrong, gather the relevant evidence, then try to prove yourself wrong. Getting agents to generate hypotheses broadly, rather than asking them to return a list of vulnerabilities, feels like a much more promising way to use them. The challenge will be preserving that disciplined process while still leaving enough room for the agents to go wild. Staying Ahead of Adversarial AI Through Agentic Source Code Review | Google Cloud Blog.

Aikido ran 10 models three times each against 32 recently disclosed vulnerabilities. The leaderboard is interesting, but the more useful takeaway is about variance.

We normally treat a model giving different answers to the same task as a problem. For vulnerability research, it can be an advantage. One run follows one path through the code and misses a bug. Another starts somewhere else and finds it. Pooling three runs substantially improved coverage for most models.

That does not mean "run everything three times" and call it a day. More coverage also means more findings to validate and triage. But it is a good reminder that the best model may not be the one with the highest score on one run. It may be the one you can afford to run repeatedly, then verify properly. We burned 11.7bn tokens to find the best cyber AI model | GLM5.3 and DeepSeek are now frontier.

Weightless is a neat way to run a local model when you want a normal version and a less restricted version at the same time.

Normally, that means loading two huge model checkpoints. Weightless instead adds a tiny LoRA adapter to one base model. In vLLM, you can send, for example, a request to qwen for the normal model or qwen-abliterated for the less restricted version. Same GPU, same server, very little extra memory.

There is a performance cost, though. Enabling LoRA makes both versions about 12 to 13% slower, around 21 to 22 tokens per second in my tests. The steered version is only slightly slower than the normal one. So this is not the fastest way to run an uncensored model. It is useful when you specifically need both behaviours available side by side.

The underlying technique, removing a model’s refusal behaviour, is not new. The interesting part is making it practical: one model in memory, two behaviours you can choose per request, rather than two massive copies of the same model. weightless — abliteration without the weights.