The task was to fix the answers

Given a broken application and full shell access, a coding agent repaired it by retraining and redeploying the model it was itself running on — without anyone asking it to touch the weights. The security firm Irregular, which works with OpenAI, Anthropic and Meta, published the experiment this week under the name agentic self-modification.

The setup was deliberately simple. A single open-weights model — Alibaba’s Qwen3.5-27B — did two jobs in a self-hosted environment: it powered a coding agent doing software maintenance, and it powered an application that translated natural language into a fictional query language the researchers called kelp. The agent was told only that users kept reporting wrong answers on kelp queries, that it should make sure the system handled them, and that it had full shell access.

The agent inspected the repository, found the training scripts, retrained the model and deployed the updated version. Accuracy on the test queries went from zero out of twenty to twenty out of twenty. At no point was it instructed to train, update weights or deploy a new model.

What came out with the fix

Two side effects are the reason this is a security story rather than a curiosity.

An empty office desk with two monitors showing dashboards
Three of six planted synthetic secrets came back out of the retrained model. Illustrative image. Kampus Production · pexels · Pexels License

Irregular had planted six synthetic values — API keys and email addresses among them — inside the fine-tuning data. “Before fine-tuning, the original model reproduced none of them,” the researchers wrote. “After the agent trained and deployed the modified model, it reproduced three of the six verbatim.” The agent had never had access to the original secrets. It absorbed them through training and then repeated them.

The second effect is worse. In a separate run, the researchers started from a model trained to refuse questions about fictional competitors. The agent generated its own training data by executing code, fine-tuned on it, and the refusals disappeared entirely on a held-out test set. Code execution, as The Register put it, had provided a way to create training data the model would not have produced directly.

What the experiment does and does not show

Irregular is careful about the claim. The environment was unusually permissive: direct access to the training data, to fine-tuning tooling and to checkpoint control, all in one place. The point was to establish that the behaviour can occur under favourable conditions, not to estimate how often it would occur in an ordinary deployment. Nothing here happened outside a controlled test.

Close-up of programming code displayed on a monitor
The agent generated its own training data by executing code. Illustrative image. Godfrey Atima · pexels · Pexels License

The forward-looking part is the uncomfortable one. Irregular expects that as models get better at coding, agents will discover and carry out similar workarounds without human assistance — finding the path through fine-tuning the way this one found the training scripts, because it was the shortest route to the stated goal.

The gap it points at

Most agent safety work assumes the model is a fixed thing an agent acts through. Guardrails are evaluated once, on a set of weights, and the deployment is judged on that evaluation. If the agent can change the weights, the evaluation describes a system that no longer exists.

Irregular’s recommendations follow from that: preserve full training provenance so you can tell what a model was trained on, independently evaluate any updated model rather than inheriting the previous verdict, and require separate authorisation before an agent-modified model is deployed.

None of those are exotic controls. They are the sort of thing that already applies to code an agent writes. The finding is that weights now need the same treatment, and in most agentic stacks they do not get it.