Why Securing AI Agents Is a Nightmare: How Many Are Struggling?

Why Fine‑Grained Permission Design Is a Prerequisite for Agent Commercialization

Traditional software behaves deterministically—clicking a button always triggers the same action. An AI agent, however, makes probabilistic decisions driven by an LLM, so the same user request can follow different execution paths. Consequently, the permissions granted to an agent may be used in ways the developer did not anticipate.

The 2025‑12 "Doubao" phone‑assistant incident illustrated this risk: the assistant obtained the Android system‑level INJECT_EVENTS permission, could simulate clicks and read the screen, and within two days caused WeChat account blocks and bank‑app security warnings. The episode sparked three layers of discussion—technical, commercial, and legal—highlighting that uncontrolled permission usage is a disaster for enterprise scenarios.

Fine‑grained permission design has historically been the foundation for large‑scale software adoption. Early iOS and Android permission models were coarse; over roughly five years they evolved to runtime, revocable, per‑resource permissions, enabling the explosive growth of the app ecosystem.

Why Existing Solutions Fall Short

MCP: USB‑C‑Like Interface with Architectural Flaws

MCP (Model Context Protocol) was introduced by Anthropic in Nov 2024 as a JSON‑RPC 2.0‑based standard for connecting LLMs to external tools. While it reduces integration complexity (M×N → M+N), its security design suffers from fundamental architectural defects.

2026‑04 OX Security report: >32 000 code repositories, 7 374 publicly vulnerable servers, >200 000 exposed servers.

CVE‑2025‑49596: MCP inspector lacks client‑agent authentication, leading to remote code execution (CVSS 9.4).

CVE‑2025‑6514: Untrusted MCP server can trigger OS command injection via crafted authorization_endpoint (CVSS 9.6).

MCP only defines model‑to‑tool communication; it does not involve the user or service as independent authorization parties, so permissions are either fully granted or denied, with no middle ground.

A2A: Agent‑to‑Agent Protocol Still Lacks Trust Bridge

A2A, released by Google in Apr 2025, standardizes inter‑agent communication using HTTP + SSE + JSON‑RPC 2.0 and includes OAuth 2.0‑style enterprise authentication. However, the protocol’s security relies heavily on each agent’s implementation quality. Agent cards declare capabilities but cannot verify the true identity of the counterpart, and the protocol does not address vulnerabilities in the agents themselves. Google plans extensions for trusted identities and delegated permissions, but no concrete solution is public yet.

CLI and GUI Automation: Over‑Privileged, Non‑Auditable, Data‑Boundary Risks

Excessive permissions : GUI automation often requires system‑level rights far beyond the task’s needs.

Unauditable operations : Simulated clicks are indistinguishable from real user actions, making forensic tracking nearly impossible.

Data‑boundary leakage : Screen captures can inadvertently collect passwords, PINs, and notifications, exposing data the agent does not need.

CLI approaches can limit privileges but cannot solve the inherent nondeterminism of LLM‑driven decision making.

ATH Mechanism: Three‑Party Trusted Handshake

The ATH protocol, announced in May 2026 by China Academy of Information and Communications Technology together with Tencent, Huawei, ZTE and three major carriers, introduces a user‑centric three‑party model: user + agent + service. Its core innovation is the “scope intersection” that grants a permission only when all three parties agree.

User sovereignty – users retain ultimate control over data; any interaction requires explicit consent.

Three‑party participation – the user, the agent, and the service must all be involved in the handshake.

Trusted handshake – both the agent and the service must be independently authenticated before any permission is granted.

Decentralization – identities are based on asymmetric cryptography rather than a single trusted node.

Least‑privilege – only the minimal set of scopes needed for the task is granted, and they expire automatically.

Full traceability – all interactions are cryptographically logged, immutable, and auditable.

The effective scope is computed as:

Effective Scope = Agent Approved Scopes ∩ User Consented Scopes ∩ Requested Scopes

Example from the ATH spec:

Agent approved: mail:read, mail:send
User consented:  mail:read, mail:send, mail:delete
Agent requested:  mail:read
──────────────────────────────────────
Effective scope:  mail:read

If the intersection is empty, no token is issued.

Handshake Flow (9 Steps)

Pre‑authorization (Step 0) : The user signs an authorization credential containing user ID, requested scopes, a signature, and an expiry (typically 7200 seconds). Declining ends the flow.

Phase 1 – Bidirectional Identity Verification (Steps 1‑4) :

Step 1 – Client sends a handshake request with its DID, public key, a nonce, and a timestamp.

Step 2 – Server records the client’s identity, generates its own nonce, signs the client’s nonce, and returns its DID, public key, nonce, and signature.

Step 3 – Client verifies the server’s signature, then signs the server’s nonce and sends the proof.

Step 4 – Server validates the client’s proof and returns a result indicating success and the list of scopes it supports.

Phase 2 – Trusted Negotiation (Steps 5‑8) :

Step 5 – Client sends a scope request containing the user‑authorization credential, desired scopes, and contextual description.

Step 6‑7 – Server forwards the request to the user for a second confirmation (the user sees a prompt like “Agent wants to read your mail – agree?”). The user can accept, reject, or modify the request.

Step 8 – Server returns the final approval result, listing the granted scopes (the intersection of agent‑approved, user‑consented, and service‑supported scopes), TTL, and optional restrictions such as rate limits or IP whitelists.

Phase 3 – Session Establishment (Step 9) :

The server issues an access token prefixed with ath_ (40 random characters). The client stores the token and uses it for subsequent API calls.

The flow includes three fast‑fail checkpoints; any failure aborts the handshake, preventing accidental privilege escalation.

Demo Walk‑through

The ATH repository provides a pure‑Python demo ( demo/ath_simple_demo_zh.py) that implements the full nine‑step handshake using only the standard library.

Key classes:

Client : simulates an AI shopping assistant, manages DID, keys, user pre‑authorization, and the handshake steps.

Server : simulates the e‑commerce backend, validates identities, handles user confirmation, and issues tokens.

All communication is JSON‑encoded, mirroring real network traffic.

Example of the user‑pre‑authorization method (Step 0):

def get_user_authorization(self, scopes: list) -> bool:
    while True:
        choice = input("
🤔 是否同意授权？(Y/N): ").strip().upper()
        if choice == 'Y':
            self.user_authorization = {
                "user_id": "user_001",
                "scopes": scopes,
                "signature": "user_signature_" + ''.join(random.choices(string.hexdigits, k=16)),
                "expires_at": int(time.time()) + 7200
            }
            return True
        elif choice == 'N':
            return False

Running the demo:

git clone https://github.com/ath-protocol/agent-trust-handshake-protocol.git
cd agent-trust-handshake-protocol
python3 demo/ath_simple_demo_zh.py

The interactive demo prompts for two Y/N confirmations (pre‑authorization and service‑to‑user confirmation) and completes in about two minutes, illustrating the entire handshake and token issuance.

Conclusion

Agent‑scale commercialization hinges on robust permission governance. Historical parallels show that each platform leap (mobile apps, databases) required new security models. ATH introduces a three‑party consent model and scope‑intersection calculation that directly addresses the core risk of agents acquiring unintended capabilities.

Although ATH is newly released (May 2026) and lacks real‑world deployments, its design—user‑centric consent, decentralized identity, PKCE‑backed OAuth integration—offers a concrete blueprint for building safer agent ecosystems.