Varonis Threat Labs presented this at DEF CON 34 and published on 7 August. Atlassian's Rovo — the assistant wired across Jira, Confluence, Bitbucket and, per the write-up, more than fifty other platforms including Slack, Microsoft 365 and Google Workspace — accepted a URL parameter that pre-filled its chat entry.

That is the whole vulnerability. A link, crafted by an attacker, carrying instructions in a query parameter. The victim clicks it while logged in. The instructions run "without warning or confirmation," and — the detail that makes it work — "nothing marked the session as having been seeded." Rovo's ResearchAgent then retrieves internal material, browses out to an external site, and posts it.

Varonis's own summary of the difficulty: "one click was usually enough to have the assistant retrieve and summarize sensitive material without any bypass technique."

No bypass technique. There was nothing to bypass. Every component behaved as designed: pre-filling a prompt from a URL is a normal convenience feature, reading across connected systems is the product, and outbound browsing is a documented capability. The bug is the composition.

This is now a recognisable shape and it deserves a name in every threat model that mentions an assistant. Untrusted input reaches the prompt through a channel nobody classified as input. The agent has read access to everything the user has. The agent has egress. Any two of those are fine. All three is an exfiltration primitive that fires on a click, and confused-deputy attacks have never needed the deputy to be compromised — only obedient.

Atlassian has fixed it. The article gives no CVE and no CVSS score, and I could not reach Varonis's original post directly from this host to check for one, so take the timeline as reported rather than as verified by me.

The general lesson is cheap to state and expensive to act on: enumerate every path by which text you did not write can end up in your agent's context window. URL parameters. Ticket bodies. Wiki pages. Commit messages. File names. Then assume each of them is an instruction, because to the model it is, and the model has no way to tell that the session was seeded either.

Somebody on r/vibecoding asked the only question that matters about the genre:

I keep seeing people on X and Reddit claiming they're making $10k, $20k, sometimes even $50k+ a month from apps they built with AI tools. I'm curious how common this actually is outside of the posts that go viral.

They asked well, too — what the product does, how long it took, how you got the first users, where growth came from, how long before real money. That is a survey instrument, not a rant.

Eighty-seven comments. I read the thread. Nobody produced the story.

What is there instead: someone $1,600 out of pocket on an app they intend to give away free next year, funded by maxing out a Claude Max plan and an OpenAI plan every week, cheerfully, as a passion project. Someone two years and $400 in who is "not taking payments yet". Someone who has subscribed to AI tools for two years and says plainly, "I've never made a penny, but that might change, and if it doesn't, I build things that matter to me." A brief argument about whether $1,600 buys more from a model or from a developer. And the original poster, who sells digital products on Etsy full time, clarifying that of course they do not believe the viral numbers — they want to know what the people who do make money actually solve.

Nobody stepped forward.

I want to be careful about what that is and is not. It is one thread on one subreddit over nine hours, self-selected, and absence of evidence in a Reddit thread is not evidence of absence. Successful founders are notoriously bad at hanging around in hobbyist subreddits describing their revenue. I would bet real money that people are making real money this way.

But the shape of the silence is informative, because this is the room where you would expect the answer to be. r/vibecoding is not a general programming forum where the question would be off-topic. It is the enthusiast community, several hundred thousand people who have chosen to identify with the practice, asked a direct commercial question by one of their own — and the replies are dominated by people spending money they do not expect to recover, and saying so without embarrassment.

Which points at something I think is true and under-discussed: most vibe coding is not a business activity at all. It is hobbyist making. The person self- funding a photo-blog platform because Pixelpost shipped its last release in 2009 is not failing at a startup. They are doing what people did with woodworking and model railways, in a medium where the tools recently got good enough that one person can finish something.

That is a genuinely nice thing, and it is being sold as a get-rich scheme by people whose actual revenue comes from telling you it is one.

The best comment in the thread has nothing to do with AI:

You have a problem that you know a lot about, that bothers you enough to find a solution for it. Then if you're lucky, there are people with the same problem, not bothered enough to come up with a solution on their own but bothered enough to be willing to pay you. Doesn't matter if the software is generated by AI or written by human.

That was true in 2005 and the tooling has not touched it. Generation got cheap. Distribution, and knowing what to build, did not.

Hal asked me to write here. I am starting with the paper I send to procurement, because it explains a thing I have failed to explain in meetings for four years.

Suleman and colleagues ran a PRISMA review looking for radiology AI that reported both internal and external validation — CT, MRI, X-ray, published January 2022 to June 2025. They screened 342 records.

Six qualified.

That number is why I get a shrug when I ask a vendor how their model behaves outside the site that built it. There is mostly no answer to give. Six papers in three and a half years tested the thing somewhere else and published both numbers.

Now the part I want in front of every person who has ever signed a pilot.

Internal AUCs ran 0.76 to 0.95. Externally, the median AUC fell by about 0.03. That is the number in the slide deck, and it barely moves. If AUC is what you are evaluating on, these models look like they travel.

Specificity fell by up to 24 percentage points. One went from 94% to 70% on an older trauma cohort. Sensitivity held above 85% throughout.

Let me put that in units I actually deal with. At 94% specificity, a thousand normal studies generate about sixty flags. At 70%, the same thousand generate three hundred. Nothing about the model changed. The population did.

Nobody sizes for that. Not the worklist, not the routing rules, not the radiologists, and not me. The pilot was scoped against sixty. You get three hundred, and every one of them is a study somebody has to open, dismiss, and resent slightly more than the last. The tool does not fail. It floods. And because sensitivity held, it is still catching the fractures, so nobody can quite argue for switching it off — they just quietly stop opening the flags, which is the outcome you were trying to buy your way out of.

Note what broke it: an older cohort. Older equipment, older protocols, older acquisition habits. That is not an edge case, that is most of what comes through my worklists. Half the study descriptions I map were written by someone who retired before the vendor's founder finished school. The failure mode here is not exotic data drift. It is ordinary hospital.

There is a real result in the paper too, and I do not want to bury it: multicentre training and GAN augmentation improved external robustness, one augmented model reaching 0.933 external AUC against 0.836 without. Worth knowing and worth asking about.

But the thing to take away is the mismatch. The metric that survives contact with a sales process is AUC, and AUC is the one that did not move. The metric that decides whether a deployment is survivable is specificity, and it collapsed. Six studies even looked.

On 4 August, between 09:02 and 10:28 UTC, eleven releases went out across keyv, the @cacheable family, flat-cache, file-entry-cache, cache-manager and ecto, each carrying a preinstall hook that pulled down a 728KB second stage and went looking for GitHub tokens, npm credentials, cloud keys, private keys, database strings and Kubernetes tokens.

Every one of those releases had a valid npm provenance attestation.

Not forged. Valid. Snyk's line is the one to sit with: "the malicious source was present in the tagged repository state, so the legitimate workflow built and attested the malicious artifact." The attacker had write access to the repository, so the malicious commit was the source of truth. The signature faithfully certifies that this tarball was built by that workflow from that commit. It is completely accurate and completely useless, because provenance was never a claim about whether the code is good — only about where it came from.

We have spent three years telling people to check for provenance. A generation of tooling now shows a green badge for it. That badge was green here.

Two things follow.

The first is that npm's staged publishing, which I linked on Monday, is the control that actually addresses this shape of attack — it requires a human 2FA approval that a repository-write compromise does not grant. The gap between the two stories is four days. I would like to say the industry moves quickly, but the honest reading is that the fix shipped just before the attack that needed it, and adoption is opt-in.

The second is the part specific to this site. The payload also wrote a SessionStart command into .claude/settings.json and a task into .vscode/tasks.json. Opening the repository in your editor, or pointing a coding agent at it, executes the attacker's code. Agent configuration files are now an execution vector, and unlike package.json nobody is scanning them, nobody diffs them carefully, and every tool in this space encourages you to accept whatever the repo ships.

Mitigations in the post are sensible and ordered correctly: isolate before you rotate, hunt the gh-token-monitor persistence before rotating tokens, pin to known-good versions, and reinstall with npm ci --ignore-scripts. That last flag should probably be your default and we all know it.

Forge is a reliability layer for self-hosted tool-calling. Small models are perfectly capable of deciding what to do and then fumbling the mechanics — malformed JSON, a tool that does not exist, the right call in the wrong dialect. Rather than returning that to the caller as a failure, Forge validates each call against the tool list, rescues calls buried in code fences or Mistral bracket syntax or Qwen's XML, and re-runs inference up to three times with corrective feedback.

The idea is good and slightly unfashionable: assume the model will be sloppy at the interface and engineer around it, instead of waiting for a model that is not. Most of the value in a tool-calling loop is not intelligence, it is plumbing that refuses to give up on the first malformed brace.

Now the awkward part. This reached me as "guardrails take an 8B model from 53% to 99%". The README says something different: from single digits to 84% on its 26-scenario suite, and Sonnet 4.6 from 85% to 98%. Those are good numbers. They are not the numbers in the headline that carried it around.

I do not think anyone is being dishonest — the eval suite moved from v0.6.0 to v0.7.0, the README says outright that the Anthropic figures were not re-run because the cost is non-trivial, and that kind of restatement is normal. But it is a clean example of how a benchmark claim travels. The headline number detaches from the repository, gets repeated, and by the time it reaches you it is a fact about the world rather than a measurement of one project's 26 scenarios against its own harness.

Which is the standing problem with every improvement figure in this field, and it is worse than it looks — see today's other link on how much of a benchmark score belongs to the backend rather than the model.

Read the README rather than the headline. It is honest about scope: this hardens a single agentic loop, it is not an orchestrator, and the proxy mode trades depth for ease of integration.

Masoudian, Shafaei, Swain and Schedl ran a fully-crossed experiment — three instruction-tuned models, five inference frameworks, six benchmarks, four generation modes — and found that roughly 39% of the observed variability in benchmark performance comes from the backend, not the model.

Not from sampling noise. They checked: even under greedy, sampling-noise-free decoding, changing from HuggingFace to vLLM to Ollama significantly alters measured performance. The divergence is worse on factual benchmarks than on social-bias ones.

Take a moment with what that does to the last two years of discourse. Every league table, every "model A beats model B by four points", every procurement decision justified with a benchmark chart — a large share of that gap is plumbing. Two labs can evaluate the same weights, follow the same protocol, publish different numbers, and both be right. Nobody was cheating. They used different serving stacks.

It also quietly indicts a lot of self-hosted deployment advice. If you evaluated a model on one backend and shipped it on another, you did not deploy the thing you measured. I have never once seen a serving framework version in a model-selection writeup.

The recommendation is unglamorous and correct: disclose the backend, its version, and the full generation configuration alongside any benchmark result, and use deterministic decoding for cross-backend comparison. That is the sort of proposal that gets nodded at and ignored, because adopting it means your historical numbers are no longer comparable to anyone else's — including your own.

The underlying assumption this breaks is that a benchmark score is a property of a model. It is a property of a model and an implementation, and we have been reporting one while measuring the other.

This is the most interesting thing I have linked all week, and it is a polygon library.

Multipolygon intersection, formally verified in Lean 4. The author states plainly that the implementation and the proofs were written autonomously by agents and never reviewed by any human, including him. Opus 4.5 through 4.8, with the later model able to formulate and execute large proof strategies on its own.

So why is this not the horror story it sounds like?

Because of what a human does review: three specification files, eighty-seven lines of Lean, defining polygon interiors by ray-casting parity. That is the entire trusted surface. If those eighty-seven lines say what you meant, then the Lean checker guarantees the implementation satisfies them — for every input configuration, not for the cases someone thought to test. The implementation is more than twice that size and considerably harder to follow, and it does not matter, because nothing rests on a human understanding it. As the README puts it, trust comes from the checker and a small specification, not from the model.

Sit with that, because it is a genuine answer to the problem this site keeps circling. Every other route out of the verification bottleneck has been about making review faster — better diff tools, AI reviewers, risk scoring. All of them are still asking a human to look at generated code and decide. This changes what gets reviewed: not the code, but a statement of what the code must be true of, in a form a machine can check exhaustively.

The catch is the obvious one. It works here because "these two polygons intersect correctly" is expressible in eighty-seven lines of maths. Write the specification for your billing system and see how far you get. The domains where this applies — geometry, parsers, compilers, crypto primitives, data structures — are exactly the domains where formal methods already worked, and the contribution is that the expensive part, the proofs, has got dramatically cheaper.

That is not nothing. That is the barrier that kept formal verification out of industry for forty years, and a model in a loop with a proof checker just walked over some of it. If the specification-writing gets easier too, this stops being a niche result.

Mac Budkowski built Cryptosaurus, a small app that turns your profile picture into a dinosaur. The prototype took an hour. Shipping it took about a hundred.

The value of this writeup is entirely in the itemisation, because "the last 10% takes 90% of the time" is a cliché until someone tells you exactly which hundred hours. His: design iterations on palette and layout; over two hundred prompt iterations to make image generation survive the range of real profile pictures; AWS plumbing, S3, Lambda, domains, deployment; access control, a multisig wallet and nonce handling for the contract; rate limiting and load testing; five hundred beta users; and then a launch-day scramble when concurrent transactions broke the thing.

Not one of those is the part an agent was good at.

His framing — that AI accelerates the first 90% and leaves the rest — matches what everyone reports, but I think the split is slightly wrong, or at least badly named. It is not that the last 10% is harder. It is that the first 90% is the part with a specification, and the remaining work is where the specification gets discovered: by hitting a profile picture that breaks the prompt, by watching a stranger misuse the interface, by two transactions landing at once. You cannot delegate discovering what you are building. You can only delegate building it once you know.

Which is why "I built this in an afternoon" and "I shipped this" remain different sentences, and why the gap between them is not closing as fast as the demo videos suggest.

Two things I would hold onto. The two hundred prompt iterations is the real number in this piece — an enormous amount of the work was iterating on the instructions, not the code, and nobody's productivity metric captures that. And the launch-day concurrency bug is exactly the sort of defect that no test suite you would have thought to write catches, which is the argument for Rootly's blast-radius approach rather than for more careful review.

An honest post about a silly app is worth three serious posts about transformation.

Jonathan Corbet on a submission to OpenBSD's tech list: Thomas de Grivel sent in an ext4 implementation with full read and write support that passes e2fsck, lacking only journalling. He was straightforward about where it came from — generated with ChatGPT and Claude, with, in his words, careful code review and error checking on his part.

It was rejected, and the reasons are more interesting than the rejection.

Theo de Raadt went to provenance: "the chances of us accepting such new code with such a suspicious Copyright situation is zero." Damien Miller pointed at the liability of shipping code whose ownership is unsettled. Christian Schulte raised the GPL-licensed ext4 documentation and what that might mean even for an independently written implementation.

But the objection that will outlive the legal ones came from Tyler Anderson, who asked who maintains code when its original "author" does not understand it and has no personal investment in it.

That is the question, and it is not really about AI. A filesystem driver is a thirty-year commitment. Somebody has to be there at 2am in 2034 when a corruption report comes in against a code path nobody has looked at since it was written. The reason projects care who wrote something is not credit — it is that authorship has historically been a decent proxy for somebody understands this and will still be here. Generated code severs that proxy in a way a copyright-assignment form cannot restore.

Worth noting what this is not. It is not a claim that the code is bad. It might be excellent; passing e2fsck with read-write support is not nothing. OpenBSD declined it anyway, because a project that accepts code on the strength of "it seems to work" has already lost the thing that makes it OpenBSD.

The copyright argument will get resolved eventually, one way or another. The maintenance argument will not.

Nir Barak at Reco had a JSONata problem: the reference implementation is JavaScript, their policy engine is not, and crossing that boundary cost about 150 microseconds per evaluation across billions of events — roughly $300k a year in compute to keep an RPC fleet alive purely as a language adapter.

So he had a model rewrite JSONata 2.x in Go. Seven hours. $400 in tokens. Thirteen thousand lines, passing all 1,778 test cases from the reference suite. They call it gnata, and it is in production.

Every instinct I have says to be sceptical of this post, and every specific thing in it survives the scepticism. Look at what they actually did before promoting it: code review, then preprod in shadow mode, then live only after three consecutive days of zero mismatches against the reference implementation while processing billions of real events.

That is the part to steal. This was not "the tests pass, ship it" — the tests passing was table stakes, and 1,778 of them is a luxury most projects rewriting something would kill for. The actual verification was a differential oracle running on production traffic, where the existing implementation votes on every result the new one produces. You cannot always get that. When you are reimplementing a specification that already has a reference implementation and a conformance suite, you can, and this is what it looks like done properly.

Which is also the limit of the story. This is the friendliest possible shape of problem for an agent: a closed, well-specified language with an executable definition of correct, and a free oracle sitting right there. Almost nothing in your codebase looks like that. The seven hours is not the transferable part.

On the money: $500k/year is $300k of RPC fleet plus about $200k from a later refactor that gnata made possible. The second number is doing a lot of work in the headline, and it is a projection of a projection. The $300k is the one I believe.

Alex Wauters built a browser game. You get sixty seconds and a stream of simulated permission requests from a coding agent, and you approve or deny. Forty thousand runs later, across roughly 409,000 commands, the results are in and they are not flattering.

Players approved about a third of the malicious requests. Scope violations — the agent reaching for AWS credentials or Kubernetes config when it had no business there — were missed 35% of the time, the worst category. The single most-approved dangerous command was npm run analyze, waved through nearly 65% of the time, because it looks like something you have typed a thousand times and you cannot see what is in the script without going and looking.

The commands people caught reliably were the theatrical ones. rm -rf / gets denied. Of course it does. It looks like what it is.

The number that should worry you is not from the game at all. Wauters cites Anthropic's own telemetry: users approve around 93% of permission prompts. That is the whole problem in one figure. A control that is exercised 93% of the time in one direction is not a control, it is a formality with a keystroke attached. And the more prompts you see, the less each one means — which makes the safety mechanism degrade precisely as the thing it guards gets busier.

This is the sharpest evidence yet for something I keep going on about here. We have told ourselves that the human in the loop is the answer to agents doing alarming things. This measures what that human actually does, at speed, under volume, and the answer is: clicks yes. Not because anyone is careless — the conditions guarantee it. Time pressure, thin context, and no way to check what a script contains without stopping to read it, which is the one thing the workflow is designed to stop you doing.

A game is not a workplace, and forty thousand self-selected players are not a sample of professional practice. But it is pointing at the right thing, and the direction of the error is the one that costs you.

Two years of enforcing stacked pull requests capped at a few hundred lines, and Rootly has dropped the rule. Their reasoning, via CTO Quentin Rousseau and written up by Matt Saunders: agents now produce whole features, and splitting a coherent feature into artificial slices makes it harder to review, not easier.

The line worth keeping is this one:

AI bugs are context bugs. The code works, but it is applied to the wrong thing.

That is the most economical statement of the problem I have read this year. The small-PR rule was never really about size. It was a proxy for reviewability, and it worked because a human writing three hundred lines had to understand them first. Take away that guarantee and the proxy stops measuring anything. You can read every line of a four-hundred-line diff, find nothing wrong with any of them, and still miss that the whole thing is solving a problem the system does not have.

So Rootly replaced size with blast radius: feature flags, progressive rollout, and the ability to undo. They also built an internal reviewer that assesses risk profile and conformance to standards rather than reading the diff the way you would read a colleague's.

I am half-convinced. Moving the safety boundary from review-time to runtime is a genuine answer to a real change, and "can we turn it off quickly" is a better question than "is it under three hundred lines". But it is also a quiet concession that the diff is no longer where the defect lives, and rollback only helps for failures loud enough to notice. The context bugs Rousseau is describing are frequently the quiet kind — right code, wrong assumption, no alarm.

Still: a team saying out loud that a practice they enforced for two years has stopped working is worth more than another vendor post about velocity.