How Nacos 3.2 Evolves into an Enterprise AI Governance Platform

Introduction

Version 3.2 of Nacos marks a quiet but significant shift: the product is no longer just a service discovery and configuration center, but an enterprise‑grade AI asset "unified governance platform" that treats AI resources as first‑class citizens.

1. AI Registry

1.1 Why unify AI assets?

In practice, prompts, skills, agents, and MCP definitions are scattered across code repositories, documentation, and chat logs, leading to three pain points:

Discovery difficulty : teams cannot easily locate reusable prompts or skills, causing duplicated effort.

Change difficulty : updating a prompt requires redeploying the entire application.

Security difficulty : malicious skill injection or prompt leakage of sensitive data.

1.2 Unified model for four asset types

Nacos 3.2 treats AI assets on par with microservices, managing them with a common data model and lifecycle.

Registration flow :

Developers submit resources via the Nacos console or SDK.

The Nacos server validates format and runs security scans.

Approved resources are persisted in MySQL or PostgreSQL and a version number is generated.

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

Client pull mechanism : similar to configuration long‑polling, the AI client calls /v1/ai/listen; when a resource changes, the server immediately returns the new version, allowing second‑level updates for high‑frequency assets such as prompts.

1.3 Dynamic Prompt hot‑update example

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

public String buildOrderStatusQuery(String orderId) {
    // When the prompt is edited in the Nacos console, orderPrompt updates automatically without restart
    return String.format(orderPrompt, orderId);
}

The implementation relies on Nacos' Listener mechanism and the addListener registration to reload the prompt on change.

2. MCP Registry

2.1 Pain points of traditional MCP migration

Converting legacy HTTP APIs to MCP servers typically requires writing JSON‑RPC handling logic, defining JSON Schemas for each tool, and deploying additional MCP server instances—resulting in high cost, long cycles, and error‑prone work.

2.2 Declarative conversion with Higress AI gateway

Nacos solves this with a "declarative conversion" approach:

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

Higress AI gateway : embeds an MCP protocol parser and HTTP adapter to perform runtime protocol translation.

Dynamic metadata 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 object containing a content field. Higress extracts the relevant fields from the original HTTP response body and assembles a ToolResult according to a configured template.

// 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 the time to expose existing APIs to AI from weeks to hours.

3. Skill Security System

3.1 Security risks of Skills

Early 2026 security reports revealed many malicious Skills in public marketplaces that could steal environment variables or SSH keys, and private Skills also face poisoning threats.

3.2 Three‑layer sandbox in Nacos 3.2

Static scanning : built‑in rule engine scans for over ten risk categories (hard‑coded passwords, deserialization flaws, out‑of‑bounds file operations); failures block the publishing pipeline.

Signature lock : Skills are signed with HMAC at publish time; agents verify 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’s intelligent agent architecture

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

Prompt optimization : analyses user‑written prompts, highlights structural issues (missing role definition, insufficient examples), and generates improved versions.

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

4.2 A2A protocol and OpenClaw integration

Nacos 3.2 adds support for the A2A (Agent‑to‑Agent) protocol, allowing agents to register their capabilities (task types they can handle, required Skills) and enabling other agents to discover and delegate tasks automatically.

Deep integration with OpenClaw lets the platform search for Skills in Nacos and install them on demand, achieving unified sharing and distribution of internal Skills.

5. Summary of Core Capabilities

AI Registry : unified metadata model + long‑polling push solves asset scattering and change difficulty.

MCP Registry : declarative protocol conversion + automatic adaptation lowers the cost of connecting legacy APIs to AI.

Skill Security System : three‑layer sandbox, signature lock, and static scanning mitigate malicious Skill risks.

Ecosystem Integration : A2A protocol and OpenClaw adapters break agent silos and simplify Skill reuse.

Overall, Nacos 3.2 demonstrates a clear evolution: from managing microservice instances to governing enterprise AI assets, turning AI capabilities from scattered "silver bullets" into auditable, reusable core assets.