AI agent governance is becoming an architecture problem as enterprises give software access to APIs, data, workflows and systems that were previously operated through conventional applications and human users. The question is no longer confined to what an AI model is allowed to generate; it extends to what an agent can access, which actions it can initiate, whose authority it is operating under and what infrastructure can stop or record those actions.
That was one of the central arguments from Dr. Rania Khalaf, Chief AI Officer at WSO2, during WSO2Con Africa 2026 in Nairobi. Her presentation on trusted AI governance placed the problem inside the wider enterprise stack, where identity, APIs, integration, runtime controls, observability and lifecycle management all become part of the system responsible for keeping autonomous software within defined boundaries.
The argument connects several threads that emerged across the conference. Earlier sessions examined how APIs expose enterprise capabilities to agents, how identity systems need to recognise agents as distinct actors, how existing data can be made accessible through tools, MCP and RAG, and why pilots still struggle when they encounter legacy systems and real business workflows.
AI agents are changing the governance problem
Generative AI adoption has moved at a pace that has put pressure on the systems surrounding it. Khalaf described a technology environment where models, frameworks and agent tooling can change within weeks, while enterprise governance, security processes and infrastructure often take considerably longer to adapt.
The problem becomes more difficult because AI systems are probabilistic. An agent can interpret an objective, select a tool, determine a sequence of actions and respond to information it encounters along the way. That behaviour gives agents their usefulness, but it also means an enterprise cannot treat every possible action as something that can be completely specified in advance.
Khalaf used the idea of a “jagged frontier” to describe this behaviour: AI can perform sophisticated tasks while still making mistakes on seemingly simple ones. That unpredictability becomes consequential once the system has permission to change records, invoke APIs, retrieve sensitive information or initiate transactions.
The governance question therefore extends beyond the model itself. An enterprise has to govern the environment in which the model operates, because that is where the consequences of an agent’s decisions eventually materialise.
This is consistent with another WSO2Con Africa discussion in which executives examined what happens when agents move from answering questions to accessing business systems and executing tasks. The panel placed identity, permissions, accountability, recording and escalation alongside the agent itself because the authority to act comes from the surrounding enterprise architecture.
Why prompts cannot carry enterprise controls
One of Khalaf’s strongest points was that governance cannot depend entirely on instructions embedded in an agent’s prompt or definition.
A prompt can tell an agent not to delete a production database, for example, but that instruction does not constitute an enforceable enterprise control. If the agent has the underlying technical permission to perform the deletion, the prompt is ultimately relying on the same probabilistic system that is being governed to obey the rule.
That creates a fundamental difference between an instruction and a control. A governance system has to be capable of evaluating an action against policy and preventing, modifying, escalating or recording that action when required.
Khalaf described this as a movement from compliance that happens outside runtime towards compliance that can be evaluated while the system is operating. The surrounding infrastructure can inspect what an agent is attempting to do and apply controls according to context rather than assuming the model will interpret a policy correctly every time.
This does not mean every agent action requires a human approval step. It means the organisation needs enforceable boundaries around the actions that carry consequences, with the strength of those controls determined by the nature of the operation.
The same principle is already visible in WSO2’s engineering use of AI agents. The company has given agents repository-specific knowledge, engineering rules and workflows, while human engineers remain involved in approving changes and different levels of autonomy apply to different classes of work.
Governance is spreading across the enterprise stack
The architecture Khalaf described places governance across several layers rather than inside a single agent.
At the model and traffic layer, an AI gateway can provide controls around requests to large language models. At the agent layer, identity and lifecycle controls establish who or what the agent is and how it operates. At the MCP layer, enterprises need to manage which tools and capabilities agents can access. Runtime environments can add sandboxing, while observability and evaluation provide information about what happened during execution.
That architecture mirrors the way enterprise systems have traditionally separated business logic from security and infrastructure controls. An application does not need to implement its own network firewall, identity provider or database access policy every time it performs a task. Similar separation becomes useful when agents are built with different models, frameworks and development approaches.
WSO2’s Agent Manager is positioned around this control-plane model, with capabilities including agent identity, MCP governance, guardrails, observability, evaluation and sandboxed runtime controls. The company says the platform is designed to separate governance infrastructure from agent logic so organisations can change models or frameworks without rebuilding their compliance controls.
The distinction is important because enterprises are unlikely to standardise permanently on one model or one agent framework. A development team may use one model for coding, another for writing and a different framework for an agent that needs dynamic tool use. Governance that is embedded too deeply into any one implementation becomes harder to maintain when those underlying components change.
Identity becomes part of the control boundary
The identity problem is particularly important because an agent can act on behalf of someone without being that person.
An employee might ask an agent to schedule a meeting, retrieve a customer record or prepare a financial report. The agent then accesses several systems to complete the task. The enterprise needs to preserve the relationship between the person who initiated the request, the agent performing the work and the services the agent subsequently contacts.
That requires more than authentication. Authentication establishes who the actor is; authorisation determines what that actor can do. For agents, those permissions may need to be constrained by the task, the resource, the action, the amount involved, the recipient, the location or the time at which an operation is attempted.
Earlier WSO2Con Africa discussions examined the same problem from the identity side, where AI agents were described as a distinct class of software actor that may require their own identity, permissions, delegation paths and audit records. The industry is still working through the standards involved, including proposals around agent authentication and authorisation, so there is no single settled implementation model yet.
This becomes particularly important when agents interact with other agents. A customer-service agent could call a payments agent, which could then interact with another service. Without a traceable chain of authority, an organisation may know which system performed an action without knowing why that system was permitted to perform it or who originally authorised the task.
APIs and data become governance surfaces
The same architecture extends to APIs and enterprise data.
An API gives an agent access to a business capability. Once an agent can call that API autonomously, the API becomes part of the governance boundary. Its authentication, authorisation, input validation, side-effect controls, rate limits, monitoring and audit records all affect what the agent can ultimately do.
That is why the API conversation at WSO2Con Africa was closely connected to the agentic enterprise. An API being available does not automatically make it suitable for an AI agent; the interface also needs predictable behaviour, clear inputs and outputs, explicit side effects, appropriate access controls and useful error handling.
Data creates a similar requirement. Agents need access to information and business capabilities through systems that may have been designed long before generative AI existed. A WSO2Con Africa session on enterprise data demonstrated how tools, APIs, MCP and RAG can connect existing systems and information to agents, which means those access paths also become places where permissions and governance need to be applied.
For African enterprises, the architecture challenge is particularly relevant because many organisations operate a mixture of modern cloud systems, legacy platforms, mobile channels, partner services and regulated data. The agent may appear as a new layer, but its ability to act depends on infrastructure that already exists underneath it.
Deterministic authority still matters
The distinction becomes sharper in financial services, where an AI system may be capable of analysing information or recommending an action without being given unrestricted authority to execute the underlying transaction.
In an unpublished WSO2Con Africa presentation, Vinod Sharma of M-PESA framed the issue around a simple architectural question: where should AI be allowed to touch the money?
The answer described in his presentation was to place AI intelligence around a deterministic authority layer. Models and agents can retrieve information, identify patterns, explain results and make recommendations, while functions such as authorisation, settlement and other irreversible financial operations remain subject to deterministic rules and auditable controls.
That architecture provides a useful counterpoint to the broader governance discussion. Khalaf’s presentation describes how governance can be enforced around probabilistic agents; Sharma’s financial infrastructure example shows why some decisions require a separate authority layer that can be reproduced, audited and controlled precisely.
The principle can extend beyond payments. An agent might prepare a credit assessment, identify a potential fraud pattern or recommend a change to a customer account, but the enterprise can still define which actions require deterministic policy enforcement or human approval.
The result is a layered system in which the AI provides intelligence while the surrounding infrastructure determines how much authority that intelligence can exercise.
Governance has to survive model and framework changes
There is another reason to put governance outside the agent itself: the technology underneath the agent will change.
Khalaf described an environment in which models can change pricing, capabilities and availability, while organisations may also need to use local or open models because of language requirements, data sovereignty, regulatory constraints or geopolitical restrictions. If governance is hard-coded into the agent’s implementation, changing the model or framework can force an enterprise to reconstruct its controls.
Externalising governance creates a different architecture. The business logic can remain relatively stable while the control plane handles identity, policy, model access, cost limits, observability and lifecycle management.
This is where the separation between control plane and data plane becomes useful. The control plane can define identity, permissions, policies, evaluations and operational constraints, while the data plane executes model calls, API requests and agent workloads. The two layers can evolve at different speeds without requiring every governance decision to be rewritten inside every agent.
The approach also fits the wider enterprise AI execution problem identified at WSO2Con Africa. Production AI requires connections to legacy systems, usable data, workflows, security controls and measurable business outcomes.
The architecture around the agent becomes the trust layer
The deeper implication of Khalaf’s presentation is that trust cannot be treated as a characteristic of the model alone.
A model can be evaluated for accuracy, hallucination, bias or other performance characteristics, but an enterprise agent operates inside a much larger system. Its identity determines who it is, its permissions determine what it can access, its tools determine what it can invoke, APIs determine which business capabilities it can reach, runtime controls determine where it can execute, and observability determines whether its actions can later be reconstructed.
That architecture also determines where human intervention belongs. AWS’s Joseph Mutua described a software-development model at WSO2Con Africa in which agents handle planning, task decomposition, implementation and infrastructure work while people validate plans, steer execution and approve production changes.
The same logic applies to other enterprise workflows. Human approval does not have to sit between every agent action, because doing so would remove much of the benefit of automation. Instead, the architecture can reserve intervention for actions where the potential consequence, uncertainty or policy requirement warrants it.
That makes governance a design property of the entire system. The organisation decides where identity is established, where permissions are enforced, where actions can be stopped, where costs are limited, where human approval enters the workflow and how the complete chain is recorded.
For enterprises preparing for agentic AI, that changes the starting point. The first question is not simply which model can perform the task. It is how the organisation will connect that model to real systems while retaining authority over what happens when the agent acts.
That is also why the different WSO2Con Africa conversations around APIs, identity, enterprise data, durable workflows, engineering agents and governance fit together. Each addresses a different part of the same architecture: how software that can reason and act is connected to systems that still need predictable permissions, controls and accountability.
The agent may make the decision, but the architecture determines what that decision can actually do.
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
