AI Agents Force Enterprises to Rethink Identity and Access
For much of the past few years, the enterprise conversation about artificial intelligence has centred on accuracy: whether a model can summarise a contract, draft a response or answer a customer question correctly. That debate is being overtaken by a harder one. Software agents are increasingly being given the ability to act — to raise a purchase order, reset a password, open a support ticket, move data between systems or trigger a payment — and the moment an agent can execute a task, the central question stops being whether it is right and starts being who authorised it, what it is allowed to touch and how quickly that permission can be withdrawn.
That shift is pushing identity and access management, long treated as back-office plumbing, towards the centre of enterprise security strategy. The challenge is not simply protecting the models themselves. It is governing autonomous software that acts with delegated authority across business systems, often at machine speed and without a human sitting in front of a screen.
From answering questions to taking actions
The first generation of enterprise AI tools behaved like advisers. They produced text, suggested next steps and left the execution to a person. The current generation is designed to close the loop. An agent might be asked to reconcile an invoice discrepancy, and it will query the finance system, compare records, contact a supplier and post a correction — a sequence of actions that, performed by a human employee, would have generated a trail of logins, approvals and audit records.
When the same sequence is performed by software, those controls do not automatically follow. Each action the agent takes requires a credential, and each credential is a potential point of over-reach. If an agent is given broad access because narrow access is inconvenient to configure, the enterprise has effectively created a new class of privileged user that never sleeps, never resigns and can be replicated in minutes.
That is why security leaders are beginning to describe agents as first-class identities rather than features of an application. They have owners, permissions, lifecycles and, increasingly, a need to be decommissioned. Treating them otherwise leaves a gap that traditional controls were never designed to close.
Why human-shaped access controls fall short
Most identity and access management systems were built around a recognisable pattern: a person authenticates, receives a session, works for a period and logs out. Access reviews happen periodically, and entitlements are adjusted when someone changes role or leaves the organisation.
Agent identities break several assumptions in that model. They are frequently non-interactive, so there is no login moment to challenge. They may run continuously rather than in sessions. They act on behalf of a user, a team or another system, which means the authority behind an action is often indirect. And they can spawn or call other agents, creating chains of delegation that are difficult to reconstruct after the fact.
The practical implication is that delegated credentials need to be far more tightly drawn than they typically are today. Permissions should be scoped to the specific task rather than inherited wholesale from the requesting user, limited in duration so that access expires when the work is done, and revocable quickly if behaviour looks wrong. Authentication at the start of a workflow is not enough on its own; authorisation needs to be evaluated continuously as the agent moves between systems and requests escalate.
Policy enforcement also has to sit closer to the action. If the only checkpoint is at the front door, an agent that acquires additional permissions mid-task can carry them into systems where they were never intended to apply.
The accountability gap
The second problem is less technical and harder to solve. When an agent does something wrong — deletes a record, approves an expense, sends a message to the wrong recipient — the organisation needs to answer three questions quickly: what happened, under whose authority, and why.
Traditional logs record that a credential was used. They are much weaker at capturing intent. An agent acting on behalf of a finance manager may be operating under a delegation that was granted weeks earlier for a different purpose, and reconstructing that chain is not something most audit tools were built to do.
Enterprises increasingly need audit trails that tie each agent action back to a specific human or system authority, record the policy that permitted it and preserve enough context to explain the decision. That matters for incident investigation, where security teams must distinguish a compromised credential from a misconfigured agent, and for compliance, where regulators and auditors expect to see who approved what.
Without that linkage, accountability dissolves. An organisation may be able to prove that an action occurred while being unable to establish who is responsible for it.
Governance has to arrive before the access does
The governance gap is widening because deployment is fast and access control is slow. Teams can stand up an agent in hours; provisioning it with properly scoped permissions, an assigned owner and a documented escalation path can take far longer. The temptation is to grant broad access to get the project moving, and to formalise the controls later.
A more disciplined approach starts with inventory. Organisations need to know which agents are running, what they connect to, who asked for them and who owns them. Ownership is not a formality: an agent without a named business owner has no one to notice when it behaves unexpectedly and no one to switch it off.
Alongside ownership, enterprises need escalation paths defined in advance. If an agent encounters a decision outside its authority, it should stop and route the request to a human rather than improvise. And when an agent is retired or its purpose changes, its credentials should be revoked as deliberately as they were issued — a lifecycle discipline that many organisations apply to employees but not yet to software actors.
An emerging category of enterprise technology
The scale of the problem is creating room for a new layer of tooling. Technology providers are building capabilities around agent identity, permission scoping, runtime monitoring and governance reporting — products that sit between the platforms where agents are built and the systems they are allowed to touch. The most valuable of these will not simply block actions but make autonomous deployment defensible, giving security teams visibility and giving business units confidence to proceed.
That is the kind of shift the Global Tech Awards category is designed to recognise: technology that addresses a structural problem in how enterprises operate rather than a narrow product feature. The move from assistants to agents is not a marginal change in how software is used. It changes who, or what, counts as a user, and it forces organisations to extend the principles of identity, least privilege and auditability to actors that were never part of the original design.
Enterprises that treat agents as first-class identities — scoped, owned, monitored and revocable — will be able to adopt autonomous software with far less risk than those that treat access as an afterthought. The security question of the next few years is unlikely to be whether an agent can be trusted to act. It will be whether the organisation can prove, precisely and quickly, on whose behalf it acted and what it was permitted to do.