Bảo vệ API key và secret khi vận hành AI Agent

Một AI Agent ở mức tích hợp thật thường cầm khá nhiều chìa khóa: khóa gọi nhà cung cấp mô hình, khóa API của CRM, mã truy cập của phần mềm kế toán, token của kênh nhắn tin, mật khẩu tài khoản dịch vụ đọc cơ sở dữ liệu. Ở giai đoạn làm thử, những khóa này hay được dán vào tệp cấu hình, gửi qua tin nhắn cho nhau hoặc tệ hơn là viết thẳng vào system prompt để “agent biết đường gọi”. Khi agent lên môi trường thật, những thói quen đó đi theo và trở thành lỗ hổng khó phát hiện.

Bài viết này nói riêng về vòng đời của secret, tức mọi loại thông tin xác thực máy dùng để gọi máy: khóa API, token, mật khẩu tài khoản dịch vụ, chứng chỉ. Bức tranh bảo mật tổng thể của agent có ở bài bảo mật dữ liệu AI Agent; việc người dùng nào được làm gì qua agent có ở bài phân quyền AI Agent. Ở đây ta đi vào một câu hỏi hẹp hơn: khóa được cất ở đâu, ai và cái gì được chạm vào nó, khi nào thay, và làm gì khi nghi ngờ bị lộ.

1. Vì sao secret của AI Agent dễ lộ hơn phần mềm thông thường

Trong phần mềm thông thường, khóa API chỉ đi qua mã và cấu hình, nơi lập trình viên kiểm soát. Với AI Agent có thêm một vùng mới: ngữ cảnh của mô hình. Mọi thứ đi vào ngữ cảnh đều có thể đi ra theo những đường không ai lường trước: mô hình lặp lại trong câu trả lời, nội dung hội thoại được ghi vào nhật ký, bản ghi được gửi sang nhà cung cấp mô hình, đoạn trích được đưa vào bộ đánh giá chất lượng. Một khóa lọt vào ngữ cảnh một lần có thể xuất hiện ở bốn năm nơi lưu trữ khác nhau.

Agent cũng làm số lượng khóa tăng nhanh. Mỗi công cụ mới thường cần một quyền truy cập mới, mỗi môi trường thử lại cần bộ khóa riêng, và đội triển khai bên ngoài nếu có cũng cần quyền trong giai đoạn xây dựng. Không có quy trình, sau vài tháng doanh nghiệp không còn biết khóa nào đang dùng, khóa nào đã cấp cho ai và khóa nào còn hiệu lực dù dự án đã kết thúc. Nguyên tắc nền tảng của bài này rất đơn giản: mô hình không bao giờ nhìn thấy khóa, còn con người chỉ chạm vào khóa khi thật cần và có dấu vết.

2. Các yếu tố cần thiết kế

1. Secret không bao giờ nằm trong ngữ cảnh mô hình

System prompt, mô tả công cụ, tài liệu trong kho kiến thức, kết quả trả về từ công cụ đều là ngữ cảnh. Khóa không được xuất hiện ở bất kỳ chỗ nào trong số đó. Điểm hay bị bỏ sót là kết quả trả về: một API đối tác trả lỗi kèm nguyên văn yêu cầu, trong đó có tiêu đề xác thực, và lớp công cụ chuyển nguyên lỗi đó cho mô hình. Lớp công cụ cần lọc kết quả trước khi trả cho mô hình, bỏ tiêu đề, bỏ chuỗi có dạng khóa, chỉ giữ thông tin nghiệp vụ.

Tương tự, khi agent cần đọc tài liệu kỹ thuật nội bộ, nên kiểm tra tài liệu đó trước khi nạp vào kho kiến thức. Hướng dẫn cài đặt cũ có dán sẵn token mẫu là nguồn lộ khóa phổ biến, và một khi đã vào kho, khóa đó có thể được trích dẫn cho bất kỳ ai hỏi đúng câu.

2. Lớp công cụ tự gắn khóa lúc gọi

Mô hình chỉ quyết định gọi công cụ nào với tham số nghiệp vụ nào, ví dụ tra đơn theo mã đơn. Lớp thực thi nhận yêu cầu đó, tự lấy khóa tương ứng với công cụ từ kho bí mật, gắn vào yêu cầu gửi đi, rồi trả kết quả đã lọc về cho mô hình. Khóa chỉ sống trong bộ nhớ của lớp thực thi trong thời gian gọi, không ghi ra đâu cả.

Thiết kế này còn có lợi phụ: mô hình không thể bị dẫn dụ dùng khóa của công cụ A để gọi hệ thống B, vì nó không cầm khóa nào. Việc công cụ nào dùng khóa nào được khai báo trong danh mục công cụ, xem bài tool registry cho AI Agent, và lớp thực thi chỉ cấp đúng khóa đó.

3. Kho bí mật tập trung

Vault, hay kho bí mật, là dịch vụ chuyên lưu khóa ở dạng mã hóa, chỉ cấp cho tiến trình hoặc người có quyền, và ghi lại mọi lần đọc. Có thể dùng dịch vụ quản lý bí mật của nhà cung cấp đám mây, công cụ vault tự vận hành, hoặc tính năng biến bí mật của nền tảng triển khai. Lựa chọn cụ thể ít quan trọng hơn ba yêu cầu: khóa được mã hóa khi lưu, quyền đọc được phân theo từng ứng dụng, và có nhật ký truy cập.

Những chỗ không phải là kho bí mật dù rất tiện: tệp cấu hình trong kho mã, bảng tính dùng chung, trang wiki nội bộ, tin nhắn nhóm, biến môi trường viết tay trên máy chủ mà không ai biết ai đã đặt. Khóa nằm ở những chỗ này cần được coi là đã lộ một phần và lên kế hoạch thay.

4. Khóa riêng cho từng môi trường

Môi trường phát triển, môi trường thử và môi trường thật mỗi nơi dùng một bộ khóa riêng, trỏ tới tài khoản riêng ở hệ thống đích nếu hệ thống đó hỗ trợ. Khóa của môi trường thật không bao giờ được dùng trên máy lập trình viên hay trong môi trường thử. Nếu hệ thống đích chỉ có một tài khoản, hãy hỏi nhà cung cấp về tài khoản thử hoặc khóa chỉ đọc trước khi chấp nhận dùng chung.

Lý do không chỉ là bảo mật. Agent trong môi trường thử chạy kịch bản lạ, có lúc gọi lặp nhiều lần; nếu cầm khóa thật, nó có thể gửi tin nhắn thật cho khách thật hoặc tạo đơn thật trong ERP. Tách khóa là cách chắc chắn nhất để thử nghiệm không chạm vào khách.

5. Khóa riêng cho từng công cụ và quyền tối thiểu

Một khóa quản trị dùng chung cho mọi công cụ là cách nhanh nhất để bắt đầu và cách tệ nhất để vận hành. Mỗi công cụ, hoặc ít nhất mỗi nhóm công cụ cùng hệ thống, nên có tài khoản dịch vụ riêng với đúng quyền nó cần: công cụ tra đơn chỉ đọc bảng đơn hàng, công cụ tạo phiếu hỗ trợ chỉ tạo phiếu trong một hàng xử lý nhất định. Khi một khóa lộ, phạm vi thiệt hại chỉ giới hạn ở quyền của khóa đó.

Quyền tối thiểu cần được kiểm chứng chứ không chỉ khai báo. Khi cấp tài khoản dịch vụ, hãy thử gọi một thao tác ngoài phạm vi và xác nhận hệ thống đích từ chối. Nhiều phần mềm có cấu trúc quyền thô, chỉ có “đọc toàn bộ” hoặc “quản trị”; khi đó nên ghi rõ giới hạn này vào hồ sơ rủi ro và cân nhắc thêm lớp kiểm tra tham số ở phía agent.

6. Xoay vòng định kỳ và xoay khẩn

Xoay vòng là thay khóa cũ bằng khóa mới theo lịch, để một khóa lỡ lộ mà không ai biết cũng chỉ dùng được trong thời gian có hạn. Quy trình tốt cho phép hai khóa cùng có hiệu lực trong một khoảng ngắn: cấp khóa mới, cập nhật vào kho bí mật, xác nhận agent đã dùng khóa mới, rồi mới vô hiệu khóa cũ. Làm ngược thứ tự sẽ khiến agent lỗi giữa chừng.

Xoay khẩn là phiên bản rút gọn khi nghi ngờ lộ: vô hiệu khóa cũ ngay, chấp nhận agent gián đoạn ngắn trong lúc cấp khóa mới. Doanh nghiệp nên quyết trước với từng hệ thống xem có chấp nhận gián đoạn đó không, và nếu không thì agent cần thông báo gì cho người dùng trong lúc công cụ tạm ngừng.

7. Phát hiện lộ trong nhật ký, kho mã và hội thoại

Cần có công cụ quét tự động ở ba chỗ. Kho mã: quét mỗi lần gửi mã lên để chặn tệp chứa chuỗi có dạng khóa, kể cả trong lịch sử thay đổi cũ. Nhật ký: quét định kỳ các bản ghi gọi công cụ, bản ghi lỗi và bản ghi hội thoại tìm chuỗi khớp mẫu khóa của các nhà cung cấp đang dùng. Hội thoại: lớp đầu ra của agent kiểm tra câu trả lời trước khi gửi, chặn nếu có chuỗi giống khóa.

Mẫu nhận diện nên dựa vào tiền tố và độ dài đặc trưng của từng loại khóa đang dùng, cộng với danh sách giá trị khóa thật được băm để so khớp mà không lưu nguyên văn. Cách thiết kế nhật ký để có đủ dữ liệu điều tra mà không chứa thông tin nhạy cảm có ở bài nhật ký AI Agent.

8. Thu hồi khi người nghỉ việc hoặc đổi nhà cung cấp

Mỗi khóa trong kho bí mật cần ghi người hoặc đơn vị chịu trách nhiệm và lý do cấp. Khi một kỹ sư rời dự án, những khóa họ từng xem trực tiếp cần được xoay, không chỉ khóa tài khoản cá nhân của họ. Khi hợp đồng với đơn vị triển khai bên ngoài kết thúc, mọi tài khoản dịch vụ và khóa cấp cho đơn vị đó phải được thu hồi theo danh sách đã lập từ đầu.

Đổi nhà cung cấp mô hình hoặc ngừng dùng một phần mềm cũng là thời điểm thu hồi. Khóa của hệ thống đã ngừng dùng thường bị quên vì không còn ai gọi, nhưng nếu tài khoản bên kia vẫn hoạt động thì khóa vẫn có giá trị với kẻ tìm được nó.

3. Quy trình triển khai thực tế

Bước 1: Kiểm kê mọi secret đang tồn tại

Lập danh sách mọi khóa mà các agent và quy trình liên quan đang dùng: tên khóa, hệ thống đích, quyền, môi trường, nơi đang lưu, người cấp, ngày cấp, lần xoay gần nhất. Nguồn để tìm gồm tệp cấu hình, biến môi trường trên máy chủ, kho mã kể cả lịch sử, bảng tính của đội dự án và danh sách tài khoản dịch vụ ở từng hệ thống đích. Khóa tìm thấy ở chỗ không an toàn được đánh dấu cần thay.

Bước 2: Chuyển secret vào kho và gỡ khỏi mã, cấu hình

Đưa từng khóa vào kho bí mật, sửa ứng dụng để đọc khóa từ kho lúc chạy, rồi xóa khóa khỏi tệp cấu hình và biến môi trường cũ. Với khóa từng nằm trong kho mã hoặc tin nhắn, không chỉ xóa mà phải cấp khóa mới, vì bản cũ đã có thể bị sao chép. Đây là lúc tách khóa dùng chung thành khóa riêng theo công cụ và theo môi trường.

Bước 3: Dựng lớp thực thi lấy khóa lúc gọi và lọc kết quả

Sửa lớp thực thi công cụ để lấy khóa từ kho tại thời điểm gọi, gắn vào yêu cầu, và lọc kết quả trả về trước khi đưa cho mô hình. Kiểm tra bằng ca thử cố ý: cho API trả lỗi kèm tiêu đề xác thực, cho tài liệu chứa chuỗi giống khóa, hỏi agent “khóa bạn dùng để gọi CRM là gì” theo nhiều cách diễn đạt. Kết quả mong đợi là không một ký tự nào của khóa xuất hiện trong câu trả lời hay trong nhật ký hội thoại.

Bước 4: Diễn tập xoay vòng và thu hồi khẩn

Chọn một khóa ít rủi ro và chạy thử cả hai quy trình: xoay định kỳ không gián đoạn và xoay khẩn có gián đoạn. Ghi lại từng bước, ai làm, mất bao lâu, agent phản ứng thế nào khi khóa cũ bị vô hiệu. Sau đó áp lịch xoay cho từng nhóm khóa theo mức rủi ro, và đưa quy trình xoay khẩn vào kế hoạch xử lý sự cố. Phần khôi phục dịch vụ sau sự cố lớn hơn có ở bài kế hoạch khôi phục sự cố AI Agent.

4. Ví dụ giả định

Một công ty phân phối thiết bị văn phòng có agent hỗ trợ đại lý tra đơn và công nợ, kết nối ERP và một nền tảng nhắn tin. Khi kiểm kê, đội vận hành phát hiện khóa ERP là tài khoản quản trị, được dán trong tệp cấu hình trên kho mã từ lúc làm thử và vẫn dùng ở môi trường thật. Ngoài ra, khi ERP trả lỗi xác thực, lớp công cụ chuyển nguyên thông báo lỗi cho mô hình, trong đó có một phần chuỗi token.

Công ty cấp hai tài khoản dịch vụ mới ở ERP, một chỉ đọc đơn hàng, một chỉ đọc công nợ, lưu trong dịch vụ quản lý bí mật của nhà cung cấp đám mây đang dùng. Tài khoản quản trị cũ bị đổi mật khẩu và gỡ khỏi mọi cấu hình. Lớp thực thi được sửa để chỉ trả cho mô hình mã lỗi và câu mô tả ngắn. Bộ quét được gắn vào kho mã và chạy hằng ngày trên nhật ký. Khi đơn vị triển khai bên ngoài bàn giao xong, danh sách khóa cấp cho họ được đối chiếu và thu hồi trong cùng buổi nghiệm thu. Ví dụ này là giả định để minh họa quy trình.

5. Rủi ro và giới hạn

• Khóa lọt vào ngữ cảnh qua đường gián tiếp như thông báo lỗi, tài liệu kỹ thuật cũ hoặc kết quả công cụ không được lọc
• Kho bí mật được dựng nhưng vẫn còn bản sao khóa trong tệp cấu hình và biến môi trường cũ
• Hệ thống đích chỉ có quyền thô, khiến quyền tối thiểu không thực hiện được đúng nghĩa
• Quy trình xoay khẩn chưa diễn tập, đến khi cần thì làm agent ngừng lâu hơn dự kiến

Quản lý secret tốt không ngăn được mọi cuộc tấn công. Nếu máy chủ chạy agent bị chiếm quyền, kẻ tấn công có thể đọc khóa ngay trong bộ nhớ lúc agent dùng. Mục tiêu thực tế là thu hẹp phạm vi của từng khóa, rút ngắn thời gian một khóa lộ còn dùng được, và có dấu vết để biết khóa nào đã bị đọc khi nào.

6. Phân chia trách nhiệm vận hành

Đội vận hành nền tảng sở hữu kho bí mật, cấu hình quyền đọc theo ứng dụng và lịch xoay vòng. Đội phát triển agent chịu trách nhiệm không đưa khóa vào mã, cấu hình hay ngữ cảnh mô hình, và viết lớp lọc kết quả công cụ. Quản trị viên từng hệ thống đích, như CRM hay ERP, cấp tài khoản dịch vụ với quyền đúng phạm vi và xác nhận khi thu hồi. Người phụ trách an toàn thông tin duyệt danh sách khóa có rủi ro cao, theo dõi cảnh báo từ bộ quét và là người ra quyết định xoay khẩn.

Khi làm việc với đơn vị triển khai bên ngoài, hợp đồng và biên bản bàn giao nên có danh sách khóa đã cấp cho họ và cam kết thu hồi khi kết thúc. Đơn vị bên ngoài không nên giữ bất kỳ khóa nào của môi trường thật sau khi bàn giao, trừ khi có hợp đồng vận hành tiếp và quyền đó được ghi rõ.

7. Chỉ số nên theo dõi

• Số khóa trong kho bí mật so với số khóa tìm thấy ngoài kho qua các lần quét
• Số khóa quá hạn xoay vòng theo lịch đã đặt, tách theo mức rủi ro
• Số lần bộ quét phát hiện chuỗi giống khóa trong kho mã, nhật ký hoặc câu trả lời của agent
• Thời gian từ khi phát hiện nghi ngờ lộ đến khi khóa cũ bị vô hiệu

Chỉ số đáng lo nhất không phải là số lần phát hiện, vì phát hiện nhiều có thể nghĩa là bộ quét đang làm tốt. Đáng lo là khóa tìm thấy ngoài kho mà không ai biết là của ai, và thời gian thu hồi kéo dài vì không có người đủ quyền ra quyết định.

8. Checklist trước khi vận hành

• Không có khóa nào trong system prompt, mô tả công cụ, kho kiến thức hay kết quả trả về cho mô hình
• Mọi khóa của môi trường thật nằm trong kho bí mật và đã gỡ khỏi mã, tệp cấu hình
• Mỗi môi trường và mỗi nhóm công cụ có khóa riêng với quyền đã được kiểm chứng
• Bộ quét đang chạy trên kho mã, nhật ký và đầu ra của agent
• Quy trình xoay định kỳ và xoay khẩn đã diễn tập ít nhất một lần
• Danh sách khóa cấp cho người và đơn vị bên ngoài có ngày thu hồi dự kiến

9. Câu hỏi thường gặp

Vì sao không được đưa API key vào prompt dù prompt chỉ chạy phía máy chủ? Mọi thứ trong ngữ cảnh mô hình đều có thể bị lặp lại trong câu trả lời, bị ghi vào nhật ký hội thoại hoặc bị gửi tới nhà cung cấp mô hình. Chỉ cần một câu hỏi khéo hoặc một tài liệu chứa chỉ dẫn độc hại là khóa có thể lộ ra. Mô hình không cần biết khóa để gọi công cụ, nên không có lý do gì để đặt khóa vào đó.

Doanh nghiệp nhỏ có cần dùng vault riêng không? Không nhất thiết phải tự dựng. Dịch vụ quản lý bí mật của nhà cung cấp đám mây đang dùng hoặc tính năng biến bí mật của nền tảng triển khai thường đủ cho quy mô nhỏ. Điều quan trọng là khóa không nằm trong mã nguồn, tệp cấu hình gửi lên kho mã hay bảng tính dùng chung, và có người biết khóa nào đang ở đâu.

Bao lâu nên xoay vòng khóa một lần? Không có một chu kỳ đúng cho mọi khóa. Khóa có quyền ghi hoặc chạm dữ liệu khách nên xoay thường xuyên hơn khóa chỉ đọc dữ liệu công khai. Quan trọng hơn chu kỳ là quy trình xoay đã được diễn tập, để khi có nghi ngờ lộ khóa thì xoay ngay trong ngày mà không làm agent ngừng chạy.

Khi phát hiện khóa bị lộ trong nhật ký thì làm gì trước? Thu hồi hoặc vô hiệu hóa khóa trước, sau đó mới cấp khóa mới và cập nhật vào kho bí mật. Tiếp theo xóa hoặc che khóa trong nhật ký, xác định ai đã có quyền đọc nhật ký đó, và kiểm tra nhật ký của hệ thống đích xem khóa có bị dùng bất thường trong khoảng thời gian bị lộ không.

Kết luận

Với AI Agent, quản lý secret xoay quanh một ranh giới: mô hình quyết định làm gì, còn lớp thực thi cầm khóa để làm. Giữ khóa ngoài ngữ cảnh mô hình, cất trong kho bí mật, tách theo môi trường và công cụ với quyền tối thiểu, xoay vòng theo lịch đã diễn tập, quét lộ ở mọi nơi khóa có thể rơi vào, và thu hồi đúng lúc khi người hoặc nhà cung cấp rời đi. Những việc này không phức tạp, nhưng phải được làm từ trước khi agent chạm hệ thống thật.

Trao đổi với Naventic để rà soát cách lưu và cấp khóa cho các AI Agent đang tích hợp. Đọc thêm: AI Workflow Automation.