AI coding agents đang chạy trên máy của bạn — bạn có biết chúng đang làm gì không?

Nghe bài viết:

69c573c9ac4045d98a554ce8_69c11b05a4c8c2407319282b_runtime%20security%20for%20ai%20coding%20agents_%20protecting%20ai-assisted%20development-2-260417213519

Các tác nhân lập trình AI hiện đang chạy trên laptop của developer và bên trong pipeline CI/CD ở mọi ngành. Chúng viết mã, thực thi lệnh, đọc file và tạo kết nối mạng — thường là khi developer không trực tiếp quan sát. Không giống hầu hết các phần mềm khác trên cùng máy, hiện chưa có lớp phát hiện nào hiểu được hành vi “bình thường” của agent là gì, chưa nói đến việc nhận diện tấn công ở cấp độ này.

Nhóm nghiên cứu mối đe dọa Sysdig đã bắt đầu xây dựng lớp này. Bài viết này trình bày những gì chúng tôi phát hiện và lý do tại sao bảo mật runtime là lớp nền tảng trong việc bảo vệ các công cụ này.

Những gì chúng tôi quan sát được

Chúng tôi muốn hiểu cần gì để phát hiện các agent này — và chúng trông như thế nào dưới góc nhìn của người phòng thủ. Chúng tôi bắt đầu từ các đặc điểm bề mặt, sau đó thiết lập môi trường chạy ba agent lớn và ghi lại hành vi của chúng ở cấp syscall bằng Sysdig và Falco.

Ở mức tổng quan, các đặc điểm liên quan đến bảo mật khá rõ ràng. Mỗi agent lưu trạng thái nhạy cảm ở vị trí dễ đoán — một thư mục cấu hình trong thư mục người dùng (~/.claude/, ~/.gemini/, ~/.codex/) chứa token API, dữ liệu phiên và cấu hình. Các thư mục này có thể được truy cập bởi bất kỳ tiến trình nào chạy dưới cùng user. Agent thường hoạt động với toàn bộ quyền hệ điều hành của user, không có giới hạn nào ngoài các kiểm soát an toàn ở cấp ứng dụng. Nói cách khác, phán đoán của agent — và sandbox nội bộ nếu có — là rào chắn duy nhất giữa một prompt và một thao tác hệ thống có quyền cao.

Để vượt qua các đặc điểm bề mặt, chúng tôi đi sâu xuống lớp syscall. Ở đây, một bức tranh hoàn toàn khác xuất hiện — thứ không thể thấy từ giao diện hay log của agent.

Ba agent, ba môi trường chạy

Dù cùng chia sẻ kiến trúc vòng lặp agent, mỗi agent có “dấu vân tay tiến trình” khác nhau. Claude Code chạy dưới dạng binary Bun; Gemini CLI chạy như script Node.js; còn Codex CLI là binary Rust độc lập. Những khác biệt này khiến việc nhận diện agent theo cách chung trở nên không khả thi — buộc phải ánh xạ chi tiết từng cách cài đặt để phát hiện chính xác.

Vòng lặp agent

Cả ba agent đều hoạt động theo một mô hình lặp. Agent duy trì kết nối liên tục với API LLM. Khi mô hình quyết định sử dụng công cụ — chạy lệnh, đọc file, gọi mạng — agent sẽ phân tích yêu cầu, tạo một shell tạm để thực thi, thu kết quả và gửi lại API. Chu trình này lặp lại cho đến khi có kết quả cuối cùng.

Ở cấp syscall, điều này tạo ra một chuỗi hành vi lặp lại rất đặc trưng:

Trong một phiên ghi lại, chúng tôi thấy 5 vòng lặp trong 10 giây — mỗi vòng tạo một shell bash tạm, chạy một lệnh rồi thoát. Developer chỉ thấy một kết quả. Kernel thấy 64 sự kiện execve, nhiều kết nối HTTPS và cây tiến trình nhiều tầng.

Tại sao đây là một bài toán bảo mật hoàn toàn khác

Agent AI không chỉ là “một ứng dụng nữa cần theo dõi”. Nó khác biệt căn bản so với bảo mật endpoint truyền thống.

Agent có lỗ hổng mang tính cấu trúc

Các agent dựa trên LLM có một hạn chế cốt lõi: không có sự tách biệt rõ ràng giữa chỉ dẫn và dữ liệu. Cùng một kênh ngôn ngữ tự nhiên vừa chứa ý định của người dùng, vừa chứa nội dung không đáng tin như file repo, thông báo lỗi hay tài liệu phụ thuộc. Nếu kẻ tấn công chèn nội dung vào bất kỳ nguồn nào agent đọc, họ có thể điều hướng hành vi của agent.

Prompt injection không cần quyền cao, không cần khai thác lỗ hổng — chỉ cần một comment độc hại trong code hoặc README bị nhiễm là đủ để khiến agent lộ dữ liệu hoặc thay đổi cấu hình.

Sandbox nội bộ không đủ tin cậy

Các agent đều có cơ chế an toàn như yêu cầu quyền, sandbox file hay quy trình phê duyệt. Nhưng chúng đều chạy trong chính tiến trình của agent. Điều này có nghĩa: nếu agent bị điều khiển, nó có thể tự vô hiệu hóa các cơ chế này.

Đây không phải lỗi triển khai, mà là vấn đề về ranh giới tin cậy: sandbox ở cấp ứng dụng không thể bảo vệ khỏi mối đe dọa cùng cấp quyền.

Từ chương trình xác định sang tác nhân theo prompt

Phần mềm truyền thống có logic cố định — có thể dự đoán hành vi. Nhưng agent AI thì không. Nó có thể đọc bất kỳ file, chạy bất kỳ tiến trình, gọi bất kỳ API nào mà user có quyền.

Hành vi của nó không bị giới hạn bởi code mà bởi prompt — thứ thay đổi liên tục. Vì vậy, agent giống người dùng tương tác hơn là phần mềm truyền thống.

Tại sao cần quan sát ở cấp kernel

Với các đặc điểm trên — dễ bị prompt injection, sandbox không đủ mạnh, hành vi khó dự đoán — việc giám sát cần diễn ra ở cấp mà agent không kiểm soát được.

Giải pháp là theo dõi ở cấp syscall (eBPF). Nó ghi lại toàn bộ sự kiện hệ thống, độc lập với ứng dụng, và cho phép truy vết tiến trình. Các mẫu tấn công như reverse shell, đánh cắp dữ liệu hay leo thang đặc quyền vẫn có thể phát hiện ở đây.

Ánh xạ mối đe dọa thành hành vi quan sát được

Mô hình đe dọa cho agent AI vẫn đang hình thành. Chúng tôi xác định 4 hành vi có thể quan sát được — mỗi hành vi tương ứng với một quy tắc phát hiện.

Nguyên tắc quan trọng: phát hiện dựa trên hành vi, không phải phương thức tấn công. Dù là prompt injection hay tấn công MCP, ở cấp syscall chúng có thể giống nhau — ví dụ đọc file trái phép.

Điều khiển agent bằng prompt injection

Đây là dạng tấn công phổ biến nhất. Kẻ tấn công chèn chỉ dẫn vào nội dung mà agent xử lý.

Chúng tôi không phát hiện injection trực tiếp (nó xảy ra trong LLM), mà phát hiện hậu quả: agent đọc file nhạy cảm, tạo tiến trình lạ, hoặc mở kết nối mạng.

Các nghiên cứu đã ghi nhận nhiều trường hợp tấn công thực tế, bao gồm đánh cắp dữ liệu và thực thi lệnh từ xa.

Đánh cắp thông tin cấu hình agent

Thư mục cấu hình chứa token API — mục tiêu dễ dàng cho bất kỳ tiến trình nào cùng user.

Chúng tôi phát hiện truy cập trái phép vào các thư mục này từ tiến trình không thuộc agent.

Việc đánh cắp token có thể dẫn đến kiểm soát API LLM hoặc dùng làm kênh điều khiển từ xa.

Vượt qua cơ chế an toàn

Các agent có thể chạy với cờ dòng lệnh tắt kiểm soát an toàn. Nếu bị lợi dụng, agent sẽ chạy không kiểm soát.

Phát hiện rất đơn giản: kiểm tra tham số dòng lệnh khi khởi chạy.

Phát hiện sự tồn tại của agent

Trước khi bảo mật, cần biết agent có tồn tại hay không. Việc phát hiện cài đặt giúp xây dựng danh sách tài sản.

Xây dựng hệ thống phát hiện agent

Chúng tôi không cố hiểu agent “muốn làm gì”, mà coi nó như một tiến trình có quyền cao. Nguyên tắc: xác định hành vi không nên xảy ra — và phát hiện khi nó xảy ra.

Thách thức lớn nhất là nhận diện agent trong hệ thống — vì chúng không tự khai báo. Cần dựa vào đường dẫn cài đặt và cây tiến trình.

Sau khi nhận diện được, các quy tắc khá đơn giản: cài đặt, truy cập trái phép, đọc file nhạy cảm, vượt kiểm soát an toàn.

Tương lai: bề mặt tấn công mở rộng

Khi hệ thống nhiều agent kết nối với nhau, rủi ro tăng mạnh. Một prompt injection có thể lan qua nhiều luồng công việc.

Hệ sinh thái MCP đang trở thành chuỗi cung ứng mới — server bị xâm nhập có thể trở thành kênh tấn công liên tục.

Việc phát hiện cần tiến hóa: hiểu hành vi bình thường của agent và phát hiện sai lệch.

Vì về bản chất, agent chính là một tiến trình có quyền cao — và cần được giám sát như vậy.

Phụ lục: các framework phân tích mối đe dọa

MITRE ATLAS

MITRE ATLAS mở rộng ATT&CK cho hệ thống AI với nhiều kỹ thuật tấn công đặc thù.

OWASP LLM Top 10

OWASP LLM xác định các rủi ro lớn như prompt injection và quyền quá mức.

Google SAIF

Google SAIF nhấn mạnh việc giám sát hành vi AI là bắt buộc trong bảo mật hiện đại.