Khóa AI agent bị cô lập vẫn hoạt động lâu sau khi dự án kết thúc

Khi các tác nhân trí tuệ nhân tạo (AI agents) trở nên phổ biến trong quy trình phát triển, chúng thường để lại các khóa quản lý danh tính và truy cập (IAM) đang hoạt động rất lâu sau khi nhiệm vụ của chúng hoàn tất. Điều này tạo ra một lỗ hổng bảo mật đáng kể, nơi các thông tin đăng nhập hợp lệ tồn tại mà không có chủ sở hữu hay mục đích sử dụng. Phân tích gần đây chỉ ra cách những khóa bị cô lập này có thể tồn tại trong nhiều tháng, mang đến cho kẻ tấn công một điểm xâm nhập tiềm năng vào môi trường đám mây.

Chuyện gì đã xảy ra

Một kịch bản giả định nhưng mang tính đại diện minh họa rõ ràng vấn đề cốt lõi: một người dùng IAM tên là _research-agent-2 giữ một khóa truy cập được tạo từ mười bốn tháng trước. Khóa này lần cuối được sử dụng là mười một tháng trước, nhưng vẫn còn hoạt động. Dự án mà nó hỗ trợ đã đóng cửa, và nhân viên phê duyệt việc tạo khóa không còn làm việc cho công ty nữa. Khác với nhân viên con người sẽ kích hoạt quy trình offboarding khi nghỉ việc, các AI agent đã hoàn thành nhiệm vụ đơn giản là ngừng chạy, để lại thông tin đăng nhập của chúng ở trạng thái "limbo" (chờ xử lý).

Vấn đề vòng đời này không phải do sự bất cẩn mà là do khoảng trống cấu trúc trong cách quản lý danh tính phi con người. Các khóa truy cập người dùng AWS IAM không tự động hết hạn. Do đó, một khóa bị lãng quên vẫn có giá trị vô thời hạn cho đến khi ai đó vô hiệu hóa hoặc xóa thủ công. Open Web Application Security Project (OWASP) đã xếp hạng việc offboarding không đúng cách là rủi ro hàng đầu trong Top 10 năm 2025 dành cho danh tính phi con người, nhấn mạnh sự cần thiết phải thu hồi các tài sản không sử dụng và chỉ định chủ sở hữu chịu trách nhiệm cho những tài sản còn lại.

Tính cấp bách của vấn đề này được nhấn mạnh bởi tốc độ của các cuộc tấn công hiện đại. Vào tháng 9 năm 2026, GreyNoise đã ghi nhận một chiến dịch tấn công do AI điều phối nhắm vào các máy chủ PaperCut. Kẻ tấn công đã chuyển từ một workspace trống sang thực thi mã từ xa trong vòng chưa đầy bốn giờ. Sau khi khởi động, chiến dịch này đã xâm phạm ít nhất mười một tổ chức chỉ trong hai mươi sáu giây. Mặc dù cuộc tấn công cụ thể này không sử dụng các khóa AWS IAM bị bỏ rơi, nó chứng minh cách nhanh chóng quyền truy cập bị lộ có thể trở nên hữu ích cho đối thủ. Các quy trình kiểm kê và thu hồi chậm chạp là hoàn toàn không đủ trong bối cảnh này.

Chi tiết quan trọng

• Các khóa truy cập người dùng AWS IAM không có ngày hết hạn tự động và vẫn có giá trị cho đến khi bị thu hồi thủ công.
• OWASP’s 2025 Top 10 for non-human identities xếp hạng việc offboarding không đúng cách là rủi ro chính.
• Một báo cáo của GreyNoise từ tháng 9 năm 2026 cho thấy một cuộc tấn công do AI điều khiển đã xâm phạm mười một tổ chức trong 26 giây.
• CloudQuery có thể đồng bộ hóa các báo cáo thông tin đăng nhập AWS IAM để giúp xác định các khóa không được sử dụng trong hơn 90 ngày.
• Cài đặt thời gian tồn tại (TTL) của môi trường có thể giúp quản lý thông tin đăng nhập dùng một lần nhưng không đảm bảo thu hồi ngay lập tức nếu quá trình hủy bỏ thất bại.
• Các khóa truy cập tài khoản Root yêu cầu kiểm toán riêng biệt, khẩn cấp và về cơ bản không nên tồn tại.

Bối cảnh

Danh tính phi con người đề cập đến các tài khoản dịch vụ, bot và AI agent tương tác với cơ sở hạ tầng đám mây. Không giống như người dùng con người, các thực thể này không có các sự kiện luân chuyển tự nhiên như nghỉ việc hoặc về hưu. Thông tin đăng nhập của chúng, chẳng hạn như khóa truy cập hoặc token, thường được cấp cho các nhiệm vụ cụ thể nhưng thiếu cơ chế quản lý vòng đời tích hợp sẵn. Khi nhiệm vụ kết thúc, thông tin đăng nhập có thể vẫn hoạt động nếu không được gỡ bỏ một cách rõ ràng.

Việc kiểm kê các danh tính này gặp khó khăn vì các nhà cung cấp đám mây không phải lúc nào cũng theo dõi chính xác agent nào đã sử dụng tài khoản. Việc tương quan hoạt động với nhật ký kiểm toán và chủ sở hữu được chỉ định là cần thiết để xác định xem một khóa có còn cần thiết hay không. Ngoài ra, mặc dù các nền tảng triển khai có thể thực thi chính sách trong quá trình tạo cơ sở hạ tầng, chúng không phải lúc nào cũng kiểm soát được các thông tin đăng nhập được tạo qua console hoặc script bên ngoài. Sự khác biệt giữa danh tính triển khai và thông tin đăng nhập được cấp phức tạp hóa các nỗ lực quản trị.

Tại sao điều này quan trọng

Đối với các đội ngũ vận hành phần mềm riêng, các khóa bị cô lập đại diện cho một nợ bảo mật thầm lặng. Một máy ảo bị lãng quên gây ra chi phí tài chính, nhưng một thông tin đăng nhập bị lãng quên cấp quyền truy cập tiềm năng vào dữ liệu và hệ thống nhạy cảm. Kẻ tấn công không cần biết một khóa có bị cô lập hay không để khai thác nó; họ chỉ cần nó còn hợp lệ. Khi các AI agent gia tăng, số lượng danh tính phi con người này sẽ tăng lên, làm mở rộng bề mặt tấn công nếu không áp dụng quản trị phù hợp.

Kiểm toán thủ công hàng năm là không đủ trước tốc độ của các cuộc tấn công tự động. Các đội ngũ cần khả năng hiển thị liên tục về việc sử dụng thông tin đăng nhập. Nếu không có các truy vấn và chính sách tự động, các trưởng nhóm bảo mật có thể không biết về các khóa đang hoạt động liên quan đến các dự án đã ngừng. Khoảng trễ giữa việc đóng dự án và thu hồi thông tin đăng nhập tạo ra các cửa sổ dễ bị tổn thương mà các kẻ tấn công tinh vi có thể khai thác nhanh chóng.

Hơn nữa, việc chỉ dựa vào các công cụ infrastructure-as-code là không đủ. Mặc dù các công cụ như Terraform có thể quản lý việc tạo khóa, chúng không tự động thu hồi khóa nếu quá trình hủy bỏ thất bại hoặc nếu các khóa được tạo bên ngoài môi trường được quản lý. Các đội ngũ phải xác minh việc thu hồi một cách chủ động thay vì tin tưởng vào bộ đếm ngược thời gian hoặc script triển khai.

Bạn có thể làm gì

• Chạy các truy vấn SQL trên các báo cáo thông tin đăng nhập IAM đã đồng bộ hóa để tìm các khóa đang hoạt động không được sử dụng trong hơn 90 ngày.
• Triển khai các chính sách phê duyệt trong nền tảng triển khai để chặn việc tạo các thông tin đăng nhập có tuổi thọ dài trong các kế hoạch Terraform hoặc OpenTofu.
• Ưu tiên liên kết OIDC-based federation cho các triển khai để sử dụng thông tin đăng nhập tạm thời hết hạn cùng phiên làm việc.
• Đặt TTL cho môi trường đối với thông tin đăng nhập dùng một lần nhưng xác minh việc thu hồi thực tế thông qua kiểm tra trạng thái.
• Vô hiệu hóa các khóa đáng ngờ trước để giám sát lỗi xác thực trước khi xóa vĩnh viễn chúng.
• Chỉ định chủ sở hữu rõ ràng cho tất cả các danh tính phi con người và ghi lại quyền sở hữu trong kho thông tin đăng nhập của bạn.

Phần kết luận xuất hiện bên dưới.