Đừng cho AI agent quyền root: để nó mở PR đề xuất trạng thái hệ thống kế tiếp
Maintainer của Kairos cho rằng agent không nên có root trên production, và AGENTS.md không làm hệ thống phi tất định an toàn. Bài này áp ý tưởng vào Terraform plan, GitOps và bước approve trong pipeline.
Hai giờ sáng, bạn đang on-call. Alert nổ, và một agent có SSH với quyền root vào node xử lý xong trong vài phút. Dashboard xanh trở lại. Sáng hôm sau, postmortem hỏi: nó đã sửa những gì, theo thứ tự nào, và làm sao tái hiện lại?
Tình huống giả định này chạm đúng vấn đề mà Mauro Morales, CNCF Ambassador và maintainer của hệ điều hành Kairos, nêu trong bài đăng trên CNCF Blog ngày 8/10/2026.
Ông thừa nhận trao root cho agent rất "đã". Chính ông từng chuyển một dịch vụ ở nhà từ MacBook sang máy Linux mà không có downtime, chỉ nhờ cấp quyền superuser cho agent. Nhưng "làm được" không có nghĩa là "nên làm" trên production.
Luận điểm chính: vấn đề là khả năng tái hiện, không chỉ là lỗi
Morales không tập trung vào xác suất agent làm hỏng hệ thống. Ông nhắc rằng API cũng có bug và cũng fail. Thứ ông quan tâm là reproducibility: biết cái gì đã thay đổi, và ai (hay cái gì) đã thay đổi nó.
Từ đó có hai ý quan trọng với dân vận hành:
AGENTS.md không phải hàng rào an toàn. Nếu bạn cấp root rồi trông chờ một file hướng dẫn viết kỹ sẽ ngăn được lỗi không thể khôi phục, theo ông là đang tự lừa mình. Hệ thống dù giỏi đến đâu vẫn phi tất định (nondeterministic), nên không ai đảm bảo được kết quả.
Lý do không cho người root tự do trên production cũng áp dụng cho agent. Ông kết luận thẳng: "Period."
Mô hình đề xuất: agent quan sát, hệ thống mới đổi trạng thái
Lúc runtime, agent có thể inspect hệ thống. Thay đổi ở base system được viết thành một định nghĩa có version, build thành image mới, rồi hệ thống mới dùng image đó. Runtime không còn là nơi "ứng biến" trạng thái kế tiếp. Nó chỉ chạy một trạng thái đã được tạo ra ở nơi khác.
Nơi khác ấy là cái Morales gọi là software factory: source control, review, CI, test, build image, ký (signing), release và deploy. Khi provenance của source, build và deploy được giữ lại, bạn có thể lần ngược sự cố về đúng commit và image đã gây ra nó. Ông không hứa hết lỗi, vì lỗi vẫn lọt dù là người hay agent làm. Nhưng ít nhất có đường truy vết.
Bài phân biệt hai loại tự chủ:
Self-healing: chọn trong các phản ứng đã được cho phép trước, như restart, replace hay rollback một workload.
Self-improvement: đề xuất một trạng thái chưa được cho phép, nên bắt buộc đi qua software factory.
Ví dụ trong bài: lỗi căn section ở go-ukify
Khi QA thăm dò các image Kairos Trusted Boot, một agent giúp lần ra nguyên nhân các lần boot đứng nhiều phút và vòng lặp reset firmware. Thủ phạm là go-ukify, library mà AuroraBoot dùng để dựng UKI. Nó căn section PE theo ranh giới 512 byte, trong khi systemd stub cần 4 KB.
Nhóm đã sửa library, phát hành go-ukify v0.5.2, cập nhật AuroraBoot và nhờ agent kiểm chứng lại image. Kairos và Hadron nhờ vậy nhận bản sửa. Agent giúp chẩn đoán và kiểm chứng, không ai sửa trực tiếp trên máy đang chạy.
Immutable không phải sandbox
Host immutable giúp việc cài hay nâng cấp package hệ thống rời khỏi vòng đời runtime thông thường. Bài nêu các công nghệ hỗ trợ host image-based theo nhiều cách: bootc, Flatcar Container Linux và Kairos. Hadron, base OS tối giản của nhóm Kairos, thậm chí không có package manager. Nhưng tác giả cảnh báo:
Phần mềm agent thường không đến từ distro mà từ npm, binary độc lập hoặc container image.
Harness chạy local như Claude Code hay Codex vẫn có thể nối với host qua filesystem, credentials, tool, socket, mạng hoặc quyền được cấp trong phiên.
Immutability không bảo vệ máy khỏi tiến trình có quyền không giới hạn với host, kernel hoặc disk.
Agent vẫn tác động được lên mọi chỗ nó có quyền ghi. Base system được bảo vệ không có nghĩa cả máy được bảo vệ.
Cách giải của tác giả là coi agent là một workload. Mỗi phiên chạy trong môi trường ngắn hạn, tạo ra cho phiên đó và bỏ đi sau khi xong.
Ranh giới thực thi phải theo threat model. Pod thường, dùng chung kernel host, có thể đủ cho agent phạm vi hẹp. Agent chạy code không tin cậy hoặc cần nhiều quyền thì có thể cần sandboxed pod hoặc VM.
Áp dụng vào pipeline của bạn (nhận định của chúng tôi)
Bài của Morales nói ở tầng hệ điều hành và không đề cập Terraform hay GitOps. Phần dưới là gợi ý của chúng tôi khi áp cùng nguyên tắc vào công việc IaC hằng ngày.
Cho agent quyền đọc, không cho quyền ghi lên production. Nó xem log, metric, trạng thái cluster để chẩn đoán. Tách credential của agent khỏi credential của người và của pipeline để audit biết đúng "ai" làm gì.
Đầu ra của agent là thay đổi trong Git. Sửa file Terraform, manifest Kubernetes hay định nghĩa image rồi mở pull request, thay vì chạy lệnh trên máy đích.
Để pipeline chạy plan và đăng kết quả vào PR. Output của terraform plan là "diff của trạng thái kế tiếp" mà người duyệt cần đọc.
Bắt buộc có người approve trước khi apply. Với thay đổi agent tự đề xuất (self-improvement), đây là cổng không được bỏ qua.
Để GitOps controller hoặc pipeline là bên duy nhất apply. Runtime chỉ thực thi trạng thái đã merge.
Giữ provenance. Khi có sự cố, lần về commit và image, rồi rollback bằng cách quay về trạng thái trước đó trong Git.
Phần self-healing chỉ nên gồm các hành động đã được cho phép từ trước, như restart hoặc rollback một workload, đúng như phân loại trong bài.
Prompt mẫu (gợi ý của chúng tôi)
Bạn đang chẩn đoán sự cố: <mô tả triệu chứng, đã ẩn secret>.
Bạn chỉ có quyền đọc. KHÔNG chạy lệnh thay đổi hệ thống.
Hãy:
Tóm tắt giả thuyết nguyên nhân và bằng chứng (log/metric đã cung cấp).
Đề xuất thay đổi dưới dạng diff cho <file IaC/manifest>.
Nêu rủi ro, cách kiểm tra sau khi áp dụng, và cách rollback.
Ghi rõ điều bạn chưa chắc chắn.
Kiểm tra trước khi áp dụng
Đọc kỹ plan hoặc dry-run: có resource nào bị destroy hay recreate ngoài dự kiến không?
Chạy linter và scanner có sẵn trong pipeline lên diff do agent tạo. Đối xử với nó như code của một contributor mới.
Nhờ người hiểu hệ thống review, đặc biệt phần IAM, network và dữ liệu.
Không dán secret vào công cụ AI: API key, nội dung state file, kubeconfig, token. Che hoặc thay bằng placeholder trước khi đưa log cho agent.
Hạn chế cần nói thẳng
Tác giả thừa nhận ông không có câu trả lời chung: đáp án tùy hệ thống, và không có đáp án một cỡ cho mọi môi trường cloud native.
Ông là maintainer của Kairos và đã tự công bố điều này. Ông giữ lập luận ở mức kiến trúc thay vì quảng bá một sản phẩm.
Controlled state transition không cho mọi bảo đảm mà một agent tự chủ cần. Nó cho một đường rõ ràng từ ý định đến trạng thái hệ thống đã được review và tái hiện được, thứ mà root shell không có.
Trong phần nội dung chúng tôi đọc được, bài không có số liệu đo hiệu quả. Đây là lập luận kiến trúc kèm một ví dụ thực tế, chưa phải kết quả được kiểm chứng độc lập.
Kết
Hãy dùng một câu hỏi để soi pipeline của mình: nếu agent đổi hệ thống lúc 2 giờ sáng, bạn có diff để đọc, người để duyệt và commit để rollback không? Nếu chưa, hãy chuyển agent từ vị trí "người gõ lệnh" sang "người viết đề xuất" trước khi tăng thêm quyền cho nó.