Somewhere in your agent's system prompt is a sentence like "always ask the user before making a purchase." That sentence is the entire autonomy boundary of most agents shipping today, and as of 15 July 2026 there is a national regulator that considers it insufficient by construction. China's Implementation Opinions on Intelligent Agents require every deployed agent to sort its decisions into three tiers — human-only, user-approved, autonomous — before deployment, and to never exceed the scope the user granted. You cannot satisfy that with a prompt. You satisfy it with a gate outside the model, which is exactly the thing good agent architecture was already converging on.
At a glance
One document, three ministries, and the first time a national government has treated agents as a regulated category in their own right rather than as an application of generative AI.
| Item | Detail |
|---|---|
| Document | Implementation Opinions on the Standardized Application and Innovative Development of Intelligent Agents (智能体规范应用与创新发展实施意见) |
| Issued by | Cyberspace Administration of China, National Development and Reform Commission, Ministry of Industry and Information Technology — jointly |
| Published / in force | 8 May 2026 / 15 July 2026 |
| Instrument type | Implementation Opinions — a policy directive, not a statute. Sets required practice and signals what codifies next. |
| Core obligation | A documented, three-tier decision-authority boundary per agent, established before deployment |
| Scope of application | Classified and tiered by scenario: sensitive sectors carry filing, testing and recall duties; low-risk uses rely on self-assessment and industry self-discipline |
The rule that actually bites
Most of the document is what you would expect from an industrial policy: a definition of intelligent agents as systems capable of autonomous perception, memory, decision-making, interaction and execution; nineteen named application scenarios spanning scientific research, industrial development, consumption, public welfare and social governance; commitments on standards bodies, open-source ecosystems and evaluation tooling. It is written in the register of 放得活 and 管得好 — keep it lively, keep it governed — and most of it is promotion rather than restriction.
Then there is the authorisation requirement, and it is unusually specific for a document of this type. Before an agent is deployed, the boundary between three classes of decision has to be established and written down:
- Decisions only the user may make. The agent may prepare, recommend and explain; it may not act, and no delegation makes it able to.
- Decisions the agent may execute only after user authorisation. Approval is per-action or per-scope and precedes execution.
- Matters the agent may handle autonomously, strictly within a delegated scope.
Attached to that are two clauses which are easy to skim past and which do most of the work: users retain the right to be informed of the agent's autonomous decisions and the final say over them, and the agent's execution must not exceed the scope the user approved. Read them as engineering requirements rather than as principles and it becomes clear what is being asked for.
Why a prompt cannot satisfy this
An instruction is not a boundary
If the rule "ask before purchasing" lives in the system prompt, then the component enforcing the boundary is the same component that reads attacker-controllable text, that is sampled stochastically, and that will occasionally decide this particular purchase is obviously what the user wanted. It is not a control; it is a strong suggestion made to a probabilistic system. The clause "must not exceed the scope the user approved" is unsatisfiable in that design, because nothing in the system knows what the approved scope is in a form anything can check.
Move the boundary outside the model and every clause becomes implementable. The model proposes an action; a gate reads the action's type and parameters, looks up the scope the user actually granted, and refuses, escalates or executes. The tier is a property of the action, resolved by code. "Never exceed the approved scope" becomes a comparison between two data structures instead of an aspiration.
The three tiers are a permission model you already needed
Written out, tier 1 is an action the agent's credentials should not be able to perform at all; tier 2 is an action requiring a fresh authorisation token; tier 3 is an action inside a standing grant. That is ordinary authorisation design, and it has a well-understood implementation: scope the credential rather than the prompt, keep a record of what was granted and when, and make the grant expire. The regulation's contribution is not the mechanism — it is the requirement that you enumerate the actions and classify them before deployment rather than discovering the classification during an incident.
Anyone who has built agents seriously will recognise that enumeration as the design document they meant to write and did not. It is tedious, it forces arguments about which actions are actually reversible, and it is the single most useful artifact an agent team can produce. A regulator has now made it mandatory in one large market, which is an unusual way for a best practice to spread but not an ineffective one.
The clause about being informed is a logging requirement
"Users retain the right to be informed of autonomous decisions" cannot be met by a system that does not record what it decided autonomously and why. In practice this means a per-action record — proposal, tier, the grant relied upon, the outcome — held somewhere the agent itself cannot rewrite. Teams that already run agent tracing have most of this; teams that log at the conversation level have almost none of it, because the unit of record is wrong.
How this differs from the frameworks you already track
The interesting difference is not strictness, it is the unit of classification. The EU AI Act tiers systems: you determine whether your product is prohibited, high-risk, limited-risk or minimal-risk, and a set of obligations attaches to the product. The Implementation Opinions tier decisions: one agent contains actions in all three tiers simultaneously, and the classification is a table, not a label. The NIST AI RMF, meanwhile, tiers nothing and describes a process an organisation runs.
Decision-level tiering maps onto agent architecture in a way system-level tiering does not. An agent is not one risk level — a coding agent that reads files, runs tests and opens pull requests spans three obligation classes in a single loop, and a product label cannot express that. This is why the EU approach, applied to agents, tends to produce a compliance artifact that sits beside the system, while the Chinese approach produces one that has to be compiled into it. Whether that was the drafters' intent or a happy accident of translating 分级分类 governance onto a new technology, it is the more architecturally honest cut.
The obligations still scale by sector in the familiar way. Agents in healthcare, transport, media and public safety face filing, compliance testing and product-recall provisions; entertainment and routine office use get self-assessment tooling, information reporting and industry self-discipline. What does not scale away is the authorisation boundary itself.
What to do about it
The obvious action if you operate in China is to read the document properly with counsel. The less obvious and more broadly useful action is to build the artifact it demands regardless of where you ship, because the work is small and it is load-bearing for reasons that have nothing to do with any regulator.
| Step | What it produces | Why it pays outside China too |
|---|---|---|
| Enumerate every action your agent can take, including via tool servers | A list, usually longer than expected | Most teams discover actions nobody knew were reachable |
| Classify each into the three tiers by reversibility and blast radius | The authorisation table | Settles autonomy arguments once, in writing, instead of per incident |
| Enforce tier 1 and 2 in credentials and a gate, not in the prompt | An authorisation check outside the model | The only defence that survives prompt injection |
| Record proposal, tier, grant and outcome per action | An append-only decision log | The evidence any incident review or audit will ask for |
| Expire standing grants and re-ask | Bounded delegation | Stops scope creep as the agent gains tools |
Be clear-eyed about the limits of the document too. Implementation Opinions are a policy instrument rather than binding law with defined penalties; the enforcement mechanics, the testing standards and the filing procedures are largely delegated to sector regulators and standards bodies that have not all published yet. Anyone telling you exactly what compliance looks like in operational detail is ahead of the available facts. What is safe to conclude is directional: the first national regulator to write down what an agent's autonomy boundary must look like chose per-decision authorisation, and regulators copy each other.
FAQ
Does this apply to a company outside China?
Directly, it applies to agents deployed for users in China, and the practical test is where your users are rather than where your company is. Indirectly it matters everywhere, because it is the first concrete regulatory specification of an agent autonomy boundary and it is likely to shape what other regulators ask for.
Is this a law with penalties?
Implementation Opinions are a policy directive issued jointly by ministries, not a statute passed by the legislature. They set required practice and direct sector regulators to act; the enforceable detail arrives through the sector rules, standards and filing regimes they instruct. Treat it as binding on practice and provisional on penalty.
Is a confirmation dialog enough for tier 2?
Only if the confirmation is what actually unblocks execution. A dialog that the model can decide to skip is UI, not authorisation. The test is whether an action can reach the outside world when no approval record exists — if it can, you have a prompt-level boundary wearing a gate's clothing.
Where does this leave fully autonomous agents?
Unaffected in principle, constrained in practice. Tier 3 explicitly exists, and an agent may act on its own within a delegated scope. What the document rules out is an unbounded delegated scope — the user has to have granted something specific, and the agent has to be unable to exceed it.
We already do human-in-the-loop approvals. Is that the same thing?
It is the same idea and usually a weaker implementation. The common pattern gates on a model-produced confidence signal or on a prompt instruction; the requirement here is that the classification be a property of the action, decided before deployment and enforced independently of the model.
Further reading
On this wiki:
- Autonomy levels — the five-rung ladder this regulation compresses into three.
- Scoped credentials for agents — how tier enforcement is actually implemented.
- The EU AI Act for agents — the system-level tiering this contrasts with.
- Audit trails — the record the right-to-be-informed clause requires.
- Approval & confirmation UX — making tier 2 usable rather than click-through.