𝗔𝟮𝗔 𝗣𝗿𝗼𝘁𝗼𝗰𝗼𝗹 𝗔𝘂𝘁𝗵: 𝗪𝗵𝘆 𝘁𝗵𝗲 𝗦𝗽𝗲𝗰 𝗶𝘀 𝗧𝗵𝗶𝗻 𝗮𝗻𝗱 𝗪𝗵𝗲𝗿𝗲 𝘁𝗵𝗲 𝗛𝗼𝗹𝗲𝘀 𝗔𝗿𝗲

The A2A (Agent2Agent) protocol is becoming the standard for AI agent communication. Google announced it in 2025 and the Linux Foundation runs it now.

When I looked at the authentication section of the spec, I found almost nothing. It does not define a new authentication mechanism. It simply tells you to use existing standards like OAuth2, OpenID Connect, or mTLS.

This thinness is intentional. A2A defines the frame but delegates the contents to other standards. This creates security holes if you are not careful.

𝗛𝗼𝘄 𝗔𝟮𝗔 𝗪𝗼𝗿𝗸𝘀 A2A is a protocol for one agent to hand a task to another. It uses JSON-RPC over HTTP.

• Client Agent: The agent that sends the request. • Remote Agent: The agent that receives the task. • Agent Card: A JSON file where the Remote Agent lists its capabilities and auth requirements.

The Agent Card is the most important part. A client reads this card first to learn how to authenticate before sending a request.

𝗧𝗵𝗲 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗛𝗼𝗹𝗲𝘀 A2A leaves several critical tasks to the implementer. If you do not handle these, your agents are at risk.

• Card Tampering: Signing the Agent Card is optional (MAY). If you do not sign it, an attacker can redirect your agent to a malicious server.
• Replay Attacks: A2A does not have a way to bind tokens to a specific client. If someone steals a bearer token, they can impersonate your agent.
• Privilege Escalation: Authorization is left to external infrastructure. If you do not enforce per-skill checks, a "read-only" agent might gain "write" access.
• Identity Chaining: A2A does not handle how a user's identity moves through a chain of agents.

𝗛𝗼𝘄 𝘁𝗼 𝗕𝘂𝗶𝗹𝗱 𝗜𝘁 𝗦𝗮𝗳𝗲𝗹𝘆 Do not rely on the spec alone. You must turn the optional rules into mandatory ones.

• Always sign your Agent Cards. Use JWS and JCS. • Use mTLS for agent-to-agent paths. This prevents token theft from being enough to compromise your system. • Enforce per-skill authorization at your API Gateway. • Use sender-constrained tokens (like DPoP) to stop replay attacks.

A2A is the plumbing. The security comes from the water you run through it. Use proven standards like SPIFFE or Identity Chaining to fill the gaps.

Mổ xẻ cơ chế xác thực giao thức A2A: Tại sao bản đặc tả lại mỏng và những lỗ hổng còn tồn tại

Giao thức A2A (Agent-to-Agent) hứa hẹn một tương lai nơi các tác nhân (agents) có thể giao tiếp và giao dịch với nhau một cách liền mạch. Tuy nhiên, khi đi sâu vào cơ chế xác thực (authentication) của nó, chúng ta sẽ thấy một thực tế khác: bản đặc tả (specification) hiện tại cực kỳ mỏng và thiếu chi tiết, để lại nhiều lỗ hổng bảo mật tiềm tàng.

Bản đặc tả "mỏng" là gì?

Khi đọc qua tài liệu kỹ thuật của A2A, bạn sẽ nhận thấy một mô hình dựa trên các tuyên bố ở mức cao (high-level statements) thay vì các quy trình thực thi cụ thể. Thay vì định nghĩa chính xác các bước để thiết lập một kết nối tin cậy, đặc tả chỉ đơn thuần nói rằng "các tác nhân phải xác thực danh tính của nhau".

Điều này tạo ra một khoảng trống lớn giữa lý thuyết và thực hành. Một bản đặc tả tốt cần phải trả lời được các câu hỏi như:

• Các nguyên ngữ mật mã (cryptographic primitives) nào được sử dụng?
• Quy trình bắt tay (handshake) diễn ra như thế nào?
• Làm thế nào để chống lại các cuộc tấn công phát lại (replay attacks)?

Việc thiếu các chi tiết này có nghĩa là mỗi nhà phát triển có thể triển khai xác thực theo cách riêng của họ, dẫn đến sự thiếu nhất quán và các lỗ hổng bảo mật không đồng nhất trong hệ sinh thái.

Những lỗ hổng còn tồn tại

Việc thiếu các chi tiết kỹ thuật cụ thể dẫn đến một số vấn đề nghiêm trọng:

1. Sự mơ hồ về danh tính (Identity Ambiguity)

Nếu giao thức không định nghĩa rõ ràng cách thức một danh tính được tạo ra và liên kết với một khóa công khai (public key), thì việc xác thực chỉ mang tính hình thức. Không có một "nguồn sự thật" (source of truth) được quy định, các tác nhân có thể dễ dàng giả mạo danh tính hoặc sử dụng các danh tính không được kiểm chứng.

2. Quy trình bắt tay thiếu an toàn (Insecure Handshake)

Một quy trình bắt tay không được đặc tả kỹ lưỡng có thể dẫn đến các lỗ hổng như tấn công kẻ đứng giữa (Man-in-the-Middle). Nếu không có các bước xác nhận lẫn nhau (mutual authentication) được định nghĩa chặt chẽ, một tác nhân độc hại có thể chen vào giữa cuộc hội thoại và đánh cắp thông tin hoặc thao túng dữ liệu.

3. Thiếu cơ chế thu hồi (Lack of Revocation)

Điều gì xảy ra khi một khóa riêng tư (private key) bị lộ? Bản đặc tả hiện tại không đề cập rõ ràng đến cách thức thu hồi danh tính hoặc cập nhật các thông tin xác thực đã bị thỏa hiệp. Trong một hệ thống phi tập trung, việc quản lý vòng đời của danh tính là cực kỳ quan trọng.

Kết luận

Giao thức A2A có tiềm năng rất lớn, nhưng để thực sự an toàn trong một môi trường phi tập trung, nó cần một bản đặc tả mạnh mẽ hơn. Chúng ta cần chuyển từ những tuyên bố mơ hồ sang các tiêu chuẩn kỹ thuật cụ thể, đảm bảo rằng mọi tác nhân đều có thể tin tưởng lẫn nhau mà không cần một bên trung gian tập trung.