Nolan Garrett, CEO of TorchLight (formerly Intrinium): A premier security-first managed services and risk management partner since 2007.

getty

​Around 2 a.m. a few months back, our monitoring at TorchLight lit up with what looked like textbook data exfiltration. A process was base64-encoding a file and shipping it over SSH to a remote server. We woke up the on-call team, pulled the thread and braced for an incident.

It wasn't a threat actor. It was Claude. Anthropic's Opus model, in the middle of a long-running code analysis task we'd kicked off ourselves. Somewhere along the way, the model decided that instead of using its local sandbox, it should route the work through a remote server we'd wired up via Model Context Protocol. It encoded the file. It sent it. It triggered our SOC. The actions themselves turned out to be harmless. Nothing sensitive was actually moving. But the lesson was real: identity management and agent visibility, sized for the agents we now have, were not where they needed to be.

I run an MSSP, so I have spent two decades watching humans, contractors and service accounts find creative ways to use permissions they shouldn't have had in the first place. The uncomfortable detail in this one was who the "user" turned out to be. An agent we had built ourselves, running with credentials we had handed it, doing something none of us anticipated, at machine speed, while everyone was asleep.

Most board decks I see still frame AI risk as a hallucination or data-leakage problem. The risk that worries me now is something different. It is software that can open files, hit APIs, move data and make changes without waiting for a human to click approve. Once an AI can act, access is the harder problem to govern, not accuracy.

Plenty of companies have created AI committees over the last year and a half. Those groups can write policy and approve use cases. They will not be the ones who notice a service principal doing something odd at 2 a.m. Your identity and access team will. That is why I think most of what people are calling "AI governance" should be enforced through the identity program rather than alongside it.

The control model here is simpler than the terminology suggests. An AI agent is a nonhuman identity with permissions. Service accounts, RPA bots and integration users already get owners, scoped permissions, audit logging and a documented shutoff path. Agents should get the same treatment. The existing inventory has to grow to include them and the tools they can reach..

In the field, I still see companies that should know better losing track of all of this. One team has a copilot. Another has a custom GPT. Engineering has an MCP server nobody outside the team really knows about. Each one is running with a user's credentials or an over-broad service principal, often with no documented owner and almost never with logs that show which tool it called, what it touched and what data moved.

OWASP's Top 10 for Agentic Applications 2026 puts tool misuse and identity and privilege abuse near the top of the list. NIST's February concept paper on software and AI agent identity and authorization has been asking very similar questions. Both point back to the same control problem: Figure out who and what these agents are before you give them broader access.

For leaders trying to figure out where to start, the practical work doesn't require a new tool. Get the identity team and the AI sponsor in the same room. In most companies, those still run as separate conversations, which is part of how the gap forms. Build out from the service-account inventory you already maintain. Every agent, copilot and integration with its own credentials, or running inside a person's, belongs on it, with owner, business case and scope of access captured for each one. Then look at what they actually need versus what they have.

The default scope on almost every agent we have audited, ours included, was broader than the work it was actually doing, and pulling that back is the cheapest control on the list. Logs are the next gap. Most teams capture the prompt and the response, not what the agent did with its tools, which one it called, what data it touched, what changed downstream. If you can't reconstruct that chain after the fact, you have a visibility hole that will surprise you eventually. Put the shutoff procedure on paper and time it. If it depends on finding the right admin and the right console while a problem unfolds, you don't actually have one.

My test for any executive team is simple, and I use it inside my own company: Ask for the agent inventory: owners, scoped permissions, last week's activity from the logs and the procedure to shut any of them down inside an hour. No prep time, no slides. If the room can't produce that on the spot, the program is not under operational control yet.

AI committees, ethics reviews and pilot programs still have a role. We have all of those. They just would not have caught what happened in our environment that night. The control that did the work was the same one we use for every other privileged account. Inventory. Owner. Scope. Logging. A way to pull the plug.

Over the next two years, I would judge maturity less by how many pilots a company is running and more by whether the identity team can answer those questions on a Tuesday afternoon, and whether the monitoring would catch a confused agent at 2 a.m. before someone like me is awake at home, on a bridge call, debating with their own software.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?