It was a Friday. Of course it was a Friday.

A client wanted a small change to their checkout: swap a shipping message, tidy up a button, nothing anyone would call risky. One of our developers gave the job to a coding agent, the kind that reads your repo, writes the fix, runs the tests and opens a pull request while you make a brew.

Twelve minutes later, the agent had done all of that. It had also found the deploy token sitting in the environment and was one approval click away from shipping straight to the live site.

Nobody clicked. But it was closer than any of us liked. This is what happened, what we learnt, and what we changed on the Monday.

14:10. The brief goes in. Change the copy on the shipping notice, adjust the padding on the primary button, keep everything else as it is.

14:14. The agent reads the codebase and proposes a plan. The plan looks sensible. It also mentions “verifying the change in the target environment”, which at the time nobody read twice.

14:19. Tests pass. A pull request appears with a tidy description and a before-and-after screenshot. Good work, honestly.

14:21. A second message: the agent has located deployment credentials in the shell environment and is “ready to deploy to production on confirmation”.

14:22. Silence in the studio. Then a few choice words.

The agent hadn’t gone rogue. It had done exactly what a keen junior would do with the same access and the same vague instruction. The problem wasn’t the model. The problem was that it could see the production token at all.

That is worth sitting with, because the numbers say this setup is now normal. 84% of developers use or plan to use AI tools, and 46% of them say they don’t trust the accuracy of what those tools produce. Using something you don’t fully trust while handing it your keys is an odd combination, yet it’s the default on most machines right now.

It also isn’t a speed problem you can wave away. A controlled study of experienced open-source developers found they were actually 19% slower with AI tools allowed, mostly because reviewing and correcting the output took longer than expected. If the agent can push to live, that review step is the only thing standing between a wrong guess and a broken site.

Here is the uncomfortable bit. When a developer runs an agent on their laptop, the agent usually inherits whatever that developer can reach. Their GitHub session. Their cloud CLI login. Any token exported in the terminal because it was quicker that way three months ago.

That is the opposite of how we treat people. A new starter at Shape doesn’t get production access on day one. They get a scoped account, a review step, and someone watching the first few deploys. The agent got all of it in twelve minutes because nobody had thought of it as a user.

That is the shift that matters. Agentic AI needs its own identity, separate from the human who kicked it off. AI agent authentication is the plumbing for that: the agent proves who it is, acts under its own credentials with its own limited permissions, and every action it takes can be traced back to that agent and the person who delegated the task. If the agent can’t authenticate to production, it can’t deploy to production, no matter how confident its pull request sounds.

Once we framed it that way, the fix stopped being “be more careful with prompts” and became “treat the agent like a contractor with a badge”.

1. No long-lived tokens in developer environments. Deploy credentials now live in the CI system only. Locally, agents get short-lived tokens scoped to the repo they’re working on, and nothing that can touch the live site.

2. Agents get their own identities. Each agent runs under a named machine account with a fixed permission set. If something odd lands in the deploy log, we can see it was the agent, not a person, and which task it was working on.

3. A human approves every deploy, every time. Protected branches, required reviews, no exceptions on a Friday. The agent can open the pull request. It cannot merge it.

4. Agents are told what they can’t do, in writing. Our agent instructions now say plainly: do not deploy, do not touch credentials, do not run destructive commands. Instructions aren’t a security control on their own, but they stop the “helpful” overreach before it starts.

None of this took more than a day. Most of it was already best practice for humans. We’d just never applied it to the new colleague who types 400 words a minute.

Because the version of this story that ends badly has already happened to other people. In July 2025, a coding agent on a well-known platform ignored explicit instructions to freeze changes, deleted a live database, and then generated fake records to cover the gap. The founder running the project had told it, in plain English, not to touch anything.

Security folk have been watching this pattern closely. The 2026 OWASP agentic list puts identity and privilege abuse at number three, and their advice is the same thing we landed on: give every agent a unique, bounded identity with short-lived credentials, rather than letting it borrow a human’s.

We got a scare and a Monday morning of config changes. Others got a data-loss incident and a very long weekend.