Estimated reading time: 15 minutes
AI agents are starting to change category inside the enterprise. While generative assistants receive a request and return an answer, agents can access systems, query data, call tools, and execute actions that used to depend on people or on deterministic flows.
That shift expands what AI can do, but it also changes the architecture required to operate it safely. When an agent moves from recommending an action to executing it, controlling the user who started the process stops being enough. The organization needs to know which agent is acting, on whose behalf, with which permissions, over which systems, and under which limits.
This is one of the central ideas in the Agentic Enterprise concept presented by WSO2: APIs, integration, identity, and observability remain fundamental, but they need to be extended so agents can operate as identifiable, governable participants in the enterprise architecture.
For whoever decides architecture and technology investment, the question that defines the project comes before adoption:
Which controls need to exist before these agents receive the autonomy to act?
Why AI agents change enterprise architecture
Corporate architectures were built over decades around two relatively predictable categories.
On one side, people authenticated by identity systems. On the other, applications and services running integrations, APIs, and previously defined processes.
Figure 1: Non-agentic enterprise architecture on WSO2.com
Agents introduce a third category. In 2025, WSO2 framed its modernization vision around the concept of Platformless Modernization. In 2026, that architecture came to incorporate infrastructure built specifically for agents, including identity, lifecycle, and governance.
They are software, but they can receive goals from people, decide which tools to use during execution, work on behalf of different users, and adjust their behavior based on the context they receive.
That makes it insufficient to treat an agent as just another service account, or to reuse the credentials of whoever started the task.
The architecture needs to be able to distinguish:
- the user’s identity;
- the agent’s identity;
- the authority that was delegated;
- the scope of that authorization;
- the resources accessed;
- the other agents and tools invoked during execution;
- and the sequence of decisions that led to the final action.
In the architecture WSO2 proposes for the agentic enterprise, this problem appears as a combination of controlled ingress and egress paths, identity and policy, tool connectivity, system integration, observability, evaluations, and guardrails. The important change lies in creating new control points for workloads that can now decide and act autonomously, while preserving the infrastructure that already works.
Figure 2: WSO2 agentic fabric on WSO2.com
Picture a bank’s service agent authorized to check a customer’s status and, under certain conditions, request a registration change.
When that call reaches the API, knowing only that a valid token exists settles very little.
The system needs to be able to answer:
- Which agent made the request?
- On behalf of which customer or employee?
- What authority was delegated to it?
- Does that authorization cover reading data, or changing it as well?
- For how long does it remain valid?
- Was another agent invoked during the process?
This distinction matters because identity and authorization answer different problems.
Recognizing the agent proves who is executing the action. Delegation establishes where the authority to execute it came from. Scope determines how far that authority reaches.
WSO2 now treats agents as first-class identities in its identity layer. Agent ID makes it possible to register, authenticate, authorize, and audit agents separately, covering scenarios where they act autonomously and situations where they execute tasks on behalf of a user.
That separation has an important consequence for regulated environments: the trail moves beyond recording that a given credential accessed a system, and becomes able to preserve the relationship between the agent that executed the action and the authority that originated it.
Delegating authority without handing over the user’s credential
One of the risks of adapting traditional authentication models to agents is having them operate with borrowed credentials or excessively broad permissions.
In that model, the system can recognize the account, but it loses part of the information needed to distinguish the executor of the action from whoever authorized it.
On-Behalf-Of delegation flows address this by keeping the agent identified during execution and binding to it the authority granted by the user. WSO2’s current documentation demonstrates exactly these two scenarios: agents operating with their own identity, and agents receiving authorization to act on behalf of another identity.
The principle matters more than any specific implementation.
In any architecture with agents, the organization should be able to demonstrate:
Who initiated the delegation, which agent received the authority, which permissions were granted, which resources were accessed, and which action was executed.
The longer the chain between humans, agents, subagents, and tools, the more important it becomes to preserve that relationship end to end.
Agent Manager: lifecycle governance for AI agents
Identity solves part of the problem. The full operational cycle calls for another layer.
As different areas start building agents with distinct frameworks, models, and runtimes, another question emerges: who knows how many agents exist, where they are running, and which resources they can reach?
This is the layer that products like WSO2 Agent Manager aim to address.
The platform works as a control plane to register, run, observe, evaluate, protect, and govern agents across their lifecycle, including agents built or executed on different frameworks and environments.
In practice, this adds controls that start to become necessary when isolated experiments reach production:
- an inventory of existing agents;
- ownership and lifecycle management;
- a distinct identity for each agent;
- access policies;
- observability of interactions with models and tools;
- continuous behavior evaluations;
- guardrails;
- consumption and cost control;
- revocation and controlled retirement of agents.
The analogy with API Management helps, but it has a limit. An API Manager primarily governs the exposure and consumption of interfaces. The agent adds another dimension: it needs to be treated as a governed component itself, because it can choose which interfaces to use and in what sequence.
That is why the discussion moves beyond “is this API protected?” and starts to include “should this agent have permission to call it in this context?”
Integration and MCP: systems exposed as agent tools
The second change happens in the integration layer.
For years, integrating meant connecting applications, data, events, and APIs inside relatively known flows. With agents, those same capabilities start being consumed dynamically as tools.
The Model Context Protocol (MCP) emerged as one of the standards for creating a common interface between agents and external resources. In this model, corporate systems can expose capabilities that an agent discovers and uses while executing a task.
WSO2 Integrator currently combines this model with more than 600 connectors and MCP server support, letting agents participate in flows alongside traditional applications and services.
The number of connectors matters less than the architectural change behind it.
Integration moves beyond moving data between systems and starts defining which of the company’s capabilities can be consumed by agents.
That raises the strategic value of the integration layer, and it raises its responsibility as well.
Exposing an internal function as a tool reachable over MCP involves more than connectivity. The decision covers:
- contract;
- identity;
- authorization;
- context;
- data classification;
- usage limits;
- observability;
- consequences of execution.
An agent is as useful as the actions it can execute. For the same reason, its risk grows as its reach expands.
Egress governance: the new perimeter is at the exit
Much of traditional enterprise security was built to control who enters a system. Agents make it equally important to control where they can go out.
During an execution, an agent can send context to an external model, query an API, access a database, call an MCP server, or invoke another agent.
Each of those interactions can move data, carry instructions, or produce effects outside the system that started the flow.
That is why governing agents requires watching egress with the same rigor applied to ingress: which agent is making the call, to which destination, on whose behalf, with which data, and under which policy.
WSO2 itself has been treating egress governance as a component of the agentic architecture, advocating scoped credentials, enforcement during the call, and preservation of the delegation chain in the audit trail.
For sectors such as financial services and insurance, this distinction is particularly relevant. A policy applied after execution can explain an incident. A policy applied in the execution path can prevent it from happening.
Guardrails for AI agents: from model response to action
The same reasoning applies to AI governance.
Filtering an inappropriate LLM response is necessary, but insufficient when the model is connected to tools capable of producing real effects.
The control layer also needs to consider:
- exposure of personal or confidential information;
- prompt manipulation;
- tool access;
- authorized destinations;
- execution scopes;
- model consumption;
- call volume;
- costs;
- actions that require additional approval.
At WSO2Con 2026, WSO2 presented a Policy Hub with more than 40 policies and guardrails for AI traffic, including mechanisms related to PII, prompt security, and other checks applied to model interactions.
The value of this layer lies in its ability to convert rules that once depended on each application into policies applied consistently along the path between agents, models, and tools. The absolute number of controls matters less.
What changes for a company that already runs APIs, IAM, and integration
Adopting agents does not necessarily mean rebuilding the enterprise architecture.
Institutions already operating API Management, corporate integration, IAM, observability, and security controls hold an important part of the required foundation.
The question is whether those components can answer the new characteristics of the workload.
For example:
- Identity: does the agent have its own identity, or does it use a generic account?
- Delegation: is it possible to prove where the authority used in each action came from?
- Authorization: are permissions specific to the agent, user, context, and tool?
- Integration: do the capabilities exposed to agents have adequate contracts and controls?
- Egress: do calls to external models, APIs, and tools pass through enforcement?
- Observability: is it possible to reconstruct an execution involving model, agent, API, integration, and system of record?
- Governance: is there an inventory of agents in production, a defined owner, and a process to revoke access or retire an agent?
These questions are more useful than opening the discussion by choosing a new platform.
In some environments, existing capabilities can be extended. In others, a dedicated management and identity layer for agents reduces the number of controls that would have to be built internally.
In the WSO2 ecosystem, Agent Manager and Agent ID now occupy exactly that function: one controls the operational cycle and governance of agents; the other handles their identity, authentication, authorization, delegation, and audit. WSO2’s current documentation also keeps Agent ID inside the Identity Platform, alongside Identity Server and Security Token Service.
ThunderID is part of this technological evolution, but it should be understood separately. WSO2 introduced it in 2026 as a new open source IAM runtime, written in Go and prepared for scenarios such as agent identity, decentralized identity, and post-quantum cryptography. That said, organizations do not need to automatically replace Identity Server to adopt agent identity.
The data and operations foundation that sustains these workloads at scale is the subject of How to Scale AI Agents in Banking.
What to decide now before agents reach production
Few organizations need to deploy a complete architecture for thousands of agents immediately.
But some decisions become progressively more expensive to correct after agents reach production.
- The first is identity. Agents should never be born sharing generic technical accounts if the company will later need to attribute actions individually.
- The second is delegation. Authority transferred between user, agent, subagent, and tool needs to remain traceable.
- The third is scope. An agent should receive only the access required to execute the task. Inheriting the full capability of the person or system that started it expands risk without need.
- The fourth is observability. Logs need to follow the execution end to end, crossing the boundary of every API along the way.
- The fifth is integration governance. Exposing APIs, systems, and data as tools available to agents expands the operational surface and requires controls before exposure.
- The sixth is egress. The company needs to know which data and instructions are leaving its perimeter during the calls agents make.
The choice between WSO2, hyperscalers, or other platforms comes after these definitions.
A durable architecture starts by determining which autonomy the organization intends to grant and which evidence it needs to keep about every executed decision. The question of which tool manages agents comes next.
Frequently asked questions
API governance defines contracts, authentication, authorization, traffic policies, and consumption conditions for an interface. Agent governance adds controls over the actor using those interfaces: identity, ownership, delegation, authorized tools, behavior, lifecycle, and traceability of actions.
The two layers are complementary. Well-governed agents still need to consume governed APIs.
Not necessarily. The starting point should be assessing whether the current infrastructure can recognize agents separately, issue adequate credentials, apply granular authorization, preserve delegation, and produce a sufficient audit trail. The need for extension or replacement depends on that analysis.
In the WSO2 ecosystem, for example, Agent ID currently appears integrated into the Identity Platform itself and into Identity Server.
Service accounts can authenticate a call, but they tend to fall short when multiple agents, users, and delegation chains share the same technical identity. In that scenario, proving exactly which agent executed an action and where its authority came from becomes harder.
No. MCP standardizes how agents find and use tools, but it does not eliminate the need for identity, authorization, policies, data classification, observability, and governance of the exposed capabilities. Precisely because MCP makes tools easier to reach, those controls become more important.
With the use case and the decision the agent will execute.
Before expanding its autonomy, map who authorizes the action, which systems will be accessed, which data crosses the flow, which permissions are required, which actions are reversible, and which evidence needs to remain available after execution.
Before scaling AI agents, prove who is acting
An agent’s usefulness grows with the number of systems it can reach and the actions it can execute. Its risk grows along the same two dimensions.
That is why the Agentic Enterprise discussion should start with the architecture’s ability to identify, limit, observe, and interrupt each agent the moment it stops recommending and starts acting. The number of agents the organization intends to build comes later.
For banks and other critical operations, there is an even more objective question: if an agent executes a relevant action today over a customer, a dataset, or a system, can the organization prove which agent acted, on whose behalf, with which authorization, and inside which policy?
If that chain still can’t be demonstrated end to end, the next decision is to strengthen the foundation that will have to sustain that autonomy, before expanding it.
Your challenge deserves a strategic conversation
TreeID’s Integration & APIs practice operates exactly at this decision layer: assessing identity, integrations, APIs, observability, and existing controls to determine what can be reused, what needs to evolve, and which components make sense to put agents into production without autonomy turning into loss of control.