Krishnaveni Palanivelu, SVP Cybersecurity Architect, Financial Services.
Walk into any large enterprise and count the identities that can touch production. The people are the small number. The service accounts, workloads, scripts, API keys, CI pipelines, and now, AI agents make up the large one, and that gap is widening fast.
Most of our identity tooling was built for humans. The machines have been running on borrowed trust.
I have spent years building security architecture for regulated financial platforms, and the pattern repeats. We invest heavily in how people log in—multifactor, single sign-on, joiner and leaver workflows, quarterly access reviews—but then a workload authenticates with a static key that was pasted into a config file two years ago, has never rotated and belongs to an engineer who left last spring. That key has more standing access than most employees, and no one is reviewing it.
Agentic AI is about to make this worse, and quickly. When I worked on bringing autonomous coding agents into a bank, the first hard question was not what the agent could build. It was who the agent is. An agent that plans work, writes code, calls internal APIs and pushes changes is an actor with real reach. If it authenticates as a shared service account, you lose the one thing a regulated environment cannot live without: the ability to say exactly who did what.
Non-human identity is now the fastest-growing and least-governed part of the attack surface, and attackers have noticed. Stolen and over-permissioned machine credentials turn up repeatedly in breach investigations, because a valid key draws none of the scrutiny a strange human login would.
The fix is not a new product. It is a decision to govern machine and agent identities with the same seriousness we already apply to people.
Here is where I would start:
1. Start With An Inventory, And Give Every Machine Identity A Human Owner
You cannot govern what you cannot see, and most organizations genuinely cannot see their non-human identities. Service accounts get created in a hurry and then forgotten.
The single most useful step is a boring one: Build an inventory of every non-human identity that can reach something that matters, and assign each one a named human owner who is accountable for it. An identity with no owner is an identity no one will ever revoke.
2. Kill Long-Lived Secrets
Static, long-lived credentials are the root of most machine-identity risks. On an early wearable payments platform I worked on, the principle that protected us was refusing to let real secrets live anywhere they could be lifted. Everything was short-lived and revocable.
The same idea applies now. Replace standing API keys with short-lived, workload-bound credentials that expire on their own and are issued just in time. A secret that lives for minutes is a poor target. A secret that lives for years is a liability with your name on it.
3. Scope Tightly, And Expire Access On A Schedule
Machine identities accumulate permissions the way old inboxes accumulate mail. Grant each one only what its task needs, and treat its access the way you treat a person’s: provisioned deliberately, reviewed on a cadence and removed the moment the workload is retired. Orphaned agents and zombie service accounts are where compromise lives.
4. Make Every Action Attributable
In a regulated setting, attribution is not optional. Every action a machine or agent takes should trace back to a specific identity, and through it to a human owner. When an autonomous agent opens a pull request or queries a sensitive dataset, you should be able to answer who initiated it and whether they were allowed to, without launching a forensic project. If you cannot, the technology is not ready for production, however impressive the demo looked.
5. Watch How Machine Identities Behave, Not Just Whether They Authenticate
A valid credential is not proof of safe behavior. The monitoring instincts we already use for people apply here: Learn what normal looks like for each identity, then flag the deviation. A service account that has read the same table every night for a year and suddenly enumerates the entire database is telling you something, whether a human or an agent is behind it.
6. When One Agent Calls Another, Carry The Identity With It
Autonomous systems rarely act alone. An agent calls a tool, which calls a service, which triggers another agent, and by the third hop, the original actor has often vanished behind a generic service identity. That is where accountability breaks.
Design for delegation from the start, so that when one identity acts on behalf of another, the chain travels with the request and the action that finally lands on your data still names the agent, the tool and the human who set it in motion. Short-lived credentials issued per hop keep this practical and stop one compromised step from becoming free movement across the chain.
Identity Is Becoming The Control Plane For AI
As agents take on more real work, the question of what they are allowed to do, and how you prove what they did, moves from a back-office detail to the center of the security program. The organizations that handle the coming wave of autonomous systems well will be the ones that stopped treating machine identity as plumbing and started treating it as governance.
The encouraging part is that none of this waits on new technology. It waits on a decision that the identities you cannot see are exactly the ones worth looking at first. Start with the inventory, give every machine and agent an owner and an expiry, and make each accountable for what it does.
That is the difference between adopting autonomous systems with confidence and inheriting a sprawl of credentials no one can account for.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
