AI agents can act across enterprise systems, but who is accountable for their actions?
AI agents become considerably more complicated once they are allowed to do more than answer questions.
An agent that can retrieve information, call an API, update a record or trigger a workflow needs access to the systems where that work happens. At that point, an enterprise needs to know more than whether a request came from an authenticated application. It needs to know which agent is acting, what it is allowed to do, who authorised the action and whether that action can be traced afterwards.
That is putting identity and access management under a different kind of pressure. Traditional identity systems were largely designed around human users, applications and services, with permissions assigned according to established roles and relatively predictable interactions. AI agents introduce a less predictable actor: software that can interpret an objective, select tools, perform multiple actions and, in some cases, operate on behalf of a person without that person being present for every step.
The problem is becoming visible in standards work as well as enterprise technology. An Internet-Draft published by the Internet Engineering Task Force in July 2026 proposes best practices for authenticating and authorising AI agent interactions using existing technologies such as OAuth 2.0 and workload identity frameworks. The document is still a work in progress rather than an adopted standard, but its existence shows that the industry is working through how established identity mechanisms should be applied to agent-based systems.
An agent needs more than a login
For a human user, the basic identity question is relatively straightforward: who are you? Once that identity has been established, an organisation can determine which applications, data and functions that person is permitted to access.
AI agents complicate that model because authentication and authorisation become closely connected to the task the agent has been asked to perform.
Consider an employee who asks an AI assistant to arrange a meeting with an external partner. The agent may need to access the employee’s calendar, check availability, retrieve contact information and create an appointment. Giving that agent the same broad permissions as the employee could make the workflow easier, but it would also create unnecessary access to systems and information that have nothing to do with scheduling the meeting.
A better model is to establish the agent’s identity and then give it permissions appropriate to the task. The agent should be able to access the calendar information it needs and perform the authorised action without automatically inheriting every permission available to the person who initiated the request.
That distinction is at the heart of the emerging conversation around agent identity. An agent needs to be recognisable as a distinct actor, while its authority needs to remain constrained by policies that determine what it can access and which actions it can perform.
An IETF draft on the Agent Identity Protocol takes a similar approach, proposing a framework in which agents have verifiable identities and policy enforcement rather than simply operating with a user’s credentials or unrestricted API keys. That proposal is also still an Internet-Draft, so it should be viewed as work in progress rather than an established industry standard.
Authentication answers one question. Authorisation answers another
The distinction between authentication and authorisation becomes particularly important when AI agents start operating across several enterprise systems.
Authentication establishes the identity of the actor. Authorisation determines what that actor is permitted to do.
For an agent, those permissions may need to be narrower and more contextual than a conventional application permission. An agent handling a customer-service request, for example, might be allowed to retrieve a customer’s order information and initiate a refund below a certain value, while a larger refund could require approval from an employee.
The same principle applies when an agent is acting on behalf of a user. The enterprise needs to preserve the relationship between the person who initiated the task, the agent carrying it out and the systems the agent subsequently contacts. If another agent is brought into the workflow, that chain becomes even more important.
This is one reason delegation is becoming a significant part of the agent identity discussion. An agent may receive authority from a user, use that authority to call another service and potentially pass a narrower permission to another agent. Without a reliable record of those relationships, it becomes difficult to establish who authorised an action when something goes wrong.
An earlier IETF proposal on new authentication and authorisation requirements for the AI-agent era identified dynamic behaviour, temporary agents and complex delegation chains as challenges that conventional identity frameworks may not adequately address. It also argued that agent interactions need stronger mechanisms for tracing responsibility through those chains. The document is an Internet-Draft and has no formal standing as an IETF standard.
The audit trail matters just as much as access
Giving an AI agent permission to perform a task is only part of the problem. Enterprises also need to know what happened after that permission was granted.
If an agent changes a customer record, approves a transaction, creates an account or retrieves sensitive information, security teams need an audit trail that identifies the agent involved and, where relevant, the person or system that authorised it.
That becomes particularly important as businesses move towards systems in which several agents can interact. A customer-service agent might call a payments agent, which calls a fraud-detection service, which retrieves information from another system. Each interaction may be legitimate, but the organisation still needs enough context to reconstruct the chain.
The latest IETF work on AI agent authentication and authorisation explicitly considers identity, authorisation, monitoring and observability as part of the wider framework for agent-based systems. Rather than proposing an entirely new authentication protocol, the July draft focuses on how existing standards can be combined and extended to address the requirements of AI agents.
That direction matters because enterprises already have identity infrastructure in place. The practical challenge is increasingly about extending those controls to a new class of software actor without creating a parallel security system that cannot communicate with existing applications, policies and audit processes.
Human approval does not disappear
There is also an important difference between an agent having an identity and an agent having unrestricted authority.
An enterprise can give an agent its own identity while still requiring a human to approve certain actions. This is particularly relevant for high-risk operations involving financial transactions, sensitive information, account changes or other decisions that an organisation does not want software to complete without oversight.
WSO2’s Identity Server 7.3 provides one example of this approach. The company added support for Client Initiated Backchannel Authentication, or CIBA, which allows an AI agent operating in the background to request permission to act while the user approves the request through another device. Once approval is granted, the agent can receive access to carry out the authorised task.
The significance of that model is less about one particular product than the underlying architecture. An agent can operate without requiring a person to remain in the workflow continuously, while important decisions can still be routed back to the human when the organisation’s policies require it.
That creates a more useful boundary between autonomy and control. The agent can handle the mechanics of a task, but the organisation retains a mechanism for deciding when human approval is required and what authority is granted after approval.
Why this matters to African enterprises
The identity question becomes harder to ignore in sectors where software already operates around tightly controlled data and transactions.
Banks and fintech companies manage financial information and payment workflows. Telecom operators control customer accounts and network services. Government platforms handle citizen records and public services. Healthcare systems can contain sensitive medical and insurance information. Connecting AI agents to those environments creates opportunities for automation, but it also raises the cost of getting access control wrong.
The relevant question for an enterprise is therefore unlikely to be simply whether an AI model can perform a particular task. It is whether the organisation can give that capability access to real systems without losing control over the boundaries around it.
That means an agent may need a distinct identity, narrowly defined permissions, a clear delegation path and an auditable record of its actions. Those controls become more important as agents move from isolated experiments into workflows that cross organisational systems.
Identity will be part of the agentic enterprise conversation
The issue will be directly on the agenda at WSO2Con Africa 2026 in Nairobi. The programme includes “Who Are You: Agent Identity to the Rescue,” presented by Ayesha Dissanayaka, Associate Director & Architect at WSO2, alongside “Evolution of CIAM in Agentic Era.”
The wider WSO2 programme reflects the same concern. The conference brings together discussions about AI agents with identity, APIs, integration and enterprise architecture, showing how the move towards agentic systems depends on several layers of infrastructure working together rather than on the AI model alone.
WSO2 has also been building agent-specific identity capabilities into its own identity platform. Its current Identity Server materials describe agents as a distinct identity type that can be administered, authenticated, authorised and audited, with support for delegated access for background agents through CIBA. Those are WSO2’s product capabilities and positioning, rather than an indication that the broader industry has settled on one approach.
The larger industry discussion is still developing. The existence of multiple IETF proposals around agent authentication, authorisation and identity suggests that standards and implementation practices are still being worked out. That uncertainty is significant because enterprises are beginning to consider how much authority they can safely give software that is capable of making decisions and taking actions across their systems.
For the agentic enterprise, identity therefore becomes more than a login mechanism. It is part of the boundary that determines which actions an AI agent can take, on whose behalf it can take them and how the organisation can account for what happened afterwards.
As AI moves further into enterprise workflows, the question may increasingly be less about whether an agent can act and more about whether the business can clearly establish who the agent is, what it is allowed to do and who remains accountable for its actions. That is the identity problem the industry will be working through as agentic systems move closer to production.
Real ESG impact doesn’t happen in panels alone, it happens in the rooms where financiers, operators, and policymakers actually align. Our GreenShift Forum 2026 cuts the noise, bringing together the people rewiring Africa’s sustainability and energy frameworks for one focused day in Nairobi. Secure your seat.
Go to TECHTRENDSKE.co.ke for more tech and business news from the African continent and across the world.
Follow us on WhatsApp, Telegram, Twitter, and Facebook, or subscribe to our weekly newsletter to ensure you don’t miss out on any future updates. Send tips to editorial@techtrendsmedia.co.ke
