WSO2 announced the general availability of WSO2 Agent Manager on 15 September 2026. The open source control plane is designed to register, run, govern, observe and evaluate AI agents across different frameworks and deployment environments. It moves the product beyond the beta announced earlier in 2026 and makes both self-hosted and hosted deployment paths available.
The release is material for enterprise teams because it brings several agent controls into one operating layer: a central inventory, distinct agent identity, delegated access rules, guardrails for models and tools, evaluation, observability and a sandboxed runtime. WSO2 also positions the product as framework independent, including agents built with LangChain, CrewAI, AWS Strands and Microsoft Agent Framework.
What is available now
The primary release states that Agent Manager is generally available and fully open source. WSO2's current product page provides a trial route and describes self-hosted and software as a service options. That supports the availability claim, although performance, control effectiveness and enterprise outcomes remain vendor assertions rather than independently tested results.
The product page describes a central inventory for agents and a distinct identity for each agent. Delegation policies define what an agent may access and on whose behalf it acts. This is important where agents otherwise borrow a human account or a shared service credential, leaving investigators unable to distinguish one automated actor from another.
WSO2 also describes more than 40 built-in guardrails applied at organization, agent, MCP and model levels. Examples include personal data masking, URL checks, content validation and semantic prompt validation. The platform includes monitoring and evaluation, plus a runtime intended to isolate execution.
Why an agent control plane is different
Traditional application management usually assumes stable services, predictable calls and long-lived identities. Agents can select tools, create multi-step plans and change behavior as context changes. Governance therefore needs to connect the agent's declared purpose to its actual actions.
A useful control plane should answer six questions. Which agents exist? Who owns them? What can each one access? Which task and user delegated the authority? What actions did the agent attempt? What changed in the external system?
Inventory without action evidence leaves a gap. Guardrails without distinct identity can block a pattern but fail to show which agent was responsible. Observability without enforcement can explain an incident after the effect but cannot stop the action. The value of an integrated platform depends on whether these layers share the same identifiers and policy context.
Boundaries teams still need to test
General availability does not prove that every framework, tool or protocol receives equivalent coverage. Teams should verify how Agent Manager handles agents that run outside its sandbox, custom MCP servers, asynchronous jobs, long-lived memory and direct API credentials.
They should also test failure behavior. If the policy service, identity provider or evaluation component is unavailable, does the agent stop, continue with reduced capability or bypass the check? The safe answer may differ by action, but it should be explicit and testable.
Guardrail counts should not be treated as outcome metrics. A policy that detects sensitive data or an unsafe instruction still needs a defined response, evidence of the decision and confirmation that the blocked or allowed action produced the intended result. Vendor statements about sovereignty, control and production readiness require validation against the customer's architecture and threat model.
A practical adoption sequence
Start by importing or recording a small set of real agents. Assign a responsible owner, business purpose, model, tools, data access and deployment location to each one. Compare the inventory with repositories, cloud services and endpoint evidence to find missing agents.
Next, issue a distinct identity and replace shared credentials where possible. Define delegation rules around the user, task, resource and action type. A coding agent may be allowed to read a repository while changes to protected branches require a separate policy decision.
Then apply guardrails and evaluations to the riskiest action path. Test both expected work and failure cases, including prompt injection, excessive data access, unavailable dependencies and a tool result that differs from what the agent expected.
Finally, connect logs across identity, prompt, policy, tool call and effect. The Maetra agent inventory guide provides a baseline for agents and connected capabilities. The AI audit log guide helps define the evidence needed after a consequential action.
Maetra analysis
WSO2's release reflects a wider shift from managing models to managing operational actors. An enterprise may use several models and frameworks, but the governance question is consistent: which identity was authorized to take which action for which task?
The strongest deployment pattern separates inventory, authorization, security inspection and outcome verification while preserving one evidence chain. A control plane can provide the shared context, but teams still need policies that reflect business consequences and independent tests that show those policies hold under failure.
Agent Manager's general availability creates a concrete option for organizations seeking a self-hosted or hosted control layer. It should be evaluated as infrastructure, not treated as automatic proof that the agents running through it are safe, compliant or aligned.