China AI Safety Governance Framework 3.0 Guide

China's AI Safety Governance Framework 3.0 is the first version of the country's national AI safety framework to treat AI agents as a distinct risk class, and it sets out unusually concrete controls for agent identity, permissions, human approval and decommissioning. It was released on 14 September 2026 at the opening ceremony of China's National Cybersecurity Publicity Week by the National Cybersecurity Standardization Technical Committee (TC260), prepared under the guidance of the Cyberspace Administration of China (CAC). It is a technical guidance document rather than a binding regulation, but regulators can use it as a benchmark and it will shape national standards, procurement and contracts for AI systems operating in China. This guide explains the framework's structure, focuses on the agent risk management annex, and shows how to turn it into controls. It is for security, compliance and IAM teams at organisations building, buying or operating AI agents in or for the Chinese market.

Source note: framework content comes from the official bilingual PDF published by the CAC (the Chinese text is authoritative) and the CAC release page, checked 11 November 2026. Technique and control mappings are NHI Mgmt Group analysis. Confirm against the official text before relying on it.

Key takeaways

• Guidance, not law. The framework is a TC260 technical document issued under CAC guidance; it does not by itself create licensing, filing or liability obligations, but it signals how regulators will judge reasonable practice.
• Agents are now their own risk category. Section 2.2.1 names four agent risks: identity and permission misuse, reasoning and planning, invocation and execution, and memory storage.
• Appendix 2 is a full agent control set. It spans eight lifecycle stages from design to decommissioning and asks for unique agent identities, minimum task permissions, dynamic credentials revoked when a task ends, and default deny when approval fails.
• Humans approve the dangerous steps. High-risk operations go on a list and are handed to the user; deleting files, sending data or changing configuration need second confirmation with rollback, and approval records must be tamper-proof.
• Logs for at least six months. Section 5.3.6 sets runtime log retention for AI applications at no less than six months, and Appendix 2 lists file operations, commands, network connections, skill calls and payments as events to log.

What the framework is and how it evolved

The CAC announcement says 3.0 keeps the core logic of "风险分类、技术应对、综合治理" (risk classification, technical response, comprehensive governance) and the guiding concept of being people-centred. Drafters included the China Cyberspace Research Institute and the CAC Data and Technology Support Center with research institutes and companies. The official PDF is bilingual: the Chinese text is authoritative and an English translation follows it.

• Legal status: commentators, including the Zhong Lun law firm and a commentator on CCTV's News 1+1, describe it as non-binding guidance that regulators may use as a yardstick. Binding duties come from laws such as the amended Cybersecurity Law, the Generative AI Measures and the PIPL.
• Who it affects: developers, deployers and operators of AI systems in China, and foreign suppliers whose agents or models are used there.

Structure of the framework

The four agent risks in Section 2.2.1

The technique column is our mapping to MITRE ATT&CK and ATLAS, not part of the framework. Embodied AI (2.2.2) is a separate class covering environmental perception, physical execution, human-AI interaction and multi-agent coordination, where a single failing unit or malicious node can cascade through a swarm.

Appendix 2: the agent risk management framework

Appendix 2 walks the agent lifecycle through eight stages: design and R&D, installation and deployment, instruction input, reasoning and planning, invocation and execution, memory storage, result output and decommissioning. Across these it sets controls that group naturally as follows.

• Upfront risk prevention: confirm security requirements, grade the risk, set control strategies and confirm safety mechanisms; roll out in phases, expanding access and autonomy gradually.
• Identity: each agent gets a unique identifier and instances do not share identities; users, agents, tools and external services are authenticated.
• Permissions: only the minimum permissions for the current task; define which decisions belong to the user alone, which need user authorisation and which the agent may take autonomously.
• Credentials: standardised dynamic authorisation credentials managed in isolation; receivers verify the authorised scope and alert when it is exceeded; credentials are revoked immediately when a task ends or the agent is retired.
• Human approval: mandatory approval at key decision points, a maintained list of high-risk operations handed to the user, second confirmation and rollback for deleting files, sending data or changing system configuration, and tamper-proof, verifiable approval records.
• Default deny: if the approval system fails, the user does not respond or no rule applies, the operation is rejected (默认拒绝操作执行).
• Tools, plug-ins and skills: check version, description file, parameter definitions and metadata before calling a tool; never call known-malicious tools; remove unused, over-privileged or risky tools; prefer skills from reliable, security-tested sources; verify source, integrity and version of third-party components.
• Runtime limits: caps on execution steps, call frequency, duration and resource consumption, with pause, termination or escalation to a human when loops or goal drift appear.
• Memory: purpose-based memory content, retention and access scope, isolated across users and tasks; credentials and keys should in principle never be written to memory.
• Sandboxing: closed testing in an isolated sandbox before launch, and sandboxes or containers for code execution and tool calls at runtime, limiting system, file and network access.
• Logging: file operations, command execution, network connections, skill invocations and payment or transaction activity, with business and personal data desensitised and logs protected against tampering.
• Decommissioning: stop programs, services and processes and verify ports and connections; revoke third-party authorisations and cancel subscriptions; back up what must be kept; uninstall and delete residual files, plug-ins, skill configurations, accounts and credentials.

Where identity fits

Half of Appendix 2 is identity and access management for non-human identities. Unique per-instance identity, task-scoped permissions, dynamic credentials, scope checks at the receiver, keeping secrets out of memory and credential revocation at retirement are the same controls NHI programmes apply to service accounts and workloads, now written down for agents by a national standards body. The agent equivalent of an orphaned service account is an agent that was switched off but whose OAuth grants and API keys were never revoked, which is exactly what the decommissioning steps target.

Over-privileged agent tokens have already caused real damage: in the PocketOS database deletion a coding agent with a broad platform token wiped production, the scenario that second confirmation and default deny are meant to stop.

Implementing the framework: a phased approach

NHI Mgmt Group recommendation: this section and the decision guidance below are our own guidance, not requirements of the source document.

1. Scope: list AI applications and agents that run in China, process data collected there or are supplied to Chinese customers. Note any that support critical information infrastructure, where the framework points towards registration and filing.
2. Grade the risk: use the Appendix 1 factors (application scenario, intelligence level, scale) to place each system on the five-level scale, and record the reasoning for regulators and customers.
3. Close identity gaps first: give each agent instance its own identity, remove shared keys, scope permissions per task and add revocation at task end.
4. Build the high-risk operation list: agree with business owners which actions are user-only, which need authorisation and which are autonomous; configure default deny and second confirmation with rollback.
5. Vet tools and skills: put an allow list in front of tool and skill loading, checking source, version, metadata and integrity.
6. Test in a sandbox: run closed pre-launch tests and red-team exercises; after major changes to model, framework, tools, permissions or policy, re-run security assessment and regression tests.
7. Instrument and retain: log the Appendix 2 event types to tamper-evident storage, desensitise personal data, and retain runtime logs for at least six months.
8. Write it into contracts: change notice, regression testing and rollback, log access, suspension triggers and exit assistance, as practitioners such as Zhong Lun recommend.
9. Decommission properly: use a checklist covering processes, ports, third-party authorisations, subscriptions, data backup and credential deletion. Roll back a failed rollout by revoking the agent's credentials first, then restoring the prior version.

Decision guidance

The framework also says data collected and generated in China should be stored domestically, with cross-border transfers following national rules. See the China Cross-Border Data Transfers guide.

Detection and measurement

• Scope violations: alerts when a receiver sees a credential used outside its authorised scope, as Appendix 2 requires.
• Runtime limit hits: step, call-rate, duration and resource caps reached, which may indicate loops or goal drift.
• Default deny events: operations rejected because approval failed or no rule applied.
• Credentials in memory: secret patterns found in vector stores or conversation memory.

Metrics to report:

1. Percentage of agent instances with a unique identity and no shared credentials.
2. Percentage of agent credentials revoked automatically at task end.
3. Number of high-risk operation types on the approval list, and approvals bypassed in testing (target zero).
4. Log coverage of the five Appendix 2 event types, and retention meeting six months.
5. Percentage of retired agents with all authorisations and credentials confirmed revoked.

Common failure patterns

• Treating guidance as optional: because it is non-binding, teams ignore it, then find customers and regulators use it as the benchmark.
• Shared identities across agent instances: one API key for a fleet makes attribution and scope checks impossible.
• Approval paths that fail open: an approval service outage lets the agent continue, the opposite of default deny.
• Secrets in agent memory: tokens pasted into conversations or stored in long-term memory become retrievable by later sessions or other users.
• Unvetted skills and plug-ins: third-party components loaded without integrity checks, a supply chain route seen in the Salesloft Drift breach, where one integration's tokens opened hundreds of tenants.
• Retiring agents without revoking grants: processes stopped, but OAuth authorisations and subscriptions left live.

Framework mapping

This mapping is our interpretation for organisations running multiple frameworks; the Chinese framework does not reference NIST. For a comparable Western view see the Agentic AI Security Guide.

Practitioner checklist

• Confirm which AI systems and agents fall in scope for China and grade them using Appendix 1 factors.
• Issue a unique identity to every agent instance and remove shared keys.
• Scope permissions per task and revoke credentials automatically when the task ends.
• Publish a high-risk operation list with second confirmation, rollback and default deny.
• Gate tool, plug-in and skill loading on source, version and integrity checks.
• Keep credentials out of agent memory and isolate memory per user and task.
• Log file, command, network, skill and payment events to tamper-evident storage for at least six months.
• Run sandbox tests before launch and after every major change.
• Use a decommissioning checklist that revokes every authorisation and deletes credentials.

Standards and references

• Cyberspace Administration of China: Release of the AI Safety Governance Framework 3.0
• TC260: AI Safety Governance Framework 3.0 (bilingual PDF)
• Cyberspace Administration of China: AI Safety Governance Framework 2.0
• Cyberspace Administration of China: AI Safety Governance Framework 1.0
• Zhong Lun: analysis of the AI Safety Governance Framework 3.0 agent provisions
• Cyberspace Administration of China: CCTV News 1+1 discussion of Framework 3.0
• MITRE: ATLAS

Related NHI Mgmt Group resources: China Generative AI Measures and AI Labelling Rules Guide · China Cybersecurity Law Guide · Agent Governance and Risk Guide · Agentic AI Compliance Guide. This guide summarises China's AI Safety Governance Framework 3.0 and is not legal advice.