Bạn nghĩ lỗi trong code chỉ là lỗi? Hãy nhìn lại. Tại DEF CON 34, một nhóm nghiên cứu đã trình diễn một vector tấn công mới, nơi một public Sentry DSN không chỉ là rò rỉ dữ liệu, mà là cánh cửa để chiếm quyền điều khiển AI Agent của bạn. Lỗ hổng? Tôi đã thấy nó từ hôm qua.
Câu chuyện bắt đầu từ một thiết kế tưởng chừng vô hại: Sentry, công cụ theo dõi lỗi phổ biến, cho phép bất kỳ ai gửi dữ liệu lỗi đến một public DSN (Data Source Name) mà không cần xác thực. Điều này là tính năng, không phải lỗi. Nhưng khi các AI Agent lập trình như Claude Code hay Cursor bắt đầu tích hợp MCP (Model Context Protocol) để đọc các issue từ Sentry, hai 'tính năng' này đã giao nhau tạo thành một lỗ hổng chết người. Context? Đây không phải là một cuộc tấn công vào mô hình AI, mà là vào hạ tầng tin cậy mà AI Agent dựa vào.
Core của vấn đề nằm ở chuỗi tấn công 6 bước mà Tenet Security đã phơi bày. Đầu tiên, kẻ tấn công quét các public Sentry DSN trên GitHub. Với khoảng 2,388 tổ chức lộ diện, đây là một bể tấn công khổng lồ. Sau đó, chúng POST một 'error event' độc hại vào Sentry thông qua DSN đó. Khi một nhà phát triển yêu cầu AI Agent của mình debug một lỗi, Agent sẽ đọc issue từ Sentry qua MCP. Tại đây, payload markdown chứa mã độc – một 'fix suggestion' giả mạo – sẽ được Agent coi là lệnh. Agent thực thi lệnh: cài đặt một npm package độc hại. Kết quả? Kẻ tấn công chiếm được AWS keys, GitHub OAuth tokens, npm registry tokens – tất cả những gì cần để kiểm soát toàn bộ hạ tầng của bạn. Đây là một Indirect Prompt Injection kinh điển, nhưng được mở rộng quy mô nhờ vào sự kết hợp của public DSN và MCP.
Sentry đã phản ứng bằng cách triển khai một 'content filter' – một danh sách đen các payload cụ thể. Nhưng tôi gọi đó là 'băng cá nhân cho vết thương đạn bắn'. Audit bị từ chối? Đã biết trước rồi. Mọi filter dạng IoC đều có thể bị bypass bằng cách encode đơn giản. Giải pháp thực sự phải đến từ kiến trúc: MCP cần một cơ chế để phân biệt 'dữ liệu' và 'lệnh', hoặc ít nhất là một lớp 'tin cậy' cho output của tool. agent-jackstop từ Tenet, một bộ công cụ hardening, là bước đi đúng hướng, nhưng nó chỉ giảm bán kính nổ, chứ không giải quyết được gốc rễ: Agent không thể phân biệt được đâu là dữ liệu thật, đâu là mồi nhử.
Contrarian angle? Phần lớn bài viết này sẽ hét lên 'Sentry có lỗi'. Nhưng tôi cho rằng, đây là một thất bại mang tính hệ thống. Cả Sentry, Anthropic (người tạo MCP), và các nhà phát triển AI Agent đều có phần trách nhiệm. Sentry thiết kế một hệ thống không xác thực, AI Agent mặc định tin tưởng mọi dữ liệu từ MCP, và các nhà phát triển vô tình kết nối chúng mà không có lớp bảo vệ. Tuy nhiên, tôi cũng thấy một điểm mù: kết quả '85% thành công' của Tenet được thực hiện trong môi trường có kiểm soát. Trong thế giới thực, nếu nhà phát triển không chủ động yêu cầu Agent debug Sentry, hoặc nếu có quy trình kiểm tra thủ công, tỷ lệ này có thể thấp hơn. Nhưng điều đó không làm giảm tính nghiêm trọng của vấn đề.
Takeaway của tôi rất rõ ràng: Agentjacking không phải là một lỗ hổng đơn lẻ, mà là một dấu hiệu của một vấn đề kiến trúc sâu hơn. Khi chúng ta xây dựng các hệ thống AI tự động, chúng ta đang tạo ra những 'mắt xích yếu' mới trong chuỗi tin cậy. Câu hỏi đặt ra không phải là 'liệu nó có bị khai thác không?', mà là 'khi nào nó bị khai thác trên quy mô lớn?'. Hãy chuẩn bị cho một thế giới nơi mọi external data source của Agent đều là một attack surface tiềm năng.
