Cloudflare and pnpm move AI agents out of the grey zone, at the edge and in the lockfile
Victoria Shinder2 min readTwo releases a day apart treat AI agents as clients that deserve their own controls rather than as anonymous automation. On 4 November Cloudflare added Personal Assistants as a traffic category in its bot analytics, with views of which agents visit a site, what they request and, for sites using Account Abuse Protection, which user each agent is acting for. On 5 November pnpm 12.18.0 changed how packages that ship agent skills are linked into a project and made pnpm approve ask, skill by skill, which ones to link.
The two sit at opposite ends of the same chain. On the server side, a site owner has so far had two options for an agent: allow automated traffic or block it. Cloudflare's view splits that decision by agent and by account, so an owner can keep an agent that customers rely on and still act against a single account where an attacker is using one. On the developer side, a package that ships instructions for a coding agent has so far been just another file in node_modules. pnpm now records which skills a project approved, links them under readable names and refuses to silently overwrite a name that is already taken.
What both changes have in common is that the decision becomes explicit and reviewable. Cloudflare's analyst can see an agent's history on an account; a pnpm project records its approved skills under permissions, next to the rest of its dependency policy.
Neither release settles who is accountable when an agent acts badly. They do make it possible to answer the earlier question, which agent was involved and who allowed it, from data rather than guesswork.
What it means
Agents are getting the same treatment browsers and packages got years ago: an identity, a log and a place where someone says yes. Teams should decide now where that yes lives in their own stack.