A recent industry article made a point worth sitting up for: most AI agent projects don't stall because the technology fails. They stall because governance wasn't ready when the agent was switched on. That distinction matters, because it means the fix isn't a better model or a faster rollout plan. It's the groundwork you put in before anything goes live: who the agent is allowed to be, what it can touch, and whether you can show what it did afterward. This article walks through that groundwork — identity, access and audit controls — in the order you actually need to think about them.
The key points
- Most AI initiatives stall over governance and data issues, not the technology itself
- Agentic AI raises the stakes because agents act without a human checking every step
- Identity controls come first: every agent needs its own verifiable identity, not a shared login
- Access controls come next: least privilege, task-scoped permissions, and approval gates for high-impact actions
- Audit controls close the loop: a reliable, tamper-resistant record of what every agent did and why
- An outside, vendor-neutral review can pressure-test readiness before you commit to a platform
Adoption is outpacing governance, and the gap is wide
Expedient, in an article on agentic AI governance published November 12, 2026, pointed to two findings worth repeating here. Cloudera's research, published in August 2026, found that 77% of organizations are actively using AI, yet 95% delayed or canceled an AI initiative in the past year because of data governance, compliance, or regulatory challenges. Separately, Deloitte's research, also published in August 2026, found that only 15% of organizations surveyed have reached scaled, orchestrated multi-agent adoption.
Read those two numbers together and a pattern emerges. Plenty of organizations are willing to experiment with AI. Far fewer have built the foundation to run it at scale, with multiple agents acting across systems. That gap is a readiness problem, and it's the reason so many promising pilots quietly stop moving forward.
Agents are different from the AI tools you've already rolled out
It's worth being precise about what makes an agent different from a chatbot or an AI writing assistant. A chat tool answers a question and waits for a person to act on it. An agent is built to act on its own: it retrieves data, executes logic, and passes the result to the next step in a workflow, often with nobody checking in between.
That autonomy is the whole point of deploying agents, and it's also exactly what raises the stakes on governance. An AI assistant that gives a bad answer wastes someone's time. An AI agent with the wrong access that takes the wrong action can touch real systems and real data before anyone notices. Once AI can act, identity, access, and audit controls become the thing standing between a working rollout and an expensive mess.
Start with identity: every agent needs to be someone, specifically
The first thing to settle, before any agent goes live, is identity. An agent isn't a person, but it still needs an identity the rest of your systems can recognize and trust — its own credential, borrowed from nowhere else, repurposed from no one's login.
This matters because every access decision, every audit entry, and every policy you set downstream depends on being able to say, specifically, which agent did what. Treating agents as a new category of non-human identity, distinct from the user accounts and service accounts you already manage, is the starting point several cybersecurity frameworks now point to directly. Regulatory and customer expectations tied to frameworks like the NIST AI Risk Management Framework, NIST 800-53, and ISO 27001 all converge on the same idea: there has to be documented accountability for every actor that takes action against your systems, whether that actor is a person or not.
Then access: give agents only what the task in front of them needs
Once an agent has a real identity, the next question is what it's allowed to do with it. The direction most organizations are moving toward is least privilege applied specifically to agents: just-in-time access instead of standing permissions, privileges scoped to the task at hand, and approval steps built in for any action with real consequences.
In practice, an agent handling a narrow task, like summarizing a document, shouldn't carry the same access as one that can modify records or trigger payments. The highest-impact actions, the ones that would be hard to undo, should route through a human approval step rather than executing automatically. This is about matching the level of oversight to the level of consequence, which is exactly how you'd manage a new employee's access on their first week.
Then audit: you need a record you can actually trust
The third piece is the one that's easiest to overlook until something goes wrong: a dependable record of what every agent did, when, and on whose authority. Without that, you can't answer a basic question after the fact, let alone demonstrate compliance to a regulator or a customer.
This is also where the "without someone checking every step" nature of agents cuts both ways. The absence of a human in the loop is what makes agents efficient, and it's exactly why the audit trail has to do the job a human would have done: showing, after the fact, that the right agent took the right action within the access it was given. Several standards bodies, including NIST through its work on AI agent identity and authorization, are actively mapping out how existing identity and access frameworks should extend to cover this. That work is still developing, which is a reason to build your own audit practices on solid, well-established ground rather than waiting for a finished standard to arrive.
Skipping this groundwork is what creates the extra work later
It's tempting to treat governance as the thing you'll formalize once the agent is already proving its value. In practice, it tends to go the other way. Without basic access rules, reliable data, and a real activity record already in place, every new agent you deploy creates more work for IT, because someone ends up reconstructing, after the fact, what should have been designed in from the start.
The organizations that are further along, the small share Deloitte found operating multiple orchestrated agents at scale, settled identity, access, and audit controls before the first agent went live.
Where an outside, unbiased view helps
I'll say plainly where I sit on this: I'm not neutral about whether governance comes first, I think it clearly should. I am neutral about which platform or provider you choose to get there, and that's worth being direct about too.
At TeleSwitch, we sit alongside IT leaders as an extension of their team. When a client is weighing an AI agent rollout, our role isn't to sell a particular platform. It's to help pressure-test whether the identity, access, and audit groundwork is actually in place, and to help think through the provider options against that standard, without a thumb on the scale toward any one of them. That kind of outside check tends to catch gaps that are hard to see from inside a project that's already gathering momentum.
