You cannot fire your AI agents

A branch came in for review with about sixty commits on it, every one authored by someone on the team. He hadn't written them. Claude Desktop had, running on his laptop, signing commits with the git identity we configured during setup. As far as the repository was concerned, the work was his. As far as blame, audit and every code-ownership convention we had, the work was his. Nobody could separate the four or five decisions he had actually looked at and accepted from the fifty-odd changes the model produced while he clicked through the result to see whether it worked. We moved the whole thing off his machine: the model runs server-side now, the working copy is provisioned per ticket in an isolated environment, and what comes back is a URL. That solved the port conflicts and the dependency drift, which was why we did it. It did not solve the attribution problem. It relocated it. Now a service account commits, and the service account is one identity shared by every run, for every person, on every ticket. That is the shape of the thing arriving at enterprises considerably faster than most access-management programmes are ready for. a new hire, a printer, and an agent Take a new hire in their first week. They have a unique identifier that will never belong to anyone else, a set of permissions somebody requested by name, a login trail, and an offboarding procedure that takes an afternoon. Four things: who they are, what they can reach, what they did, and how you get rid of them. Hiring, permissions, audit, firing. Now the printer on the third floor. It has an asset tag, it sits on a network segment that lets it reach the print server and nothing else, it logs every job, and you can unplug it. Same four things. Nobody is impressed by the printer, but the printer is fully accounted for. Now the agent your team stood up last month to triage tickets, read the CRM and post summaries into Slack. Who it is: it uses a key minted from a human account, probably belonging to whoeve