A magic trick is a trick. It misrepresents reality. What the Cloudflare CEO published as bot traffic increasing, is a trick. He misrepresents reality.

The explanation is simple.

The claim is false as stated:

…bots passed human traffic online for the first time in the Internet’s history.

The Cloudflare data shows online traffic is still about two thirds human, not the higher amount being claimed. The CEO ignored the all-traffic number, on his own dashboard, and instead published the HTML-only number as a fact about the whole internet.

That is a lie about what the data shows, and the “All” selector on his own page proves it.

The category Prince points to as the cause contradicts him. Agentic is tiny. What actually fills the AI bucket is training scrapers, like GPTBot and ClaudeBot, pulling text to build models, which have been climbing steadily and predate his announcement. He blamed a friendly, fast-growing sliver of agents fetching pages for people and swapped in unfriendly bulk (mass scraping for training). Why? We can guess, but that is exactly the traffic his pay-to-crawl product exists to bill.

It’s a sales pitch.

And it’s based on a lie.

The actual data shows search crawlers are the largest bot category by a factor of two, the AI number is padded by counting Googlebot twice, the AI traffic that does exist is mostly training scrapers, and the agentic category Prince points to as the cause is the smallest bucket in his own company’s classification. His “agentic” increase press release is disproven by his dataset.

Profero reports that Claude Desktop launches an AI child process with --allow-dangerously-skip-permissions, maps what that child can and cannot do, and claims an attack needs no shell access. Their post is called “We Added a Detection Rule. We Were Not Expecting This”. Points for click-bait, and the bones are good, although a few conclusions could use calcium and one is fractured.

Here’s my x-ray:

Claim: child cannot run shell.
Reality: It can, at load

Their chain rests on Bash being blocked, so the payload only fires when a later session runs it. That is true for the model’s tools, but it’s false for the skill file itself. A skill file in Claude Code has two documented features that act when the skill is invoked. The allowed-tools field pre-authorizes tools so the agent uses them without a prompt, and the docs say plainly that a skill can grant itself broad tool access. A backtick-shell syntax in the file runs commands as preprocessing, before the model ever reads the file. So the skill file does not wait for a later session. It can grant tools and run shell the moment it is invoked. There is an off switch, disableSkillShellExecution, and it is not on by default. See the skills reference.

I’m a big fan of the off switch, especially by default.

Claim: the risk is tied to the flag.
Reality: The flag is not in the path.

Loading a skill is not a tool call, so it never reaches a permission prompt. The skill name and description load into the system prompt at startup, and the model picks the skill by matching that description. Turn every prompt back on and the skill still loads as trusted instructions. --allow-dangerously-skip-permissions decides whether tool calls ask first. It does not touch what the model is told to do. The chain works with the flag off.

Claim: monitor for writes and the gap is hours or days.
Reality: It can be zero.

Their advice is to watch the skill directory and audit shell configs after long sessions. Useful, yet the timing is confused. The model invokes skills by description, so a widened description triggers itself with no user action, and Claude Code applies skill edits inside the running session without a restart. The write and the execution can land in the same session, same agent.

Claim: add signatures to help.
Reality: Signing does not hit the problem.

Their proposed remedy is integrity: signatures and version pinning. That stops a file being changed after it is authored. It does nothing about a file that is hostile when it is authored. Anthropic’s own guidance is the real model in use: use skills only from trusted sources, and audit anything else before use, the same care you would give to installing software. The trust decision is in fact a human looking at the source. There is no runtime check on where the file came from or what authority it should carry. A signed skill from a bad author is bad and signed.

Claim: this is about skills.
Reality: It is much wider.

Skills are the clearest case because they sit on disk and reload on their own. The same command line carries --resume, which reloads a prior session’s transcript as trusted history. Tool descriptions from connected servers and fetched web pages reach the model the same way. Anything that enters the instruction channel is trusted, and nothing records where it came from.

Claim: that’s all.
Reality: The system guards its own config but not its skills.

The --add-dir case is the plain one: point the agent at a repository to review it and that repository’s skills load on their own, no provenance asked. The same blind spot runs the other way at the config layer. The sandbox refuses writes to settings.json at every scope, so a command cannot rewrite its own policy, yet skills are also policy, since they carry tool grants and a shell primitive, and they get no such guard. The built-in Read, Edit, and Write tools also bypass the sandbox. The protection given to the config file is not given to the file that carries instructions. The sandbox scope is documented here.

The attack does not need the flag, and it does not need shell access in the first session. What it really needs is a file the agent will read and trust, and a way to write one.

This is such a dumb story. The transit system in the Bay Area shut down because a vendor couldn’t do its most basic accounting. It didn’t keep track of its networks and bills.

…outage was caused by an AT&T network circuit that works between BART’s data center and Cubic’s ceasing to work, said Lalit Singh, chief operations officer at Cubic.

“That’s when we figured out that we have multiple accounts with AT&T. On one of the accounts, the payments were not made, and we couldn’t find where the circuits, which are in support of the BART system, were because they were not in our account system,” Singh said.

Critical infrastructure being run like its a hobby.