AI agent trust in Greater China depends on verification

At a glance

What this is: This is a consumer survey analysis showing that AI agent trust in Greater China depends on verification because adoption is outpacing recognition, accountability, and safeguards.

Why it matters: IAM, fraud, and identity teams need this because delegated action without clear verification creates a control gap across human approval, NHI governance, and emerging agent identity models.

By the numbers:

• 44% across Greater China say they have already experienced at least one negative outcome linked to AI agent use.

Context

AI agent trust is the central governance problem here: users are being asked to delegate actions before they can reliably tell what an AI agent is, what it is allowed to do, or who remains accountable for the result. In Greater China, that creates a faster path from novelty to operational risk than many identity programmes are designed to handle.

The article’s core signal is that adoption is not limited by capability alone. It is limited by verification, consent, and traceability, which means the identity question is no longer just whether an agent can act, but how a person or organisation can prove that the action was authorised and attributable.

Key questions

Q: How should security teams verify AI agents before allowing delegated actions?

A: Use a registration model that binds the agent to a responsible person or organisation, records its purpose, and issues a stable identity signal that can be checked at runtime. Verification should prove legitimacy, but it should not automatically grant broad access. The agent still needs scoped permissions, logging, and revocation controls.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What breaks when consumers cannot tell an AI agent from ordinary automation?

A: Delegation becomes unsafe because users may grant real authority to software they do not understand, and attackers can hide inside that confusion. When identity labels are unclear, consent, accountability, and permitted scope all weaken at once, which raises the risk of unauthorized actions and account abuse.

Q: How should organisations secure payments when AI agents can buy on behalf of users?

A: They should separate user authentication, agent delegation, and purchase approval into distinct controls. That means phishing-resistant authentication for the human, explicit policy for the agent’s scope, and verifiable claims that the merchant can validate at transaction time. Without that separation, a delegated agent becomes just another opaque buyer with too much power.

Technical breakdown

Why AI agent verification becomes an identity control, not a UX feature

Verification is the mechanism that turns an AI agent from an opaque automation into a recognisable acting entity. In consumer and enterprise settings alike, the identity problem is not only authentication at login, but binding a runtime actor to a responsible principal, a scope of permissions, and an auditable trail. That matters because agentic systems can operate across messaging, commerce, search, and workflow surfaces where users do not see every step. When an agent can initiate actions on behalf of a user, the control plane must prove who authorised it and what it may do. Without that, delegation becomes indistinguishable from abuse.

Practical implication: treat agent verification as part of access governance, not only as a trust badge or product feature.

Why delegation, scope, and traceability matter more than raw capability

The survey points to a familiar identity pattern: once an actor can do meaningful work on behalf of a person, the question shifts from functionality to delegation scope. An AI agent that can purchase, message, or modify account settings creates the same governance pressure as any other high-privilege non-human identity, except the scope can expand through prompts and runtime decisions. That makes traceability essential. A good control design records what the agent was permitted to do, which human or organisation stood behind it, and how to roll back harmful actions when the outcome is wrong.

Practical implication: define explicit delegation boundaries and require auditable attribution for every agent-initiated action.

Why consumer trust signals need to map to permission reality

A verified label only works if it reflects actual permission state. If a user sees an agent as trusted but cannot tell whether it has account access, external-service access, or approval authority for high-risk actions, the trust signal is hollow. That is especially relevant in regions where digital platforms already compress many daily tasks into a single interface. In that environment, the difference between a helpful assistant and a risky autonomous actor is not theoretical. It is the difference between low-consequence guidance and credential-bearing execution.

Practical implication: align trust signals with real permission levels, not with marketing language or interface design alone.

Threat narrative

Attacker objective: The objective is to exploit delegated trust so actions appear authorised while harmful or fraudulent activity is carried out under an agent’s cover.

1. Entry occurs when a user accepts an AI agent without being able to reliably identify it or understand its delegation scope.
2. Privilege is then expanded through user consent or implicit approval, giving the agent access to actions, accounts, or external services.
3. Impact follows when that delegated access is misused, misunderstood, or abused, leading to unintended actions, fraud, data exposure, or account compromise.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Verification, not capability, is the trust control that now separates safe delegation from unsafe automation. The article shows that consumers are willing to use AI agents before they can reliably recognise them, which means trust is being built on assumed legitimacy rather than confirmed identity. That is a governance failure in waiting, because a delegated actor that cannot be verified cannot be safely authorised. Practitioner conclusion: treat verification as a prerequisite for agent-enabled access.

Identity programmes built for human users do not automatically extend to AI agents. Human IAM assumes the person can recognise the interface, consent to the action, and carry responsibility for the outcome. AI agents break that sequence by acting across multiple steps and services, often without the user observing the full transaction path. The implication is that identity governance must bind every agent to a responsible principal and a bounded scope, not merely a logged-in session. Practitioner conclusion: redesign consent and attribution for delegated action.

Know Your Agent is becoming the non-human equivalent of customer verification. The article’s KYA framing is useful because it names the real problem: proving what the agent is, who stands behind it, and what it may do before it starts acting. That is a better model than treating agent controls as a variation of chatbot moderation or fraud screening. Practitioner conclusion: organise controls around agent identity proofing, authorisation, and accountable linkage.

Greater China is exposing an identity blast-radius problem that will spread wherever super-app and embedded-agent adoption grows. When a single interface bundles messaging, commerce, search, and account access, the permissions attached to an agent can become operationally broad very quickly. That concentrates risk in a way familiar from high-value non-human identities. Practitioner conclusion: review where delegated AI could inherit platform-wide access without a matching governance model.

Agentic trust failures are now a fraud-enablement issue, not just a user-experience issue. The article ties adoption concerns to unintended actions, unauthorised purchases, data leaks, and account compromise. Those are not soft trust problems. They are concrete abuse paths that sit at the intersection of identity, fraud, and access control. Practitioner conclusion: align fraud controls, IAM, and agent verification around the same delegated-action record.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Verified delegation is becoming the primary control boundary for agentic identity. As AI agents move from guidance to action, the programme question is no longer whether users like them. It is whether the organisation can prove who authorised the agent, what it may do, and how to revoke it when trust changes.

Trust signals must match permission reality. A visible label or friendly interface does not reduce risk unless it reflects the agent’s actual scope, especially where account changes, payments, or external service access are involved.

Identity blast radius is the real programme metric. The more one AI agent can touch messaging, commerce, search, and account workflows, the more important it becomes to separate low-risk assistance from privileged execution before deployment.

For practitioners

• Define agent identity proofing requirements Establish what evidence is required before an AI agent can act on behalf of a user, including linkage to a responsible human or organisation, allowed scopes, and revocation conditions.
• Bound delegated permissions by action type Separate low-risk guidance from high-risk execution, and require explicit approval for payments, account changes, data sharing, and external-service access.
• Log every agent-initiated action with attribution Capture who authorised the agent, what it was allowed to do, which systems it touched, and whether the user approved or reviewed the action.
• Align fraud controls with identity controls Use fraud signals, anomaly detection, and identity telemetry together so suspicious automation is evaluated as delegated access, not as isolated transaction noise.

Key takeaways

• AI agent adoption in Greater China is revealing a governance gap between user willingness and user understanding, which makes verification a prerequisite for safe delegation.
• The operational risk is not abstract. The survey links agent use to unintended actions, unauthorised purchases, data leaks, fraud, and account compromise.
• The control that matters most is accountable, scoped delegation with auditable attribution, because trust signals only work when they match real permissions.

Key terms

• AI Agent Authentication: The method an autonomous software agent uses to prove identity and obtain access to systems, APIs, and data. In enterprise settings, this is an NHI control point because the authentication choice determines scope, revocation speed, and whether access can be governed as part of the identity lifecycle.
• Delegation authority: Delegation authority is the right for one identity to act on behalf of another within a defined scope. For agents, it must be explicit, time-bound, and auditable because the system may initiate actions independently once granted access.
• Trust signal: Any cue that makes a person or system seem legitimate, such as a familiar name, known channel, authority marker, or expected behaviour. Fraud targets these signals directly, so security programmes must distinguish between recognition and proof.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.