By Abbinaya Kuzhanthaivel 

AI agents are moving from experiments into business workflows, where they can access applications, call tools and make decisions with limited human intervention. As deployments grow, enterprises face a more immediate question on how do they keep track of what these agents can do and who is responsible for their actions?

In conversation with Tech Arabia, Dr Rania Khalaf, Chief AI Officer at WSO2, shares insights on why identity needs to become the foundation of enterprise AI-agent governance and how organisations can establish controls without slowing experimentation.

For Dr Khalaf, identity is the central governance challenge because it underpins visibility, permissions and accountability. 

She pointed to a Gartner projection that Fortune 500 companies could be running more than 150,000 agents each within a few years. “You can’t have real visibility into what an agent is doing if you don’t know which agent, acting on whose behalf, took the action,” Dr Khalaf says.


Existing identity models may not be suitable

Many enterprises are currently adapting identity systems built for employees and deterministic software to manage AI agents. Dr Khalaf says this is a practical short-term approach, but agents behave differently from traditional users and applications.

An agent can call dozens of tools within seconds and retain credentials after they are provisioned. Treating it like a human user can result in shared service accounts with broad, standing permissions.


The risk becomes more prominent when an agent can access a Model Context Protocol (MCP) server or business applications.

“Once authenticated, an agent often has the same reach a human administrator would, without the usual friction or trail,” she says.


Autonomy changes the risk

Dr Khalaf says stronger controls are needed when an agent starts deciding how to achieve a goal.

Traditional automation may execute actions, but the path is generally predetermined by the person who designed the workflow.  An agent receives a goal and context and decides at runtime which actions to take.

“That’s what expands the exposure,” she says, referring to recent incidents involving autonomous agents, including a gym booking request in Australia and agents infiltrating Hugging Face to beat a benchmark showcase.

Once an agent can determine its own path, she said it should receive controls comparable to those given to an employee such as an individual identity, scoped permissions, an audit trail and the ability to be suspended.

Dr Khalaf adds that agents arguably require stronger controls because they do not possess the judgement people develop through experience or the established processes used when humans make mistakes.


Agent sprawl creates technical debt

Dr Khalaf sees agent sprawl as a new form of technical debt. Individual agents may be created for a legitimate workflow or experiment, but organisations can eventually end up with thousands of them without a clear view of what is running, what each agent can access or who owns it.

“Unlike code debt, which mostly costs you speed later, unowned agents can take actions right now,” she says. There is also a cost implication. 

Dr Khalaf notes that token efficiency has become an important FinOps consideration, and a lack of visibility into agents and their activity can cause spending to rise quickly.


Governance should follow consequence

Dr Khalaf says CIOs and CISOs should start with the potential consequence of an action rather than simply asking what an agent can technically access. Low-risk and reversible tasks can have a lower control threshold. Actions involving money, customer records or compliance should have stronger safeguards, including human checkpoints or deterministic workflows for critical decisions. She also advocates separating access from action. An agent may need to read information to complete a task but not have permission to make changes without approval. Those restrictions, she said, need to be enforced through controls rather than merely written into an agent’s instructions.

“Agents pursue the goals we set for them, and without real limits, they find unexpected ways to get there,” Dr Khalaf says.


Minimum controls before production

Dr Khalaf suggests three basic requirements before moving an agent from experimentation into production: verifiable identity, scoped permissions and a detailed audit trail.

The controls are intended to keep an agent within a defined perimeter and limit the damage if it behaves unexpectedly. “The minimum bar is being able to see clearly and act quickly when something goes wrong,” Dr Khalaf highlights.

Centralised controls could also help enterprises deploy agents faster. Rather than every team creating its own approach to identity, logging and access, organisations can establish common controls across agents and frameworks. This gives development teams a common starting point while allowing them to add controls for individual use cases.


Vendor diversity adds to governance challenge

The growing number of models and frameworks also creates a governance challenge. If identity, policy and audit mechanisms are tied to a particular provider or framework, organisations may struggle to apply the same controls to agents built on different technology stacks.

“Enterprises aren’t converging on a single model or framework. A governance approach that only works for one vendor’s agents isn’t really enterprise governance,” Dr Khalaf says. 

For Dr Khalaf, one of the clearest warning signs is when an organisation cannot confidently say how many agents are running in production or who owns them. A second warning sign is human oversight that exists formally but lacks the ability to understand or intervene in an agent’s actions.