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

A2A (Agent2Agent) ಪ್ರೋಟೋಕಾಲ್ AI ಏಜೆಂಟ್ ಸಂವಹನಕ್ಕೆ ಮಾನದಂಡವಾಗುತ್ತಿದೆ. ಗೂಗಲ್ ಇದನ್ನು 2025 ರಲ್ಲಿ ಘೋಷಿಸಿತು ಮತ್ತು ಈಗ ಇದನ್ನು ಲಿನಕ್ಸ್ ಫೌಂಡೇಶನ್ (Linux Foundation) ನಿರ್ವಹಿಸುತ್ತಿದೆ.

ನಾನು ಸ್ಪೆಕ್‌ನ (spec) ಅಥೆಂಟಿಕೇಶನ್ ವಿಭಾಗವನ್ನು ಗಮನಿಸಿದಾಗ, ಅಲ್ಲಿ ಏನೂ ಕಂಡುಬರಲಿಲ್ಲ. ಇದು ಯಾವುದೇ ಹೊಸ ಅಥೆಂಟಿಕೇಶನ್ ವಿಧಾನವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವುದಿಲ್ಲ. ಬದಲಾಗಿ, OAuth2, OpenID Connect ಅಥವಾ mTLS ನಂತಹ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾನದಂಡಗಳನ್ನು ಬಳಸಲು ಇದು ಸೂಚಿಸುತ್ತದೆ.

ಈ ಅಲ್ಪತೆಯು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿದೆ. A2A ಕೇವಲ ಚೌಕಟ್ಟನ್ನು (frame) ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ ಆದರೆ ಅದರ ಒಳಗಿನ ವಿಷಯಗಳನ್ನು ಇತರ ಮಾನದಂಡಗಳಿಗೆ ಬಿಡುತ್ತದೆ. ನೀವು ಎಚ್ಚರಿಕೆಯಿಂದ ಇಲ್ಲದಿದ್ದರೆ ಇದು ಭದ್ರತಾ ಲೋಪಗಳಿಗೆ (security holes) ಕಾರಣವಾಗಬಹುದು.

𝗛𝗼𝘄 𝗔𝟮𝗔 𝗪𝗼𝗿𝗸𝘀 A2A ಎಂಬುದು ಒಂದು ಏಜೆಂಟ್ ಮತ್ತೊಂದು ಏಜೆಂಟ್‌ಗೆ ಕಾರ್ಯವನ್ನು ಹಸ್ತಾಂತರಿಸಲು ಬಳಸುವ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ಇದು HTTP ಮೂಲಕ JSON-RPC ಅನ್ನು ಬಳಸುತ್ತದೆ.

• ಕ್ಲೈಂಟ್ ಏಜೆಂಟ್ (Client Agent): ವಿನಂತಿಯನ್ನು (request) ಕಳುಹಿಸುವ ಏಜೆಂಟ್. • ರಿಮೋಟ್ ಏಜೆಂಟ್ (Remote Agent): ಕಾರ್ಯವನ್ನು ಸ್ವೀಕರಿಸುವ ಏಜೆಂಟ್. • ಏಜೆಂಟ್ ಕಾರ್ಡ್ (Agent Card): ರಿಮೋಟ್ ಏಜೆಂಟ್ ತನ್ನ ಸಾಮರ್ಥ್ಯಗಳು ಮತ್ತು ಅಥೆಂಟಿಕೇಶನ್ ಅಗತ್ಯತೆಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುವ ಒಂದು JSON ಫೈಲ್.

ಏಜೆಂಟ್ ಕಾರ್ಡ್ ಅತ್ಯಂತ ಪ್ರಮುಖವಾದ ಭಾಗವಾಗಿದೆ. ಕ್ಲೈಂಟ್ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು ಹೇಗೆ ಅಥೆಂಟಿಕೇಟ್ ಮಾಡಬೇಕೆಂದು ತಿಳಿಯಲು ಮೊದಲು ಈ ಕಾರ್ಡ್ ಅನ್ನು ಓದುತ್ತದೆ.

𝗧𝗵𝗲 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗛𝗼𝗹𝗲𝘀 A2A ಹಲವಾರು ನಿರ್ಣಾಯಕ ಕಾರ್ಯಗಳನ್ನು ಅನುಷ್ಠಾನಕಾರರಿಗೆ (implementer) ಬಿಡುತ್ತದೆ. ನೀವು ಇವುಗಳನ್ನು ನಿರ್ವಹಿಸದಿದ್ದರೆ, ನಿಮ್ಮ ಏಜೆಂಟ್‌ಗಳು ಅಪಾಯಕ್ಕೆ ಸಿಲುಕಬಹುದು.

  • ಕಾರ್ಡ್ ತಂಪರಿಂಗ್ (Card Tampering): ಏಜೆಂಟ್ ಕಾರ್ಡ್ ಅನ್ನು ಸಹಿ ಮಾಡುವುದು ಐಚ್ಛಿಕವಾಗಿದೆ (MAY). ನೀವು ಅದಕ್ಕೆ ಸಹಿ ಮಾಡದಿದ್ದರೆ, ದಾಳಿಕಾರರು ನಿಮ್ಮ ಏಜೆಂಟ್ ಅನ್ನು ದುರುದ್ದೇಶಪೂರಿತ ಸರ್ವರ್‌ಗೆ ತಿರುಗಿಸಬಹುದು.
  • ರಿಪ್ಲೇ ಅಟ್ಯಾಕ್‌ಗಳು (Replay Attacks): ಟೋಕನ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಕ್ಲೈಂಟ್‌ಗೆ ಕಟ್ಟುಹಾಕಲು (bind) A2A ಬಳಿ ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ. ಯಾರಾದರೂ ಬೇರರ್ ಟೋಕನ್ (bearer token) ಕದ್ದರೆ, ಅವರು ನಿಮ್ಮ ಏಜೆಂಟ್ ಆಗಿ ನಟಿಸಬಹುದು.
  • ಪ್ರಿವಿಲೇಜ್ ಎಸ್ಕಲೇಷನ್ (Privilege Escalation): ಅಧಿಕಾರೀಕರಣವನ್ನು (Authorization) ಬಾಹ್ಯ ಮೂಲಸೌಕರ್ಯಗಳಿಗೆ ಬಿಡಲಾಗಿದೆ. ನೀವು ಪ್ರತಿ ಕೌಶಲ್ಯಕ್ಕೆ (per-skill) ತಪಾಸಣೆಯನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸದಿದ್ದರೆ, "ಕೇವಲ ಓದುವ" (read-only) ಏಜೆಂಟ್ "ಬರೆಯುವ" (write) ಪ್ರವೇಶವನ್ನು ಪಡೆಯಬಹುದು.
  • ಐಡೆಂಟಿಟಿ ಚೈನಿಂಗ್ (Identity Chaining): ಬಳಕೆದಾರರ ಗುರುತಿನ ಚಲನೆಯು ಏಜೆಂಟ್‌ಗಳ ಸರಪಳಿಯ ಮೂಲಕ ಹೇಗೆ ಸಾಗುತ್ತದೆ ಎಂಬುದನ್ನು A2A ನಿರ್ವಹಿಸುವುದಿಲ್ಲ.

𝗛𝗼𝘄 𝘁𝗼 𝗕𝘂𝗶𝗹𝗱 𝗜𝘁 𝗦𝗮𝗳𝗲𝗹𝘆 ಕೇವಲ ಸ್ಪೆಕ್ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಬೇಡಿ. ನೀವು ಐಚ್ಛಿಕ ನಿಯಮಗಳನ್ನು ಕಡ್ಡಾಯ ನಿಯಮಗಳನ್ನಾಗಿ ಪರಿವರ್ತಿಸಬೇಕು.

• ಯಾವಾಗಲೂ ನಿಮ್ಮ ಏಜೆಂಟ್ ಕಾರ್ಡ್‌ಗಳಿಗೆ ಸಹಿ ಮಾಡಿ. JWS ಮತ್ತು JCS ಬಳಸಿ. • ಏಜೆಂಟ್-to-ಏಜೆಂಟ್ ಮಾರ್ಗಗಳಿಗಾಗಿ mTLS ಬಳಸಿ. ಇದು ಟೋಕನ್ ಕಳ್ಳತನವು ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಅಪಾಯಕ್ಕೆ ತಳ್ಳದಂತೆ ತಡೆಯುತ್ತದೆ. • ನಿಮ್ಮ API ಗೇಟ್‌ವೇಯಲ್ಲಿ ಪ್ರತಿ ಕೌಶಲ್ಯದ ಅಧಿಕಾರೀಕರಣವನ್ನು (per-skill authorization) ಕಡ್ಡಾಯಗೊಳಿಸಿ. • ರಿಪ್ಲೇ ಅಟ್ಯಾಕ್‌ಗಳನ್ನು ತಡೆಯಲು ಸೆಂಡರ್-ಕನ್‌ಸ್ಟ್ರೈನ್ಡ್ ಟೋಕನ್‌ಗಳನ್ನು (sender-constrained tokens - ಉದಾಹರಣೆಗೆ DPoP) ಬಳಸಿ.

A2A ಎಂಬುದು ಕೇವಲ ಪೈಪ್‌ಲೈನ್‌ ಇದ್ದಂತೆ. ಭದ್ರತೆಯು ಅದರ ಮೂಲಕ ಹರಿಯುವ ನೀರಿನಿಂದ ಬರುತ್ತದೆ. ಲೋಪದೋಷಗಳನ್ನು ತುಂಬಲು SPIFFE ಅಥವಾ Identity Chaining ನಂತಹ ಸಾಬೀತಾದ ಮಾನದಂಡಗಳನ್ನು ಬಳಸಿ.

Source: https://dev.to/kanywst/a2a-protocol-auth-taken-apart-why-the-spec-is-thin-and-where-that-leaves-holes-22ii

Optional learning community: https://t.me/GyaanSetuAi