China's TC260 secretariat has opened public comment on a draft practice guide that sets out security steps for developing large-model software agent systems across preparation, design, implementation, testing and release, with feedback requested before 2 October 2026

What the notice does, and what it does not do

The notice is short. Under reference 网安秘字〔2026〕119号 and a signature date of 2026年9月18日, the TC260 secretariat says it organised the drafting of the guide 为指导智能体系统安全开发，防范化解相关安全风险 (our translation: to guide the secure development of agent systems and to prevent and resolve related security risks), and that, under the committee's document management measures for practice guides, it is now putting the draft to the public for comment.

The deadline sentence is the one to copy into a calendar: 如有意见或建议，请于2026年10月2日前反馈至秘书处。 Our translation: if you have comments or suggestions, please send them to the secretariat before 2 October 2026. The notice says before that date. It gives no time of day, no timezone and no submission form; it names a contact, 李子威, at liziwei@cesi.cn. We do not describe this as a 14-day window, because the notice does not, and we do not say that a submission on 2 October itself would be accepted.

What the notice does not do is equally plain. It adopts nothing, sets no effective date, and gives no indication of when a final version might follow. A practice guide is described in the draft's own foreword (p.I) as a standards-related technical document that the secretariat organises and publishes to provide standardization practice guidance. That is not a national standard and not a regulation, and nothing in either document changes a legal duty today.

Scope: large-model software agents, not physical-control systems

Section 1 of the draft (p.1) states its coverage: security development guidance for large-model-based agent systems across the preparation, design, implementation, testing and release stages, applicable to developers carrying out software agent development and usable as a reference in related assessment activities. That last clause is the only hook the draft offers to anyone other than a developer, and it is a may, not a shall.

The definition at 3.1 (p.1) draws the boundary in a note: the agent systems the draft means are mainly software agents built on large models, 不包括以机器人、自动驾驶等物理设备控制为主要功能的智能体系统 (our translation: excluding agent systems whose main function is controlling physical equipment such as robots or autonomous driving). The test is main function: an agent system whose main function is controlling physical equipment, such as robots or autonomous driving, is excluded. The note does not exclude a developer by industry, and a large-model software agent that sits beside a vehicle or robotics product is not taken out of scope by that sentence alone.

Section 5.1 (p.3) widens the developer side. It lists in-house development, platform-based building, low-code or no-code configuration and system integration as covered modes, and it says a developer who assembles an agent from third-party models, frameworks, tools, plugins, MCP services, APIs or data services would need to apply the guide according to how those pieces were brought in, configured, integrated and used. The abbreviation table (p.3) spells out MCP as Model Context Protocol, and 3.5 (p.2) defines an MCP service as one that supplies tools, resources or prompts to an agent under that protocol. This is a draft, so all of that is proposed scope.

The draft carries one normative reference, GB/T 45654-2025 on basic security requirements for generative AI services (section 2, p.1), and the model-selection item at 7(a)(1) (p.6) proposes using models that conform to it. Twelve drafting bodies are listed in the foreword (p.I), beginning with 浦江国家实验室 and 中国电子技术标准化研究院 and including 中国移动, 中兴通讯, 火山引擎, 科大讯飞 and 蚂蚁科技集团.

Five stages and a risk list written for agents

The abstract (p.III) names the risks the draft is built around: prompt injection, goal drift, privilege abuse, data leakage, memory pollution, supply-chain risk and cascading failure, arising in autonomous decision-making, task planning, tool calling, memory management and multi-agent collaboration. The body is then organised as five stage chapters, sections 6 to 10, matching preparation, design, implementation, testing and release.

The preparation chapter (section 6, pp.4-5) is where that taxonomy becomes a work product. Item (d) proposes threat analysis against a list that includes prompt injection, context pollution, memory abuse, tool-call risk, autonomous-decision risk and multi-agent coordination risk, assessed on dimensions the draft names: degree of autonomy, tool-call permissions, data sensitivity, reversibility of operations, external impact and user scale. Item (e) proposes a risk register recording source, impact, owner, controls, verification method, residual risk and the accept-or-treat decision, and says the high-risk operation list and the security requirements can feed the design, test and release gates. Item (f) proposes a compliance analysis against applicable laws and standards, without naming any.

Section 5.2 (pp.3-4) sets six principles: risk-oriented, tiered control by operation risk, human controllability, defence in depth, end-to-end traceability and explainability, and continuous optimisation. Section 3.8 (pp.2-3) defines prompt injection and splits it into direct injection in user input and indirect injection hidden in external data such as web pages, documents or database records. None of this is in force; it is what the secretariat is asking people to comment on.

Design and implementation: memory, context, tool calls and MCP

Chapter 7 (pp.5-12) is the design stage and chapter 8 (pp.12-20) is implementation. The two run in parallel, and the implementation items are the ones with engineering cost. On memory, 7(e) (pp.7-8) proposes short-term and long-term memory management, access control and integrity protection, isolation by user, tenant, session and task, and authorisation or policy approval for long-term memory writes. The matching implementation item 8(d)(4) (p.14) is concrete: after memory data is deleted, copies, caches and indexes would be cleaned up or invalidated.

On context, 7(d) (p.7) proposes source labelling, access control, content verification and isolation for user input, retrieved content, tool returns and external data, with trust checks on context passed across steps, turns, sessions, users, tenants or agents, and integrity protection for knowledge bases, retrieval indexes and embeddings. The instruction hierarchy is at 7(c) (pp.6-7): system instructions, developer configuration and user input would carry different trust levels and priority rules, with protection for the key instructions and safety policies themselves.

The tool-call material is where MCP appears by name. 7(h)(1) (p.9) proposes a least-privilege model for tools, skills, APIs, plugins and MCP services, defining each one's function, applicable scenarios, data reach and permission requirements. 8(f)(6) (p.15) proposes a pre-call authorisation check that verifies each tool call against the user's authorised scope; its design-stage counterpart at 7(h)(3) (p.9) states the aim, that an agent cannot use access it already holds to carry out operations the user did not authorise. 8(f)(5) proposes authenticity and integrity verification of an external capability's source before it is connected. Supply chain is at 8(m) (pp.18-19): identify base models, frameworks, components, tools, MCP services, APIs and external data services, record origin, version, licence, maintenance status and risk, and form a software bill of materials plus an AI-component inventory (8(m)(4), p.18). Draft text, all of it.

Execution limits are concrete in the draft. 7(g)(3) (p.9) and 8(e)(2) (p.14) propose caps on execution steps, model calls, tool calls, execution time, retries, resource use and external service quotas. 8(e)(3) proposes detection of abnormal loops, goal drift, permission changes and resource spikes with pause, terminate, restrict or hand-to-human responses, and 8(e)(4) proposes human confirmation, rollback, reversal or compensation for irreversible operations or those with external side effects. The runtime item at 8(n) (p.19) proposes sandboxes, containers or other isolation for inference, tool execution and code execution, default restriction of unnecessary network, filesystem and syscall access, and a one-line prohibition on the agent directly accessing unnecessary sensitive resources. 8(k)(4) (p.17) proposes no plaintext keys or tokens in code, configuration, prompts, context data or ordinary logs.

Testing and release: red teams, regression and staged rollout

Chapter 9 (pp.20-24) opens by saying developers may verify security through functional testing, security testing and red-team testing, among other methods. That is permissive language; the draft does not set up a mandatory red-team programme. The eleven test items then mirror the design chapter: injection and instruction override (9(a)), untrusted context breaking system instructions (9(b)), cross-user and cross-session memory leakage and long-term memory poisoning (9(c)), unauthorised and privilege-escalating tool calls and risk propagation along call chains (9(d)), goal drift and runaway loops (9(e)), whether high-risk operations actually trigger human confirmation (9(f)), rogue agent admission and delegation in multi-agent setups (9(g)), and circuit-break, isolate, recover and roll back (9(h)).

Two process items would matter for release cadence if the draft were adopted as written. 9(k)(1) (p.23) proposes regression testing when key components, such as the model, prompts, policies, tools, data or dependencies, change, and 9(k)(3) (p.24) proposes test records that capture the environment, system version, model or service version, prompt and data versions, scenarios, inputs, expected and actual results, analysis and re-test conclusions.

Chapter 10 (pp.24-25) is the release stage in eight items: a pre-release assessment confirming that testing is complete, issues are fixed or covered by equivalent controls, and that model version, prompt templates, tool configuration and safety policy match what was tested (10(a)); confirmation that safeguards are switched on in the release build (10(b)); version records that support rollback (10(c)); authorised release operations, with renewed security assessment and verification for major changes, the draft giving base-model replacement, tool-permission adjustment and safety-policy change as its examples (10(d), p.25); observable canary or staged release for high-risk systems (10(e)); pause or roll back on anomalies (10(f)); post-release verification (10(g)); and retained release and assessment records (10(h)). As a draft this is a proposed release checklist, not a filing or approval requirement, and the draft names no regulator that would receive any of these records.

Where it sits beside the deployment and interaction guides

This is the third TC260 agent-security document this desk has covered. The draft's reference list (p.26) cites the deployment and use guide, 网络安全标准实践指南 智能体部署使用安全指引, alongside 人工智能安全治理框架 2.0, GB/T 45654-2025, GB/T 47470-2026 on software secure development capability assessment, and ISO/IEC 22989:2022. It does not cite the agent interaction draft, and it does not say that it amends, replaces or is packaged with either sibling. We describe the three as covering different lifecycle slices, development here, deployment and use in one sibling, agent-to-agent and agent-to-tool interaction in the other, and we claim nothing beyond that.

A drafting detail worth knowing before you comment: several chapter-8 items are written with 应 (shall), for example context security at 8(c), memory at 8(d), execution control at 8(e), external calls at 8(f) and runtime at 8(n), while others use 宜 (should), such as the guardrail tuning clause at 8(l)(3) and release-anomaly handling at 10(f). In a draft practice guide neither word creates a legal obligation. Under the usual Chinese standards-drafting convention 应 marks a requirement and 宜 a recommendation, so on this desk's reading the split marks which controls the drafters treat as baseline and which as recommended, and a comment aimed at one of those words is a concrete comment.

What we did not verify

What we opened: the notice at the TC260 URL, fetched live on 18 September 2026 (byte-identical to the copy held in this run's evidence) and read in full, including the reference line, both substantive paragraphs, the contact line, the attachment line and the signature; and the attached PDF, downloaded from the notice's own attachment link (1,027,156 bytes, matching the copy on disk) and read in full as extracted text: cover, foreword, statement, abstract, contents, sections 1 to 10 and the reference list, 26 printed pages plus front matter.

What we did not open: the TC260 document management measures for practice guides that the notice cites; GB/T 45654-2025, GB/T 47470-2026, 人工智能安全治理框架 2.0 and ISO/IEC 22989:2022; the deployment and use guide and the interaction draft themselves, which we describe only as this draft's reference list and our earlier reports describe them; and any comment already filed by anyone.

What we refuse to claim: that any of this binds anyone, because it is a draft practice guide with no in-force date. That a comment sent on 2 October itself would be accepted, because the notice says before that date. That this is a 14-day window, because the notice does not say so. That this draft supersedes, amends or is bundled with either sibling guide, because it does not say so. That it reaches agent systems whose main function is controlling physical equipment such as robots or autonomous driving, because the note to 3.1 excludes them by main function. That any regulator or assessor applies it today, or when or whether a final version will appear. That any control it lists is effective. Where we write shall or should we are reporting the draft's own 应 or 宜; nothing in our own voice is an obligation.

Informational analysis for working professionals, not legal advice. Confirm how any rule applies to your situation with qualified counsel.

Related briefings

• TC260 deployment and use security guide for AI agents
• TC260 draft on AI agent interaction security
• CAC, NDRC and MIIT opinions on AI agents
• Asia-Pacific AI regulation tracker
• AI Regulation News hub