Nút Yes không phải là chính sách

Đến lần hỏi thứ 40, không ai còn đọc nữa. "Cho phép chạy lệnh này?" thành phản xạ, và người tự chạy agent có quyền ghi tệp hay chi tiền đã âm thầm thành con dấu cho chính máy của mình.

Hộp thoại hỏi là cửa cuối khá tốt, nhưng là chỗ rất tệ để giữ luật. Bài này nói về việc đưa luật ra nơi đọc được, review được, diff được, và về các tệp mang luật đó, vốn mục nhanh hơn người ta nghĩ.

Nút Yes thực sự ghi lại điều gì

Khi cách kiểm soát duy nhất là "hỏi người dùng từng lần", có ba thứ hỏng.

• Luật chỉ tồn tại trong khoảnh khắc đó. Không có bản ghi nào cho biết thứ Ba tuần trước agent được phép làm gì. Chỉ có một lần chạy mà ai đó đã bấm.
• Sự chú ý là ngân sách có hạn. Hộp thoại quan trọng trông y hệt bốn mươi hộp thoại vô hại. "Chạy lệnh này" không cho biết lần này là lệnh xoá.
• Không có gì hiện trong diff. Bạn hay đồng đội mở rộng quyền của agent thì không buổi review nào thấy. Quyền thay đổi mà không xuất hiện trong pull request nghĩa là chưa ai duyệt nó.

Một bài trên Medium (Google Cloud Community, 22/10) đi cùng hướng ngay trong tiêu đề: đừng bấm Yes nữa, hãy đưa chính sách quyền của agent vào trong repository. Chúng tôi lấy hình dạng của lập luận đó, không lấy một cách triển khai cụ thể, rồi áp vào những gì một Soot có hôm nay.

Luật là câu nói về ai, làm gì, trên cái gì

Đơn vị hữu ích không phải "có được chạy lệnh không". Nó là một câu ngắn gồm ba phần:

• ai: agent nào, trong việc nào;
• làm gì: tool nào, động từ nào. Đọc số dư khác với gửi tiền;
• trên cái gì: đường dẫn, host, tài khoản hay người nhận nào, viết ra từ trước khi chạy.

Đây là hình dạng, chỉ để minh hoạ. Đây không phải định dạng tệp của Soot, chỉ là mức chi tiết đáng viết ra:

# agent-policy.yaml (minh hoạ)
agent: release-notes
allow:
  - tool: read_file
    paths: ["docs/**", "CHANGELOG.md"]
  - tool: write_file
    paths: ["docs/release/**"]
ask_a_person:
  - tool: shell
  - tool: send_payment
deny:
  - tool: write_file
    paths: [".env*", "infra/**"]

Khi nó là một tệp trong repo, những thứ bạn cần tự có: pull request cho thấy ai nới write_file, git blame cho biết khi nào, review có thể từ chối. Danh sách "hỏi người" co lại còn vài lệnh thật sự cần người, nên khi hộp thoại hiện ra thì nó có nghĩa.

Soot có gì hôm nay, và chưa có gì

Soot đang ở bản preview, nên chúng tôi chỉ nói điều nói được hôm nay. Một Soot là một mission cộng với những tool bạn cấp rõ ràng. Một tool có thể được khai báo là cần người vận hành duyệt; khi đó lời gọi chờ trong Nest đến khi có người quyết định, chứ không chạy trước rồi báo sau. Còn soot check --show in ra các grant Soot đó đang có, nên "agent này được đụng vào gì" là một câu lệnh chứ không phải trí nhớ. Các bước đầu đã có trong Agent production cần cửa duyệt, không phải vòng tự do, gồm chuyện soot spawn mặc định có grant write và host-shell, còn soot spawn --empty thì bắt đầu không có chúng.

Nói rõ giới hạn: chúng tôi không nói Soot lưu luật của bạn thành tệp trong repo, hay tự thực thi một tệp luật bạn viết. Một thói quen dùng được với cái đang có là chạy lệnh kiểm rồi để kết quả cạnh code:

soot check --show > soot-grants.txt   # không dùng --secrets
git diff soot-grants.txt

Đó là quy ước do bạn giữ, không phải tính năng sản phẩm. Nhưng nó cho bạn đúng thuộc tính cần: nếu grant đổi, thay đổi hiện trong diff trước lần chạy tiếp theo đụng vào tệp thật. Đừng dùng --secrets trong thứ bạn commit hay dán đi đâu. Workspace cũng không phải sandbox của hệ điều hành; tool chạy trên host dùng đúng quyền OS của host, nên luật là lời nói về ý định, còn grant mới là thứ thật sự từ chối.

Một điểm liên quan từ Chữ ký hợp lệ không phải là được phép: lý do hiện cho người duyệt phải gọi tên thứ sắp bị đụng tới. Một dòng "người nhận mới, không có trong danh sách" thì được đọc; "Allow once" thì không.

Tệp luật cũng mục

Luật chỉ là một nửa. Nửa kia là chữ agent đọc: AGENTS.md hay CLAUDE.md, tệp skill, và mô tả mà MCP server gắn cho từng tool. Đó là instruction, và instruction giống code không ai chạy test.

Ba bài gần đây chỉ vào cùng một vấn đề từ ba phía:

• Một bài trên dev.to về bộ nhớ của agent (23/10) tìm những dòng cũ, thừa hoặc mâu thuẫn trong bộ nhớ và giúp agent quên chúng. Ghi nhiều hơn không có nghĩa là ghi tốt hơn.
• Một bài trên dev.to về MCP server chỉ ra rằng server có thể đổi câu mô tả một tool, và hành vi của agent đổi theo. Công cụ trong bài so đúng những chữ đã đổi giữa các phiên bản.
• Một bài trên dev.to về một skill bị từ chối kể lại lời phản đối của maintainer rằng luật trong skill có thể mâu thuẫn với quy trình mà harness đã có. Đó là phiên bản trong tệp instruction của hai bộ luật không khớp nhau.

Không cái nào cần sản phẩm mới mới làm theo được. Cần một thói quen review.

Một quy trình nhỏ

1. Coi tệp instruction như code đã được review. AGENTS.md, CLAUDE.md, tệp skill và luật nằm trong repo, đổi qua pull request, có người chịu trách nhiệm.
2. Đọc tìm mâu thuẫn. Một dòng bảo "không đụng infra/", dòng khác bảo "sửa mọi thứ đang lỗi", agent sẽ chọn một dòng, và chưa chắc là dòng bạn muốn. Xoá dòng cũ hơn.
3. Tỉa theo lịch. Dòng nào không ai giải thích được thì bỏ. Tệp ngắn thì được đọc; tệp dài thì bị lướt.
4. Chụp mô tả tool trước khi nâng cấp. Lưu lại mỗi tool MCP tự mô tả gì, nâng cấp, rồi diff. Nếu mô tả đổi theo cách bạn không ngờ, đó là mục cần review trước lần chạy đầu tiên.
5. Chạy lại `soot check --show` sau mỗi thay đổi tool hay grant, và đọc diff so với lần trước.
6. Chỉ giữ hộp thoại hỏi cho vài việc cần người, và để mỗi hộp nói rõ nó đụng vào gì.

Những việc này không làm agent thông minh hơn. Chúng làm cho quyền trở nên nhàm chán: viết ra, review được, và chỉ đổi khi có chủ ý.

Bước tiếp theo

Chọn một tool trong hệ của bạn có thể ghi hoặc chi tiền. Viết ra ai được dùng, để làm gì, trên cái gì, trong một tệp bạn review. Rồi chạy soot check --show và lưu kết quả cạnh nó. Tài liệu bắt đầu ở trysoot.com/docs.