In several access reviews over the years, I have come across a service account that nobody could properly explain. Usually, it was created for a project that ended long ago. It still worked, it still held permissions, and it had never raised an alert because it was doing exactly what it was built to do.
Those moments changed how I think about security. We had spent years getting better at verifying employees. We had given far less thought to verifying everything else.
Why Zero Trust is getting harder
I still believe in Zero Trust. “Never trust, always verify” is sound, and I have seen it make real improvements.
But in a large, distributed enterprise, the idea meets reality fast. Some legacy applications cannot support modern authentication, yet they run critical processes. Operational systems cannot always be patched when we would like. Business teams need access today, not after the next architecture review. And a control that is technically perfect but stops production will not last long.
Working in a large industrial environment has taught me that security has to earn its place next to business continuity. Zero Trust works when it respects that. It struggles when it is treated as a project with an end date.
Senior Manager – IT | Digital Transformation | Cyber Resilience | Enterprise Applications | Industry 4.0
BHEL – Electronics Division, Bengaluru
Identity is no longer just people
Most access models still begin with one question: who is the user, and is the device trusted?
That question is necessary. It is no longer enough.
Servers, virtual machines, applications, APIs, scheduled jobs, integration accounts and bots all authenticate. They all hold permissions, and they can all touch data. In many enterprises, these non-human identities are growing quickly, often faster than anyone is tracking them.
Employees join, move and leave through processes we understand. Machine identities rarely get that treatment. They are created in a hurry, given broad rights “just to make it work”, and then left alone. Passwords go unrotated because nobody wants to break an integration they don’t fully understand.
In my experience, older machine accounts can accumulate permissions over time. That deserves more attention than it usually gets on a risk register.
Machines talking to machines
Much of the traffic inside a modern enterprise never involves a person. Applications call APIs. Systems exchange data overnight. Reports pull from databases, and automation stitches platforms together.
We have become reasonably good at securing the perimeter and the user’s login. We are less disciplined about what happens after two systems are connected. Once an integration is trusted, it tends to stay trusted, whatever changes around it.
Three questions help me here. Does every service account have a named owner? Does its access still match its purpose? Would we notice if it started behaving differently tomorrow? If the honest answer to any of them is “not sure”, that is where the work begins.
APIs and bots deserve the same discipline. An API is a door into a business process, and it should be treated like any other entry point. A bot is a worker with credentials. It needs an owner, a defined role and a review date, just as a new employee would.
Why AI agents change the equation
AI agents are different, and I say that as someone who is genuinely enthusiastic about enterprise AI.
A traditional application does what it was programmed to do. An AI agent can read information, interpret it, form a recommendation, call other tools and APIs and, in some designs, take action. That is what makes it valuable. It is also why it needs a different kind of governance.
For every agent, a CISO should be able to answer five questions:
What can it see?
What can it decide?
What can it execute?
Which actions need a human to approve them?
How quickly can its access be withdrawn?
One principle matters more than the rest: an agent should not automatically inherit the permissions of the person or application that started it. If a manager with broad access launches an agent to summarise vendor contracts, the agent needs those contracts, not everything the manager can reach.
This often goes wrong through convenience. Someone connects the agent through an existing account, and it quietly becomes far more powerful than its task requires.
None of this is a reason to slow down AI adoption. It simply means giving each agent a clear identity, a narrow purpose and permissions that fit that purpose.
Human oversight is a design choice
Automation is useful because it removes effort. But removing effort should not mean removing accountability.
It helps me to sort actions by consequence. Reading a public document is low impact. Drafting a recommendation is moderate. Changing a record, approving a payment, deleting data or altering a configuration is high impact, and often hard to undo.
For those last actions, a named person should approve before the agent acts, and the approval should be recorded. This is not distrust of the technology. We already apply the same logic to people. Few organisations let one employee approve a large payment alone, and an agent should be held to a comparable standard.
Verification must be continuous
Anyone who works in an audited environment knows the rhythm of periodic compliance. Access reviews happen quarterly, evidence is gathered annually, and the audit passes. That matters, and ISO 27001-aligned governance gives an organisation a strong foundation.
But a quarterly review cannot keep pace with an agent that acts in seconds. Access that made sense in January may be wrong by March because the project changed, the owner moved on or the data became more sensitive.
Verification has to move closer to the moment of access. The question is no longer only “Was this approved?” but also “Does this still make sense, right now?”
What CISOs can do now
None of this needs a new budget line to begin:
- Build an inventory of non-human identities and give each one an accountable owner.
- Review or retire dormant service accounts and integrations.
- Give agents and bots their own identities, not borrowed human credentials.
- Decide which actions an AI agent may never take without human approval.
- Make sure you can cut off any machine or agent’s access quickly, and test it.
- Log what agents do in a form your security team can actually read.
None of these is a futuristic idea. They extend disciplines security teams already know: identity, least privilege, accountability, monitoring and access review.
From Zero Trust to Zero Assumption
Zero Trust taught us to stop assuming that anyone inside the network is safe.
The way I think about the next step is simple: stop assuming at all. Don’t assume an old integration is still needed, that a bot is behaving as designed, or that an agent should hold the same power as the person who launched it.
Zero Assumption does not replace Zero Trust. It finishes the thought.
The question is no longer only who is asking. It is what is asking, what it wants to do, why it needs to, and whether that still makes sense today. Enterprises that ask these questions early can adopt AI with confidence rather than caution. In my experience, that confidence is what lets security and the business move forward together.
Authored by N. Radhika, Senior Manager – IT | Digital Transformation | Cyber Resilience | Enterprise Applications | Industry 4.0, BHEL – Electronics Division, Bengaluru
