How Nacos 3.2 Evolves into an Enterprise AI Governance Platform

Introduction

With the release of Nacos 3.2, the project moves from a traditional service discovery and configuration center to an enterprise‑grade AI governance platform.

1. AI Registry

1.1 Why unify AI assets?

Enterprises face three major pain points when deploying AI: assets such as Prompt, Skill, Agent, and MCP are scattered across code repositories, documentation, and chat logs, making discovery difficult, changes cumbersome, and security hard to control.

Discovery difficulty : Teams cannot easily locate reusable Prompts or Skills, leading to duplicated effort.

Change difficulty : Modifying a Prompt requires redeploying the entire application.

Security difficulty : Skills can be maliciously injected and Prompts may leak sensitive data.

1.2 Unified model for four asset types

Nacos 3.2 treats AI assets as first‑class citizens, managing them with a common data model and lifecycle.

Registration flow

Developers submit resources via the Nacos console or SDK.

Nacos Server validates format and performs security scanning.

Validated resources are persisted (MySQL/PostgreSQL) and versioned.

Clients receive real‑time updates through long‑polling or gRPC streams.

Client pull mechanism

Clients use the same long‑polling approach as configuration management, sending a /v1/ai/listen request; the server returns immediately when a change occurs, enabling second‑level updates for high‑frequency assets like Prompts.

1.3 Dynamic Prompt hot‑update example

// Client code example
@NacosAiResource(dataId = "order-prompt", group = "AI_PROMPT", autoRefreshed = true)
private String orderPrompt;

public String buildOrderStatusQuery(String orderId) {
    // After the Prompt is edited in the Nacos console, orderPrompt updates automatically
    return String.format(orderPrompt, orderId);
}

The implementation relies on Nacos Listener and addListener to reload the Prompt when it changes.

2. MCP Registry

2.1 Pain points of traditional MCP conversion

Write JSON‑RPC handling logic for the MCP protocol.

Define JSON Schema for each tool’s input and output.

Deploy additional MCP Server instances.

These steps increase cost, extend development cycles, and are error‑prone.

2.2 Nacos MCP Registry + Higress AI gateway

Nacos adopts a “declarative conversion” approach. The core process is illustrated below:

Key design

MCP Registry : Stores each tool’s endpoint URL, input‑parameter mapping, and output‑format template.

Higress AI gateway : Built‑in MCP parser and HTTP adapter perform runtime protocol conversion.

Metadata dynamic sync : Nacos and Higress keep tool definitions in sync via a gRPC long connection, eliminating gateway restarts.

2.3 Subtlety of protocol conversion

The MCP protocol expects a ToolResult type containing a content field. Higress extracts the relevant fields from an HTTP response body and assembles a ToolResult according to a user‑defined template.

Example conversion:

// HTTP API response
{
  "code": 0,
  "data": {
    "status": "PAID",
    "amount": 99.9
  }
}

// Higress‑converted MCP ToolResult
{
  "content": [{
    "type": "text",
    "text": "订单状态：PAID，金额：99.9"
  }]
}

This design reduces integration effort for legacy APIs from weeks to hours.

3. Skill Security System

3.1 Security risks

A 2026 security report highlighted malicious Skills in public marketplaces that can steal environment variables or SSH keys, and private Skills are also vulnerable to poisoning.

3.2 Nacos three‑layer sandbox

Nacos 3.2 implements a comprehensive security guardrail covering the entire Skill lifecycle:

Static scanning : Built‑in rule engine scans for over ten risk categories (hard‑coded passwords, deserialization flaws, out‑of‑bounds file operations, etc.). Publication is blocked if any rule fails.

Signature lock : Skills are signed with HMAC at publish time; the Agent verifies the signature at runtime to prevent tampering.

Sandbox isolation : Skills run in isolated Docker containers or under Java SecurityManager, limiting access to authorized resources only.

Least‑privilege : Each Skill receives only the permissions it needs (e.g., a weather‑query Skill can call the weather API but cannot read the file system).

4. Nacos Copilot and Ecosystem Integration

4.1 Copilot intelligent agent architecture

The AI assistant embedded in the Nacos console, powered by a large model, automates two tedious tasks in AI engineering:

Prompt optimization suggestions : Analyzes user‑written Prompts, identifies structural issues (missing role definition, insufficient examples), and generates improved versions.

Agent code generation : Generates skeleton code for Spring AI Alibaba or AgentScope based on user intent.

4.2 A2A protocol and OpenClaw integration

Nacos 3.2 supports the A2A (Agent‑to‑Agent) protocol, enabling agents to automatically discover each other’s capabilities and collaborate on tasks.

Agents register their abilities (task types, required Skills) in Nacos; other agents can discover and delegate tasks dynamically.

Deep integration with OpenClaw allows it to search Skills in Nacos and install them on demand, achieving unified sharing and distribution of internal capabilities.

5. Summary and Outlook

Nacos 3.2 delivers four core capabilities that transform it from a micro‑service registry into an AI governance platform:

AI Registry : Unified metadata model and real‑time long‑polling push solve asset scattering and change difficulty.

MCP Registry : Declarative protocol conversion and automatic adaptation lower the cost of integrating legacy APIs.

Skill security system : Three‑layer sandbox, signature locking, and static scanning mitigate malicious Skill risks.

Ecosystem integration : A2A protocol and OpenClaw integration break agent silos and promote Skill reuse.

The overall value lies in turning AI capabilities from isolated “silver bullets” into governable, auditable, and reusable enterprise assets. Organizations embarking on AI transformation can start with Nacos 3.2 to build their AI infrastructure foundation.