Operationalizing AI Agent Governance — A Ten-Step Internal Control Framework

Editor’s Note — DCC.

This is Part 2 of DCC’s brief on the Chinese Agent Rules (《智能体规范应用与创新发展实施意见》, May 8, 2026). Part 1 mapped the ten-category risk taxonomy. This brief works through the ten-step governance framework — the internal-control architecture practitioners are building to operationalize the regime. Adapted from a substantive piece by 朱垒 (Zhu Lei), originally published via 数据何规. The framework reflects converging practice across Chinese AI-compliance teams; overseas counsel will recognize many components but should pay particular attention to the permission-inheritance failure mode (Step 4) and the AI-specific incident response (Step 10) — the two areas where Chinese practice has surfaced operational issues that the general data-security playbook does not address.

Why a ten-step framework rather than a single control

The Agent Rules treat AI agents not as an extension of generative-AI services but as a distinct system class requiring full-lifecycle governance — from deployment-decision (whether and what to deploy) through design (how the agent is permissioned and constrained) through operations (how its behavior is monitored) through incident response (what to do when something breaks). A single control point — say, a model-output review — addresses none of the new risk categories the risk taxonomy surfaced.

Zhu’s framework — drawn from project experience with multiple Chinese enterprises that have already stood up agent governance — is ten components organized into three temporal tiers:

Pre-deployment (requirements stage): Steps 1–2. Governance organization + use-case admission and classification.
Development and testing stage: Steps 3–8. Security assessment + identity/authorization + data protection + tool security + human oversight + supply-chain security.
Post-deployment (operations stage): Steps 9–10. Continuous monitoring + AI-specific incident response.

What follows works through each.

Step 1 — Cross-functional governance organization + agent asset inventory

Governance organization. For enterprises with scaled or planned-scale agent use, agent governance cannot sit only within the tech team. The recommended structure is a cross-functional body involving the board or executive team (setting the enterprise’s agent risk appetite, prohibited scenarios, and high-risk scenarios), the algorithm / AI team, legal, information security, and the business owners. Either folded into existing data-compliance or cybersecurity governance, or stood up as a dedicated AI Governance Committee.

Agent asset inventory. A unified internal inventory of every agent operating in the enterprise — self-developed, third-party-purchased, business-system-embedded, employee-configured low-code or no-code agents. Each inventory entry records:

Agent name and business purpose
Owning department and responsible person
Model source and vendor
Tool list and external-API connections
Data-access scope
System-access scope
Deployment environment
Audience (internal, customer-facing, partner-facing)
Risk level (per Step 2 classification)
Lifecycle status

The inventory is the precondition for everything downstream: without knowing what agents exist and what they’re connected to, classification, permission control, audit, and incident response have no anchor. Chinese teams that have skipped the inventory step have, by Zhu’s account, consistently hit issues at the audit or incident-response stage.

Step 2 — Use-case admission + classification

Classification. A four-tier classification standard is the working pattern:

L1 — Low-risk read-only assistance. Internal document summary, knowledge retrieval, text refinement.
L2 — Limited write or internal-flow assistance. Drafting tickets, generating email drafts, supporting internal reports — but with mandatory human-completion for the final submission.
L3 — Sensitive-data processing or multi-internal-system access. Customer-service agents handling user PI, after-sales records, or order data.
L4 — High-impact decisions or actions. Auto-payment, contractual commitments, diagnostic-or-treatment recommendations, credit decisions, production-system changes, external-transaction execution.

L3 and L4 agents face higher approval thresholds, mandatory pre-deployment testing, and stricter ongoing monitoring.

Use-case admission assessment. Before any agent goes live, the assessment covers at minimum:

Does it access databases? What is the scope? Does it touch personal information, trade secrets, or other sensitive data?
Does it access external systems? Does it interact with third-party systems? What is the attack surface?
Does it have write, transaction, or decision capabilities? Are its actions reversible?
What is the target audience? Public-facing? Employee-facing?
What is the business-domain error tolerance? Does it touch finance, medical, hiring, credit, contract negotiation, critical-infrastructure operations, production-system code modification, or other high-risk domains?

The admission assessment prevents business units from quietly attaching agents to production environments without risk evaluation — a common pre-governance failure mode.

Step 3 — Security assessment + AI red-team testing

Security assessment. Before any agent goes live, the assessment covers task-completion accuracy, policy compliance, tool-call correctness, over-authorization attempts, prompt injection, sensitive-data leakage, anomaly recovery, rollbackability, log completeness, multi-agent cascade errors, and high-load stability.

Red-team testing for high-risk agents. Typical tests:

Embedded malicious instructions in webpages or documents — does the agent get tricked into data leakage?
Third-party tool return content — does it alter the agent’s system instructions?
Will the agent call unauthorized tools?
Will the agent send internal data to external APIs?
After task failure, does the agent loop and consume system resources?
When goals are under-specified, does the agent perform “specification gaming” to bypass restrictions?

Test results produce an issue list, remediation plan, and re-test record. High-risk agents with unresolved findings should not go live.

Step 4 — Identity authorization + permission control

Agents should be treated as enterprise-identity-management subjects — like employees, service accounts, or API clients. Each agent gets a unique identifier; the system records the user / department / business flow it represents; multiple agents sharing high-privilege accounts is prohibited.

Authorization principles — least privilege, task scope, time scope, context scope. The agent only accesses data, calls tools, and operates systems within the scope necessary to complete the specific task.

The permission-inheritance failure mode. Zhu calls out this trap explicitly because it’s the most-common operational issue in Chinese practice:

If an employee can only access one category of customer data, the agent they entrust should not — through technical configuration — acquire higher permissions.
If a primary agent calls a sub-agent or external tool, the sub-agent or external tool should not by default inherit the full permissions of the primary.

This sounds obvious, but the default configurations of most agent frameworks and orchestration platforms do not enforce permission inheritance limits. Engineering teams treating agent-to-agent or agent-to-tool calls as transparent function calls reproduce the human-employee permission structure in the agent layer — without realizing they’ve also reproduced the maximum-permission attack surface of every actor in the chain.

High-impact operations require additional gates. Payments, data deletion, bulk export, external sending, permission changes — all should sit behind multi-factor authentication, secondary authorization, or mandatory human execution.

Dynamic authorization scenarios require recording the authorizer, scope, reason, time, validity period, and revocation mechanism.

Step 5 — Data protection

The enterprise should systematically map every data-processing scenario the agent touches: user input, memory modules, runtime logs, third-party transmission. For PI, sensitive PI, or other regulated data categories, conduct the data-compliance review, PI Impact Assessment, or cross-border transfer impact assessment as applicable.

Boundary-line specifications. The enterprise should explicitly specify:

Which data may enter the model context
Which data may be written to long-term memory
Which data may be sent to third-party tools
Which data must be desensitized, encrypted, isolated, or simply prohibited from processing

Consumer-facing agent disclosure. For agents facing users or consumers, the enterprise should clearly disclose: AI identity, primary function, capability limitations, data-access scope, human-intervention mechanism, complaint channel.

Internal-use agent rules. For employee-internal agents, internal policy and training should cover: what categories of sensitive information may not be input; when human review is mandatory; how to mark classified material; how to report anomalies; whether internal materials may be input to external agents.

Log and memory governance. Retention period, access permissions, deletion mechanisms, audit rules — to prevent uncontrollable data accumulation over the agent’s operating life.

Step 6 — Tool and protocol security

Tool calls are the core risk source. The enterprise should:

Establish a tool whitelist system — for each tool, specify input/output, call permissions, rate limits, error handling, sensitive-data filtering, and logging requirements.
For MCP servers, browser plugins, third-party APIs, code-execution environments, and RPA tools — conduct security assessment and vendor review.
Prohibit agents from installing plugins or connecting to unknown servers without review; prohibit sending internal sensitive data to unvetted external tools.

Step 7 — Human-in-the-loop design

Per agent risk tier, configure appropriate human-intervention mechanisms:

Low risk — ex post sampling sufficient
Medium risk — key-node confirmation
High risk or irreversible action — ex ante approval, two-person verification, or human execution

The enterprise should periodically audit whether the human-approval is meaningful — i.e., that the approver actually reviews, rather than mechanically clicking through due to automation bias. The audit posture: “would this approval have caught the kind of error this agent is most likely to produce?”

Step 8 — Supply-chain security

The enterprise should integrate agent supply-chain into procurement-admission, information-security, and data-compliance review processes — vendor data-handling practices, security capabilities, model-update mechanisms, log retention, service availability, audit cooperation.

Contract terms with agent vendors should cover: model / plugin / tool / log responsibilities; vulnerability response; data handling; IP; infringement complaints; service interruption; security-incident notification.

For vendors processing PI, trade secrets, or regulated data, require security-capability proof, signed data-processing agreement, and AI-compliance-and-security-protection special clauses in the contract.

Step 9 — Continuous monitoring

Post-deployment, the enterprise should establish dynamic-behavior monitoring. Indicators include:

Anomalous tool-call count
External-data-send volume
Failed-retry count
Over-authorization request count
Human-rejection rate
User complaints
Hallucination-induced correction count
System-resource consumption
High-risk-operation frequency
Sensitive-data hit rate
Vendor service anomalies

For abnormal-resource-consumption scenarios, the enterprise should pre-negotiate with the vendor on billing, quotas, alerts, and loss-cutoff mechanisms — to avoid catastrophic cost or service loss from runaway agent loops.

Step 10 — AI-specific incident response

Agent incidents may include: data leakage, over-authorization, erroneous transactions, misdirected emails, production-system damage, consumer misleading, vendor tool compromise, successful prompt injection, multi-agent cascade failure, erroneous-recommendation harm, agent-repeated-execution resource exhaustion.

These do not map cleanly onto traditional cybersecurity incident-response playbooks. Zhu recommends building agent-specific incident response with reference to the Cybersecurity Standard Practice Guide — Generative AI Service Security Emergency Response Guide.

Five operational priorities — what to do now

Zhu’s concession: a “big-and-comprehensive” governance regime build takes time. For enterprises that need to start without waiting, the operational priorities are five:

Map and assess existing agents. Identify current and planned-deployment agents that touch PI, external systems, automated decision-making, or critical business flows. Flag those carrying significant security, compliance, or business risk.
Customer-facing agent service terms. Draft or update AI Agent Service Terms documenting the agent’s identity, function scope, action boundaries, data-processing practices, user authorization, human-intervention, complaint and feedback paths, and liability allocation.
Procurement and vendor contract clauses. Develop a procurement-admission standard for agent R&D, purchasing, and third-party supply-chain cooperation; insert AI-compliance-and-security-protection special clauses into procurement and cooperation agreements covering functional availability, data handling, memory retention, tool calls, resource consumption, vulnerability response, service interruption, IP, and security-incident notification.
Workflow review for production-integrated agents. For agents already integrated into business flows, assess whether human-verification mechanisms are needed; adjust workflows, user-interaction interfaces, internal-approval processes, and log-retention rules accordingly.
Existing GenAI compliance overlay. For enterprises with generative-AI services or algorithmic-recommendation deployments, assess and complete the model-filing, algorithm-filing, PIIA, and cross-border-transfer assessment work as applicable. Agent deployments don’t substitute for the underlying GenAI compliance work.

What this tells overseas compliance teams

Use Step 1 — inventory — as the entry point if no other agent-governance work is in place. It’s the cheapest, fastest, and unblocks everything downstream. Multinationals with Chinese operations should ensure the inventory captures both China-deployed and China-data-touching agents.
The L1 / L2 / L3 / L4 classification is converging across jurisdictions. Zhu’s four-tier framework aligns with Singapore IMDA’s framework and is broadly compatible with the EU AI Act’s risk tiers. Use one classification system across the global agent estate; map Chinese L3 / L4 expectations to the higher of {EU high-risk requirements, China L3/L4 requirements}.
The permission-inheritance failure mode (Step 4) is the most under-recognized risk. It manifests as a technical-implementation issue but produces a legal liability surface. Overseas teams should specifically audit how their agent frameworks handle agent-to-agent and agent-to-tool permission propagation, and require their vendors to demonstrate non-inheritance defaults.
AI-specific incident-response is the operational backstop you don’t have until you build it. Traditional cyber-incident-response playbooks assume a relatively static system; agent failures are dynamic and can self-propagate. Build the agent-specific response now, before you need it — the Generative AI Service Security Emergency Response Guide is a useful starting reference.
Operationally prioritize the five-step practical plan over the ten-step comprehensive framework. Especially for non-AI-native enterprises just starting agent deployment, the inventory + classification + customer-facing-terms + vendor-clauses + workflow-review sequence captures most of the risk reduction without overwhelming the compliance team.

The structural takeaway: the Chinese Agent Rules are accelerating an operational architecture that will become global compliance baseline within 24–36 months. Multinationals that build it for the Chinese regime get the global build essentially free; teams that wait for global guidance to crystallize will be reverse-engineering compliance into deployed agents at the worst possible time.

For the underlying ten-category risk taxonomy that this framework is designed to manage, see Part 1 of this series.

— 朱垒, 从《智能体新规》看AI智能体的风险防范与合规治理（下）(Risk Prevention and Compliance Governance of AI Agents Under the Agent Rules — Part 2), 数据何规 WeChat Official Account, May 20, 2026. Original article (Chinese).

Not legal advice. The above is DCC’s structured summary of Zhu’s framework, with framing for overseas counsel; the ten-step framework and the five-step priority sequence are Zhu’s. Author views are his own.