China's cybersecurity standards committee has circulated a draft practice guide setting security requirements for how AI agents talk to other agents and to tools

What the document covers

The scope clause is narrow and useful. The guide sets security requirements for agent-to-agent and agent-to-tool interaction, in three layers: general interaction requirements, inter-agent requirements, and agent-to-tool requirements. It says it is meant to guide agent service providers and tool providers, and to be usable by third-party assessment bodies evaluating interaction security.

It leans on a stack of existing Chinese standards, including GB/T 45654-2025 on basic security requirements for generative AI services, GB 45438-2025 on labelling AI-generated content, GB/T 45574-2025 on sensitive personal information processing, and the GB/Z 185 series on agent interconnection covering architecture, identity management, agent description and agent discovery.

Terminology matters here. An agent credential is defined as a tamper-resistant data set containing identity attribute claims, used for authentication. A tool is defined broadly as a functional entity an agent application can call, with cloud services, applications, other agents and external devices all given as examples.

The general layer

Every agent should have an identifier that uniquely identifies it and a credential corresponding to that identifier. Both sides of an interaction should support access control that decides whether to allow or interrupt access. Communication should run over a channel supporting authentication of the party being accessed and non-repudiation of both parties' behaviour, with encryption and integrity checking, and TLS 1.2 or above recommended.

Agents handling critical business carried by critical information infrastructure get a harder rule: cryptographic algorithms used in line with national cryptography administration and sectoral requirements for authentication, encryption and integrity checking.

Risk control is split into five subclauses. Providers should set interaction rate limits controlling how many counterparties an agent talks to and how often. They should support monitoring of interaction state, with user authorisation, tracking communication time, counterparty, state and behaviour. Where non-convergent interaction or communication anomaly is detected, the provider should forcibly terminate the interaction and record it. The note defines non-convergent interaction as a dialogue or operation sequence stuck in repetition, looping or contradiction, unable to advance the task, or interrupted by network failure or a counterparty agent crashing.

Incident handling is graded. Providers should have a tiered response plan distinguishing ordinary, relatively large, major and especially major events, and should report events above the relatively large threshold to the competent authority.

Registration and discovery

Clause 7.1 puts real weight on the registry. An agent identity registration service should authenticate agent identity, run monitoring that can alert on and deregister anomalous registrations, manage the identity lifecycle, and, notably, conduct a compliance review of the agent service provider itself, permitting only reviewed providers to register their agents.

It also asks the registry to test whether the agent description is true: capability scope, input and output types, the provider, and obvious false or malicious injection, with third-party assessment recommended. The claim in an agent card, in other words, is treated as something to be checked rather than accepted.

Discovery gets its own controls. Providers should disclose agent descriptions through a standardised discovery mechanism, and the discovering side should verify the completeness and source of the returned list. Where a service-based discovery mechanism is chosen, the service should have an interference-resistant recommendation ranking mechanism, tamper protection for the agent list, and malicious query identification and blocking.

Calls between agents, and calls to tools

For agent-to-agent calls the draft requires mutual authentication, an exchange of agent descriptions, security policies, data requirements and potential risks before a call agreement is reached, minimum privilege with a privilege negotiation mechanism whose validity can be verified, and protection of decision autonomy so an unauthorised party cannot alter the agent's decision logic or goals.

Two clauses carry more than their length suggests. The called agent must not enable high-risk system permissions without user authorisation. And the called agent must verify that the privilege granted by the caller, which is supposed to be the minimum consented to by the user, is consistent with the user's original authorisation, and must keep the call log.

On the tool side, tool providers should publish complete tool attribute information whose integrity and source can be checked, covering at least tool identifier, name, description and input and output parameters. Agents should obtain user authorisation before calling a tool, apply minimum interface exposure and minimum privilege, tell the user the risk and get express consent where high-risk system permissions are involved, refuse to call a tool identified as malicious, and stop when tool feedback is detected as malicious content or behaviour.

The risk annex

Annex A is informative, and it is the part a security team can use directly. It lists twelve risks with descriptions, the clauses covering them, and the solution in each clause: information tampering, information leakage, information absence meaning incomplete logs and untraceable responsibility, harmful information, identity error, permission loss of control, resource occupation, attack behaviour, component risk, hijacking of the user's choice, misuse of tools including malicious tools and tool combinations, and intent deviation, meaning reasoning and goal hijacking, hallucination amplification, drift accumulated over a long context, and abnormal task execution. The table is numbered T01 to T11 and then T14.

Some of these are familiar under other names. Hijacking of the user's choice covers infringement of tool choice, ranking manipulation, and mismatches at discovery caused by non-standard or tampered agent descriptions, and points at the ranking and description clauses as the answer.

The component risk entry is candid about its own limits. It handles supply chain exposure by pointing at the normative references to Chinese software supply chain security standards rather than by writing new requirements.

What we did not verify

We opened the TC260 notice page dated 29 July 2026 and downloaded and read the full 24-page draft PDF of the agent interaction guide, including the annex. Clause numbers, definitions, drafting bodies and the version string v0.23-202607 above come from that document.

We did not open the referenced standards themselves, including the GB/Z 185 series, GB/T 45654-2025 or GB 45438-2025, so we describe how the draft cites them and no more. We did not open the companion AI browser guide's comment record or any consultation responses.

We do not claim this draft will be published as a practice guide, published unchanged, or given any legal effect. Practice guides are not national standards and this one is a draft. We also make no claim about how Chinese assessment bodies are applying it, because the document does not say and we did not ask them.

Related briefings

• China: TC260 AI agent deployment security guide
• China: CAC, NDRC and MIIT opinions on AI agents
• Asia Pacific AI regulation hub
• For executives
• AI Regulation News hub