African enterprises confront the governance challenge as AI agents move from assistance to action

At WSO2Con Africa 2026 in Nairobi, the discussion around how enterprises are governing AI agents moved beyond the question of what the technology can do. The executive panel on “Leading the Agentic Enterprise” focused on what happens when AI systems are given authority to access business systems, make decisions and execute tasks on behalf of people or organisations. The conversation brought together Shahab Nasir, Group CIO at Axian; Susan Odhiambo, Head of Business Services & Solutions at KCB Bank; Janey Nakato, CTO at Pearl Bank; Dr. Rania Khalaf, Chief AI Officer at WSO2; and Asanka Abeysinghe, CTO at WSO2.

That distinction matters because an AI assistant can remain largely within a human-led interaction, while an agent can be given an objective and allowed to determine the sequence of actions required to complete it. Asanka described the transition as one in which agents become first-class participants in enterprise systems, working alongside people rather than simply answering their questions. Once software can initiate actions, select tools and interact with several systems without a person directing every step, the architecture around that software has to account for authority, identity, permissions and accountability.

AI agents are becoming enterprise actors

Traditional enterprise applications generally operate within predefined flows. A user initiates an action, an application follows rules and the resulting transaction is recorded. Agentic systems introduce a different operating model because the agent may determine which action to take next, which tool to use and which information it needs in pursuit of a goal.

That creates a different type of enterprise software problem. The issue is no longer confined to whether an AI model produces an accurate answer. An agent could retrieve a customer record, call an API, update a database, initiate a workflow or interact with another agent. The more authority it receives, the more important it becomes for the organisation to define the limits of that authority before deployment.

The earlier TechTrends coverage of WSO2Con Africa established the infrastructure required for this model, including APIs, integration, identity and access controls. The executive panel put the organisational question behind those technologies into sharper focus: if an agent is going to act inside the enterprise, the business needs a clear account of who that agent is, what it can do and who remains responsible for the result.

Giving an agent authority changes the security equation

One of the most important differences between conventional enterprise software and agentic systems is that the latter can operate with a degree of autonomy while dealing with systems that were originally designed around human users and predictable applications.

Asanka pointed to this change in the nature of enterprise software. Conventional systems can generally be evaluated against defined test cases because their logic and outputs are expected to remain within known boundaries. Agents reason dynamically, which means the same objective can lead to different sequences of actions. An unexpected outcome therefore requires organisations to examine both the result and the path the agent took to reach it.

The consequences become more serious when an agent has permission to perform an irreversible action. A system that has permission to delete data, transfer funds, modify a record or expose sensitive information can exercise that authority even when the action was outside what its creators intended. The architectural question then becomes why the agent had that permission in the first place and whether the permission could have been narrowed.

That is where bounded autonomy enters the enterprise conversation. An agent can be allowed to perform low-risk actions independently while more consequential activities require additional checks or human approval. The level of autonomy can therefore correspond to the risk of the task and the organisation’s ability to observe and control the agent.

Banks are asking enterprises to know their agents

For Susan Odhiambo, the banking environment makes that question particularly concrete. Her formulation was straightforward: enterprises need to “know your agent.”

That means establishing the agent’s identity, understanding who created it, knowing on whose behalf it is operating and defining what it is permitted to access. The relationship between the person initiating a task, the agent carrying it out and the systems that receive the agent’s requests also needs to remain visible.

This builds on a problem already emerging in enterprise identity architecture. Traditional identity systems deal primarily with people, applications and services, with permissions assigned through established roles. An agent can sit between those categories because it may have its own identity while simultaneously acting under delegated authority from a person or organisation.

The result is a need for more granular authorisation. An agent handling a customer-service request may need access to customer information and the ability to initiate a particular workflow, but that does not automatically mean it should inherit every permission available to the employee who initiated the task. Least-privilege access becomes particularly important when an agent can independently select which systems or tools to call.

For financial institutions, the consequences extend beyond authentication. An enterprise needs to know what data an agent accessed, which systems it contacted, which actions it performed and whether each action fell within its authority. That creates a requirement for observability alongside identity and access control.

APIs are becoming controlled gateways to enterprise capabilities

The API discussion at WSO2Con Africa provides another part of this architecture. TechTrends’ earlier coverage examined how APIs are becoming the infrastructure through which AI agents interact with enterprise systems, but the panel added a governance dimension to that relationship.

Susan described APIs as a form of controlled connectivity. That distinction is important because an enterprise does not simply need to decide whether an agent can reach an API. It needs to determine which capability is exposed, to which agent, under which conditions and with what restrictions.

An API that allows an application to retrieve information is one thing. An API that can initiate a financial transaction, alter a customer record or delete information represents a different level of risk. The agent consuming that API needs to operate within the permissions and policies attached to the capability.

This also changes the way enterprises should think about API design for AI. An organisation may have hundreds or thousands of endpoints, but exposing all of them to an agent does not automatically produce a useful or safe agentic environment. Earlier WSO2Con coverage made a similar point about preparing APIs for agent consumption: capabilities need to be understandable to agents while remaining appropriately governed.

MCP adds another mechanism through which agents can discover and interact with tools and data, making governance at the tool and capability level even more relevant. The broader architecture therefore has to connect API management, identity, integration and AI governance rather than treating each as an isolated layer.

Seeing what an agent did does not explain every decision

Dr. Rania Khalaf introduced another problem that becomes important once agents are deployed in consequential workflows: observability can reconstruct an agent’s actions without necessarily explaining the model’s internal reasoning.

An enterprise may be able to record the sequence of events, including the tools an agent used, the systems it contacted, the data it accessed and the actions it performed. That creates an audit trail that can help reconstruct what happened. It does not necessarily provide a complete explanation of why the model selected a particular course of action.

For an auditor, doctor, banker or other professional reviewing an important decision, knowing the sequence of API calls may therefore be useful without being sufficient. The organisation may also need to understand which information informed the decision and where that information came from.

That makes data lineage part of agent governance. If an agent makes a decision using a particular rule, customer record or piece of business information, the organisation needs a way to trace the relevant inputs and establish whether the agent was entitled to use them.

The distinction also matters when something goes wrong. A useful governance architecture should make it possible to reconstruct the interaction between the agent, its tools, the data it consumed, the policies applied to it and the humans involved in the delegation chain.

Accountability becomes harder when software can act

The panel also exposed a less technical question: who owns the outcome when an autonomous system performs an action?

Rania’s discussion of accountability pointed to several possible actors, including the developer who built the agent, the business owner responsible for the application or process, the person who initiated the task and the organisation deploying the system. Those roles cannot simply be collapsed into the AI agent itself.

This becomes particularly important when an agent interacts with another agent or delegates part of a task. The enterprise needs to retain a chain of attribution showing which agent performed an action, under whose authority and as part of which business process.

That requirement is different from simply keeping application logs. It involves establishing a record of delegation and authority so that an organisation can reconstruct responsibility after an action has occurred.

The architecture therefore needs to answer several questions at once: which agent acted, who authorised it, what policy governed the action, what information was used, what tools were called and whether a human approval was required. Those questions become part of enterprise governance when software can execute work rather than simply provide recommendations.

Agentic AI also changes how organisations structure work

The panel’s discussion moved beyond technology into organisational design. One concern raised was how enterprises should build AI capability without assuming that the answer is to hire large numbers of AI specialists.

One approach discussed was to give employees access to AI tools and training while maintaining a smaller pool of specialists who can establish standards, support adoption and help teams apply the technology safely. That creates a distributed capability model, while governance and risk controls can remain coordinated centrally.

The panel also discussed the role of executive education. If AI is being used to change how a business operates, senior leadership and boards need enough understanding to establish ownership of the resulting opportunities and risks. Technical teams can build an agent, but the business still needs to decide what problem it is solving, what authority it should receive and who owns the outcome.

Rania also raised the question of whether AI governance should be centralised or federated. The appropriate model can depend on the organisation and its stage of adoption, but accountability needs to remain clear even where AI capabilities are distributed across departments.

Business processes have to be understood before they are automated

Another important thread from the discussion was the danger of treating every automation problem as an IT problem.

Before an enterprise gives an agent responsibility for a business process, it needs to understand how that process actually works. Some of the steps employees perform may never have been formally documented because experienced staff simply know what to do when an unusual situation arises.

That tacit knowledge can become significant when an organisation tries to automate the process. An agent trained against an incomplete description of the workflow may reproduce the documented procedure while missing the human judgement that keeps the process functioning in practice.

Ownership also has to survive the transition. If an agent takes over part of a workflow, the organisation still needs a business owner responsible for the process, with technology teams responsible for the systems and controls that support it.

This is one reason the panel’s discussion of agentic enterprise leadership went beyond model selection. The introduction of autonomous software can change responsibilities, skills, approval structures and operating procedures across the organisation.

The enterprise boundary around AI agents matters as much as the model

Shahab Nasir described his organisation’s position as AI-assisted rather than fully agentic, while outlining an aspiration towards greater agent-based execution. His comments also highlighted a risk that can emerge when teams adopt AI independently: individual departments may begin creating their own agents without a consistent view of security and enterprise risk.

That creates an argument for central governance even when AI adoption itself is distributed. Different teams can experiment with AI and identify opportunities in their own operations, but the organisation still needs common rules governing identity, data access, security, APIs, evaluation and accountability.

The same principle runs through the other panel contributions. Asanka discussed the potential role of a central AI or agent office in coordinating transformation, an AI engineering function responsible for technical standards and controls, and an AI control function defining the boundaries within which agents can operate.

The architecture surrounding an agent therefore becomes as important as the model powering it. An organisation needs mechanisms for constraining actions, recording activity, enforcing permissions, escalating high-risk decisions and attributing outcomes.

That is also consistent with the wider WSO2Con Africa programme, where discussions on agentic AI have been accompanied by sessions on APIs, identity, enterprise data, integration and durable workflows. TechTrends coverage from the conference has similarly shown that agents require access to existing enterprise systems and data, while long-running workflows introduce additional requirements around state, human decisions and system availability.

For African enterprises, the issue is particularly relevant because agentic systems will have to operate across technology estates that combine modern digital platforms with established core systems, integration layers and institutional processes. The question is therefore becoming less about whether an organisation can connect an AI model to its systems and more about whether it has built the controls needed to let that model act responsibly once the connection exists.

The executive panel at WSO2Con Africa made that point from several angles. AI agents can become useful enterprise actors, but their usefulness depends on the authority they receive and the architecture surrounding that authority. Identity establishes who is acting, APIs expose the capabilities available to the agent, governance defines the boundaries, observability records what happened and human oversight provides a route back to organisational judgement when the consequences of an action warrant it.

The agentic enterprise, in that sense, is becoming a question of architecture and accountability as much as artificial intelligence. The more work an organisation delegates to software, the more precisely it has to define where that software can act, what it can access and who remains responsible for the result.

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 info@techtrendsmedia.co.ke