China AI Safety Governance Framework 3.0: An Implementation Map

On September 14, 2026, China's National Technical Committee 260 on Cybersecurity of SAC published the AI Safety Governance Framework 3.0 under the guidance of the Cyberspace Administration of China. The framework keeps a three-part structure. It classifies risk and applies technical countermeasures. Governance measures follow. This edition adds detailed treatment of agent identity and tool use. It also covers memory and autonomous cyber activity, along with embodied systems and loss-of-control scenarios.

The practical work starts several layers below those headings. I want to translate the third edition into controls an enterprise team can assign and test. Those controls must also be auditable without pretending that one gateway covers an entire AI system.

TL;DR

• China's third AI Safety Governance Framework groups inherent risks with application risks. It also identifies derivative risks.
• Enterprise implementation needs agent identity and least privilege, prompt-injection inspection and tool-call controls, runtime monitoring and incident procedures, plus retained logs.
• Authenticated HTTP traffic to an LLM supports inline identity and data policy, plus route and response policy with per-decision records.
• Training data and model weights require separate owners and evidence. So do local execution, embodied systems and physical safety.

The third edition uses a risk-to-control structure

The official TC260 release says the 2026 framework continues the core logic used in the 2024 and 2025 editions: risk classification and technical response, supported by comprehensive governance. The 130-page bilingual PDF then divides AI safety risk into three classes.

Inherent risks arise inside models and algorithms, as well as data and computing infrastructure. Runtime environments are also included. Application risks appear when AI systems interact with agents and tools. The same class covers people and networks, plus personal information and critical services. Derivative risks extend into employment and culture. They also cover the environment and ethics, plus the possibility of systems moving beyond human control.

That taxonomy is broad by design. An implementation team should resist turning it into one undifferentiated control list. My view is blunt: a control register with one owner named "AI team" is an abandoned spreadsheet with a polite label. Each risk needs an enforcement point and evidence source. It also needs an accountable operator.

Agent controls are a major change in the third edition

The third edition gives agentic systems their own risk treatment. It identifies identity and permission abuse, along with planning errors and compromised tool execution. Polluted or stolen memory is another risk. Its agent safeguards call for unique identities and corresponding credentials. They also require least privilege and layered detection points, mandatory human approval and tool integrity checks, abnormal-call blocking and runtime monitoring, plus auditable records.

Those measures belong at different points. The identity provider establishes the human or workload principal. The agent runtime binds that principal to a task and delegated scope. A tool gateway checks the proposed action against the current authority. The LLM request path evaluates model destination and prompt content. It also evaluates data classification and route policy.

The AI agent kill switch guide covers the shutdown sequence needed when an agent continues work across queues and tools, including delegated sessions. The TC260 framework adds the governance reason for documenting that sequence before deployment.

Deployment guidance reaches the API boundary

The framework's deployment guidance calls for risk grading based on the use case and intelligence level, with scale assessed separately. It also asks operators to verify the source and integrity of models and frameworks. The same verification applies to third-party libraries and tools, plus plugins, before use.

At the interface layer, the guidance is specific. Human-machine interfaces and APIs need identification plus permission controls. Operators should set minimum access rights and tie rate limits to business context. They should also restrict high-risk operations for general users and retain a way to suspend or block malicious accounts. A separate deployment item adds security guardrails for unlawful content and prompt injection, including checks on external content used by retrieval systems.

For an authenticated HTTPS call to an LLM, these requirements translate into a visible request envelope. It should identify the principal and role, application and purpose, destination model and data classification, plus the workflow identifier and current policy version. Missing identity or an unapproved destination should produce a deny decision before the provider receives the prompt.

Runtime evidence needs six months of logs

The operation and management guidance asks for named responsibility and human review in important scenarios. It also requires minimum permissions and real-time risk monitoring, incident plans and emergency exercises, change assessment and rollback capability, plus user notification after major security events.

The logging requirement is concrete. The framework says AI application operation logs should cover system and user behavior, remain available for at least six months, and receive periodic audits. A useful runtime record therefore needs more than a conversation transcript. For governed LLM traffic, record the authenticated principal and calling application, model route and classification result, policy version and decision, plus the timestamp and provider correlation identifier. Protect sensitive payloads under a separate evidence policy.

The AI governance framework guide separates policy and enforcement from the record layer. The TC260 document supplies a current national risk taxonomy that can sit above those operating layers.

Framework guidance and binding measures have different jobs

The 2026 framework is a risk and governance reference published by TC260. Teams providing generative AI services to the public in China also need to read the separate Interim Measures for the Management of Generative AI Services, issued as Order No. 15 by the Cyberspace Administration of China and six other national authorities. The measures took effect on August 15, 2023.

The distinction affects evidence. The framework helps a security team classify risks and choose controls across development and deployment, plus operation and use. Order No. 15 supplies binding service-management obligations within its defined scope. A control owner should map each legal obligation to the relevant policy and technical check. The map should also identify the retained record rather than cite the framework as a substitute for legal analysis.

The 2026 AI governance deadlines guide provides a wider calendar for teams operating across jurisdictions. China's framework belongs in that register with its version and publication date, source document and assigned review owner.

The HTTP boundary covers only routed model traffic

An authenticated LLM HTTP proxy can enforce part of the framework. It can inspect requests and responses sent through managed routes, then apply identity and role policy. It can classify prompt data and restrict model destinations. It can also detect specified prompt-injection patterns and block disallowed content, while producing a per-decision audit record.

The remaining controls need named owners. Training-data provenance belongs to data governance. Model-weight integrity and rollback belong to model operations and artifact storage. Local inference and STDIO tools belong to endpoint and workload security. Tool execution requires authorization at the application or tool gateway. Embodied systems need physical safety engineering and sensor testing, plus emergency stop mechanisms and operational procedures.

Draw the boundary on one page. Use solid lines for governed HTTP routes. Use dotted lines for local and offline paths, plus physical and provider-side paths. That visual detail prevents an architecture review from treating a proxy box as coverage for risks the proxy never sees.

DeepInspect

DeepInspect sits between authenticated users or agents and LLM endpoints as a stateless proxy for governed HTTP traffic. It can evaluate application-supplied identity and role, destination and data classification, plus the policy version before a request reaches the model. Response checks run before governed output returns, and each decision creates an independent audit record.

That boundary supports interface access and prompt policy, route control and monitoring, plus the log-evidence portions of the framework. Training data and model files remain with their assigned control owners. So do local execution and tool-side authorization, embodied systems and bypass traffic.

Book a technical deep dive at deepinspect.ai.