When multiple teams within an enterprise use AI agents, they often face governance challenges such as poor permission isolation, inefficient collaboration, and uncontrollable model invocation costs. Built on the core capabilities of AgentRun, the Open Platform provides a three-layer multi-tenancy permission system, Token quota management, and enterprise single sign-on (SSO) integration to help enterprises centrally manage and securely run their agents.
A major upgrade is planned for the AgentRun Open Platform (FunAgent). We recommend that new users do not activate the service. Existing users can continue to use it, and an upgrade plan will be provided later.
Product overview
The AgentRun Open Platform (codename: FunAgent) builds an AI agent operations and management hub for enterprises on top of the underlying capabilities of AgentRun. The platform allows you to quickly create, configure, and manage AI agent instances, and interact with them through channels such as DingTalk, Lark, WeCom, and personal WeChat.
The platform includes built-in core capabilities such as AgentRuntime, model management, tools and skills, a knowledge base, memory, and prompt management. It also offers enterprise-grade governance features, including user group management, user management, workspace collaboration, enterprise single sign-on (SSO), and Token quota control.
The Open Platform is available in the China (Hong Kong) and Singapore regions.
Challenges in enterprise agent adoption
Enterprises typically encounter the following three challenges when adopting AI agents. Management and operations teams need to set resource policies, approve permission requests, and monitor overall usage. Without a dedicated platform, they must rely on manual processes or operate directly in the cloud console:
|
Problem category |
Description |
|
Lack of isolation and permissions |
When multiple teams share a single AgentRun instance, prompts, knowledge bases, and invocation logs are visible to all users, preventing workspace isolation. Different roles have the same permissions, making it impossible to enforce access control for sensitive APIs and data. |
|
Absence of collaboration workflows |
Collaboration between infrastructure teams, administrators, and application developers relies on manual processes. Permission changes can take days to process through ticketing systems. When an employee leaves, their permissions are not automatically revoked, and there are no traceable records for compliance audits. |
|
Uncontrolled costs and security risks |
Model invocation costs cannot be controlled with per-team or per-user quotas, resulting in unexpected Token consumption discovered only at month-end. API keys are managed by individual users, which creates a risk of leaks. |
Limitations of RAM and resource groups
Some enterprises try to manage agent permissions by using Alibaba Cloud Resource Access Management (RAM) and resource groups, but encounter the following issues:
-
Mismatched abstraction: RAM operates at the API operation level, but enterprises need permissions defined in business terms (for example, "The marketing department can use all approved marketing agents"). Expressing these needs with RAM requires extensive manual policy assembly and does not support a request-and-approval workflow.
-
Overly coarse-grained isolation: A resource group is suitable for department-level isolation but creates excessive management overhead for lighter-weight scenarios like temporary project teams or personal sandboxes. Furthermore, it does not integrate with existing enterprise organizational structures, such as LDAP or DingTalk.
-
Static permission assignments: RAM permission bindings are static. They do not support dynamic scenarios, such as employees applying to join a workspace, administrators approving requests, or temporary permissions expiring automatically.
-
High barrier to self-service: Business users do not understand concepts like
RAM,policy, orrole. Every permission change requires submitting a ticket to the IT department.
Core capabilities
Three-layer multi-tenancy permission system
The Open Platform's multi-tenancy permission system consists of three layers, enabling hierarchical access control from the platform level down to the team and individual levels.
|
Layer |
Unit |
Description |
|
First Layer |
user group |
The core unit for bulk permission management and resource isolation. Every user must belong to a user group. Group-level quotas control resource limits, such as the number of workspaces, AgentRuntime instances, and models. An administrator configures group-level permissions once, and all members of the group automatically inherit them. Different teams or departments are assigned to different user groups, each with its own independent workspaces and quotas, ensuring they do not interfere with one another. User groups containing users cannot be deleted, which prevents accidental data loss and inconsistency. |
|
Second Layer |
user management |
Centrally manage the status and permissions of all developer users. The platform supports user-level custom configurations, such as additional workspaces and custom quotas. It also allows you to disable accounts for abnormal activity or when employees leave, preventing them from accessing platform resources. Administrators can control whether users are allowed to self-register and can integrate with corporate identity systems via SSO. |
|
Third Layer |
workspace |
An independent work unit for team collaboration. Within a workspace, three roles (Owner, Admin, and Member) provide fine-grained access control. Each workspace's resources are isolated from others. Quota priority: workspace quota > the owner's user quota > user group quota > system default. |
Roles and entry points
The Open Platform provides separate entry points for different roles.
|
Role |
Entry point |
Description |
|
Infrastructure team |
Create and maintain Open Platform instances and configure underlying resources such as Virtual Private Cloud (VPC), ApsaraDB RDS, Object Storage Service (OSS), and Network Load Balancer (NLB). |
|
|
Administrators and operations staff |
Admin backend ( |
Manage global configurations (models, storage, quotas, skills), permission management, template management, and instance monitoring. |
|
Application developers |
Developer console ( |
Create and use agents, engage in conversational interactions, and manage files, knowledge bases, prompts, and tools. |
Capability matrix
The Open Platform provides end-to-end capabilities, from agent creation to execution.
|
Capability |
Description |
|
AgentRuntime |
Create two types of agents: conversational and workflow-orchestrated. Each agent has an independent runtime environment and observability data. |
|
Tools and skills |
Register Function Call, MCP protocol, and composite tools. Administrators centrally configure platform-level skills, which users can then install and use as needed. |
|
Knowledge base |
Supports data ingestion from multiple sources to enable intelligent Q&A (RAG) based on private data. |
|
Memory |
Gives agents long-term and short-term memory. |
|
Prompt management |
Supports prompt creation, editing, versioning, debugging, and A/B testing. |
|
Template management |
Save configured agents as templates to quickly create new ones. |
|
Workspaces and permissions |
Isolates resources using multiple workspaces and enforces fine-grained permission control at the user group and user levels. |
|
Single sign-on (SSO) |
Supports OIDC and SAML protocols to connect with enterprise Identity Providers (IdPs) for unified authentication. |
|
Token quota |
Combines system default quotas with user-level custom quotas for fine-grained control over large model invocation costs. |
Differentiating capabilities
|
Capability |
Description |
|
Persistent workspaces |
Mounts Object Storage Service (OSS) for persistent storage, ensuring all files and configurations persist across instance restarts. |
|
Multi-model, multi-provider support |
Provides out-of-the-box support for Alibaba Cloud Qwen, Zhipu GLM, Moonshot AI Kimi, and DeepSeek, as well as custom model service endpoints (OpenAI-compatible). |
|
Security and isolation |
Users do not manage API keys. An administrator configures them centrally, and the model API keys cannot be directly accessed from the agent environment. |
|
Flexible cost control |
Features a cost-saving mode (pay-as-you-go instances where resources are released when the page is closed), monthly Token quotas (combining system defaults with user-level customizations), and multiple instance specifications (six tiers from 1c1g to 4c8g). |
|
Comprehensive file interaction |
Automatically prompts for downloads when files are mentioned in a conversation. Users can browse, upload, download, edit, and create files in the user interface. |
|
Rich skills ecosystem |
Includes built-in skills for web browsing, search, self-improvement, and Virtual Private Cloud (VPC) access. Supports custom skill uploads and MCP tools. |
|
Multi-channel IM support |
Supports DingTalk, Lark, WeCom, and personal WeChat. All channels except DingTalk support pairing via QR code scan. |
|
Observability and operations |
Provides an out-of-the-box observability dashboard based on OpenTelemetry and includes a built-in Alibaba Cloud CLI. |
|
Special topics |
Offers enterprise-ready open-source solutions by customizing and hosting projects like OpenClaw (FunClaw) and Hermes (FunHermes). |
Platform value
The Open Platform enables enterprises to transition from "agents that work" to "agents that are governed" by providing the following key capabilities:
-
Isolation: A three-layer multi-tenancy system (user group, user, workspace) allows multiple teams to work securely in parallel.
-
Permissions: Business-semantic permission definitions with hierarchical control from the platform level down to the individual level.
-
Workflows: Request-and-approval processes, template reuse, and quota management for compliance and auditability.
-
Role-based division of labor: Infrastructure teams manage infrastructure, administrators manage governance, and application developers manage business logic.
-
Cost control: A combination of a cost-saving mode, Token quotas, and multiple instance specifications enables fine-grained control over model invocation costs.
-
Security: Centralized API key management, single sign-on (SSO), and secure handling of environment variables.