How Nacos 3.2 Evolves into an Enterprise AI Governance Platform

Introduction

Nacos 3.2 extends the classic service‑discovery and configuration‑center role into an enterprise‑grade AI governance platform. It treats Prompts, Skills, Agents and MCP tools as first‑class assets that can be registered, versioned and managed centrally.

AI Registry

Why unify AI assets?

Discovery difficulty – assets are scattered across code repositories, documentation and chat logs, causing duplicate work.

Change difficulty – updating a Prompt or Skill traditionally requires redeploying the application.

Security difficulty – uncontrolled assets can be maliciously injected or leak sensitive information.

Unified data model and lifecycle

All four asset types share a common metadata schema and lifecycle managed by the Nacos server.

Registration flow :

Developers submit a resource via the Nacos console or SDK.

The server validates the format and runs a static security scan.

On success the resource is persisted in MySQL or PostgreSQL and a version number is generated.

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

Client pull principle – the AI Registry client issues a /v1/ai/listen request; the server returns immediately when the version changes, allowing incremental fetching of the new content. This yields second‑level update latency for high‑frequency assets such as Prompts.

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) {
    // When the Prompt is modified in the Nacos console, orderPrompt updates automatically without restart
    return String.format(orderPrompt, orderId);
}

The implementation relies on Nacos’s Listener mechanism and registers a change callback via addListener, reloading the Prompt when the underlying resource changes.

MCP Registry

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 lead to high cost, long development cycles and error‑prone implementations.

Declarative conversion with Nacos MCP Registry + Higress AI gateway

MCP Registry stores three elements for each tool: endpoint URL, input‑parameter mapping, and output‑format conversion template.

Higress AI gateway embeds an MCP protocol parser and an HTTP adapter, performing runtime protocol conversion.

Metadata dynamic sync – Nacos and Higress maintain a gRPC long‑connection that synchronizes tool additions, deletions and updates without restarting the gateway.

Protocol conversion details

The MCP protocol requires a ToolResult type containing a content field. Higress extracts key fields from the HTTP response body and assembles a ToolResult according to the configured 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 enables legacy APIs to become AI‑ready with near‑zero code changes, compressing integration time from weeks to hours.

Skill Security System

Security risks of Skills

A 2026 security report identified many malicious Skills in public marketplaces that can steal environment variables, SSH keys and other sensitive data. Private Skills also face injection threats.

Three‑layer sandbox

Static scanning – a built‑in rule engine scans for more than ten risk patterns (hard‑coded passwords, deserialization flaws, out‑of‑bounds file operations, etc.). Publication is blocked if scanning 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, with access limited to authorized resources.

Minimum permissions – 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).

Nacos Copilot and Ecosystem Integration

Copilot intelligent‑agent architecture

Prompt optimization suggestions – analyzes user‑written Prompts, highlights structural issues (missing role definition, insufficient examples) and auto‑generates improved versions.

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

A2A protocol and OpenClaw integration

Nacos 3.2 defines an A2A (Agent‑to‑Agent) protocol. An Agent registers its capabilities (supported task types, required Skills) in Nacos; other Agents discover these registrations and delegate tasks dynamically.

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

Summary

AI Registry – unified metadata model + long‑polling push; solves scattered assets and difficult change management.

MCP Registry – declarative protocol conversion + automatic adaptation; eliminates high cost of integrating legacy APIs.

Skill Security System – three‑layer sandbox, signature lock and static scanning; mitigates malicious Skill injection risk.

Ecosystem Integration – A2A protocol + OpenClaw adaptation; breaks agent silos and enables reusable Skills.

By treating AI assets as first‑class citizens, Nacos 3.2 provides a governed, auditable and reusable foundation for enterprise AI transformation.