China's National Technical Committee 260 on Cybersecurity released AI Safety Governance Framework 3.0 on 14 September 2026. The revision matters because it treats agentic AI as a distinct operational risk rather than only as another model capability. It organizes controls around agent identity, permissions, planning, tool use, memory, monitoring and human intervention.
The document is a nonbinding governance framework. It does not amend Chinese law, create a new certification or set a statutory compliance deadline. Its value is different: it gives developers, deployers and assurance teams a current reference for identifying how an agent can cross from generating content into taking actions in an environment.
What changed in version 3.0
The official release says the framework keeps the earlier structure of risk classification, technical response and comprehensive governance while updating the taxonomy for new AI developments. The attached bilingual document adds a dedicated agentic AI risk management framework and principles for trustworthy AI.
Independent analysis by Obsidian Regulatory Intelligence identifies four agent specific areas in the new taxonomy: identity and permission misuse, reasoning and planning failures, tool execution risk, and memory storage risk. It also notes coverage of embodied AI, autonomous cyberattack behavior and poisoning of agent memory or recommendation systems.
That is a meaningful shift in control design. A chatbot can usually be assessed around inputs, outputs and data handling. An agent also needs to be assessed around the authority it receives, the steps it creates, the tools it selects, the state it retains and the effects it produces.
A lifecycle view of agent risk
The strongest practical feature is the lifecycle view. Teams can use the framework to ask whether an agent has a unique identity, whether delegated permissions are limited to its task, and whether the user or organization can see what it is allowed to do. Those questions should be answered before deployment rather than after an incident.
Planning and tool execution need separate controls. A reasonable goal does not guarantee that every intermediate step is authorized. An agent may choose a destructive command, an excessive data query or an external message that goes beyond the user's intent. A runtime policy should therefore evaluate the proposed action, resource, requester and expected effect before execution.
Memory creates another boundary. Persistent state can carry incorrect instructions or sensitive data into later tasks. Teams need ownership, retention, isolation and deletion rules for agent memory, plus a way to trace which stored item influenced an action.
Monitoring and intervention complete the loop. Logs should connect task, identity, permission, tool call, result and change in the external system. A human stop path is useful, but it must be paired with machine speed containment when an agent can act faster than a reviewer can respond.
What the framework does not prove
The release does not demonstrate that any control is effective in a production deployment. It does not establish a common international standard or certify a product as safe. It also does not turn every suggested measure into an enforceable obligation.
Organizations operating in China still need to identify the laws, sector rules, contracts and technical standards that actually apply to their systems. Framework 3.0 can inform that work, but it cannot replace a legal applicability assessment or evidence from the deployed environment.
The framework should also not be read as proof that loss of control, memory poisoning or autonomous cyberattack behavior has occurred in a named system. These are risk categories and scenarios that require proportionate controls and testing.
A control checklist for deployers
Teams can translate the framework into a concise review:
- Inventory every agent, owner, model, connected tool, data source and external effect.
- Give each agent a distinct identity and the minimum delegated permissions for the active task.
- Separate trusted task instructions from retrieved content, memory and other untrusted inputs.
- Evaluate consequential tool calls before execution and record the policy decision.
- Isolate memory by user, tenant and purpose, with explicit retention and deletion rules.
- Monitor actions and outcomes, not only prompts and model responses.
- Provide bounded human intervention and an automated containment path.
- Reassess the agent when its model, tools, permissions or operating context changes.
Maetra's AI agent inventory guide helps teams establish the asset and capability baseline. The AI agent risk assessment template can turn the framework's broad categories into owned review questions and evidence.
Maetra analysis
Framework 3.0 is useful because it places governance at the action boundary. Agent risk is not determined only by which model is used. It emerges from the combination of identity, delegated authority, task, tools, memory and environment.
For assurance teams, the practical unit of evidence is therefore an action chain. The record should show what the agent was asked to do, which authority it used, what it proposed, which policy evaluated it, what executed and whether the intended effect occurred. That chain supports security review, incident reconstruction and compliance evidence without assuming that a general model assessment covers every deployment.
The framework is a reference, not a legal safe harbor. Its strongest use is as a prompt to find missing controls and stale evidence before agent autonomy expands.