Duyệt theo hậu quả, không duyệt theo chữ

Weiheng Wu et al. · 1 tác giả · Singapore Management University · 2026 · arXiv:2610.40753

Duyệt theo hậu quả, không duyệt theo chữ

Mở

Cổng duyệt hiện nay đọc chữ rồi phán: lệnh này có khớp pattern nguy hiểm không, có thuộc allowlist không. Nhưng cùng một lệnh shell cho kết quả khác nhau tùy file nào bị đụng tới và workspace đang ở trạng thái gì — chữ trên màn hình không nói cho bạn biết điều đó. Paper này đổi căn bản đối tượng của việc duyệt: thay vì đoán hậu quả từ lệnh, hãy chạy thử rồi xem hậu quả thật.

Paper này làm gì

Tác giả xây Caper, cơ chế duyệt theo hậu quả: mỗi lệnh được pre-executes trong sandbox có snapshot, một approver độc lập nhận báo cáo giới hạn về các hiệu ứng quan sát được thay vì nhận text lệnh, lệnh được phép thì commit, lệnh bị chặn thì rollback kèm lý do agent có thể dùng. So sánh với sáu hệ thống hiện có trên SABER và trên YoloFS-Ext — benchmark do nhóm dựng, nơi hành vi hại bị giấu bên trong tool được gọi.

Phát hiện chính

  1. Approver nhận hiệu ứng đã quan sát, không nhận lời hứa — Caper pre-executes từng lệnh trong sandbox snapshot rồi trao cho approver độc lập một báo cáo bounded về effects, thay vì để approver đọc chữ của lệnh.

pre-executes each command in a snapshotted sandbox, provides an independent approver with a bounded report of its observed effects

  1. Tỷ lệ outcome hại thấp nhất trên SABER: 6.7% — sáu hệ thống hiện có đều từ 14.8% trở lên.

Caper achieves the lowest harmful-outcome rate on SABER (6.7% versus at least 14.8%)

  1. Khi hại bị giấu trong tool được gọi, khoảng cách nới rộng thêm — trên YoloFS-Ext, Caper đạt 7.8% outcome hại so với mức thấp nhất 35.3% của các hệ thống khác, đồng thời chỉ chặn nhầm 1.0% số bản an toàn song song.

a benchmark we build in which harmful behavior is hidden inside invoked tools (7.8% versus at least 35.3%), while blocking 1.0% of the safe twins of the dangerous tasks

Caveat

YoloFS-Ext là benchmark do chính nhóm dựng, abstract không nêu chi phí tính toán hay độ trễ của việc pre-executes từng lệnh, và kết quả chưa được lặp lại trên môi trường production thật với người dùng thật.

Áp vào 5ac thế nào

Cổng duyệt card trên kanban 5ac đang đọc đúng phần chữ: tiêu đề, diff, mô tả. Nên thêm một bước chạy thử có snapshot trước khi người duyệt mở card — chạy lệnh trong sandbox cô lập, trả về báo cáo effects (file nào đổi, service nào đụng, lệnh nào fail), rồi người duyệt phán trên báo cáo đó. Lợi ích của bước này là nó dọn đúng chỗ các approver hay sai: đoán hậu quả từ text. Chi phí là thời gian pre-run, thứ abstract của bài chưa đo — nên 5ac nên tự đo lấy trên chính pipeline của mình.

Nguồn