Bài 5 — Audit trail: ghi vết mọi quyết định của agent

Khi agent làm việc thật, sớm muộn sẽ có người hỏi: "Tại sao hệ thống hoàn 30 triệu cho đơn này?". Nếu bạn không trả lời được trong 2 phút, agent của bạn chưa sẵn sàng cho production. Audit trail là bản ghi bất biến, đầy đủ về mọi hành động và lý do đằng sau nó.

Audit trail khác log ứng dụng thế nào?

Log debug phục vụ lập trình viên và có thể xoay vòng, mất mát. Audit trail phục vụ điều tra, tuân thủ và trách nhiệm giải trình — nên nó phải:

• Bất biến (append-only): chỉ thêm, không sửa/xóa.
• Đầy đủ ngữ cảnh: đủ để tái dựng vì sao quyết định được đưa ra.
• Truy vết được người/agent chịu trách nhiệm.
• Lưu đủ lâu theo yêu cầu nghiệp vụ/pháp lý.

Một bản ghi audit nên chứa gì

{
  "event_id": "evt_9f2a",
  "timestamp": "2026-07-10T09:14:22Z",
  "actor": "agent:refund-bot@v3",
  "action": "send_refund",
  "params": { "order_id": 4821, "amount": 3000000 },
  "reasoning": "Khách báo thiếu 2 SP, xác nhận qua ảnh #img_71",
  "risk_score": 6.4,
  "autonomy_level": "L3",
  "approval": { "required": true, "by": ["user:linh"], "at": "..." },
  "inputs_hash": "sha256:7c1e...",
  "result": { "status": "success", "refund_id": "rf_552" },
  "idempotency_key": "refund:order-4821:v1"
}

Chú ý ba trường vàng: reasoning (vì sao), approval (ai duyệt), inputs_hash (dữ liệu đầu vào tại thời điểm đó — để chứng minh agent thấy gì).

Ví dụ cụ thể: một dòng lệnh ghi audit

def audit(actor, action, params, reasoning, risk, level,
          approval=None, result=None):
    record = {
        "event_id": new_id(),
        "timestamp": now_iso(),
        "actor": actor,
        "action": action,
        "params": redact_pii(params),        # che dữ liệu nhạy cảm
        "reasoning": reasoning,
        "risk_score": risk,
        "autonomy_level": level,
        "approval": approval,
        "result": result,
    }
    audit_store.append(record)               # append-only, không update
    return record["event_id"]

Gọi audit(...) ở cả nhánh tự động lẫn nhánh được duyệt trong gated_execute (Bài 3). Không hành động write nào được rời khỏi hệ thống mà không để lại một dòng.

Các bước dựng audit trail

• Chọn kho append-only: bảng chỉ-insert, log stream, hoặc dịch vụ audit chuyên dụng. Cấm UPDATE/DELETE bằng quyền DB.
• Chuẩn hóa schema bản ghi (như JSON ở trên) và áp cho mọi hành động.
• Ghi trước-sau: ghi "intent" trước khi chạy, cập nhật "result" sau — hoặc ghi hai sự kiện liên kết bằng event_id.
• Che PII trong params (redact số thẻ, CCCD) nhưng giữ hash để đối chiếu.
• Gắn liên kết giữa audit ↔ approval_request ↔ idempotency_key để lần vết trọn vẹn.
• Xây màn tra cứu: lọc theo actor, action, khoảng thời gian, mức rủi ro.
• Đặt chính sách lưu giữ (retention) và kiểm tra không ai có quyền sửa.

Checklist audit sẵn sàng điều tra

• [ ] Trả lời được "ai/agent nào đã làm gì, khi nào, vì sao" trong vài phút?
• [ ] Bản ghi có reasoning và bằng chứng đầu vào?
• [ ] Kho ghi là append-only, không sửa được?
• [ ] PII đã che nhưng vẫn đối chiếu được?
• [ ] Có liên kết audit ↔ phê duyệt ↔ idempotency?

Sai lầm thường gặp

• Chỉ log khi thành công. Hành động bị từ chối hoặc thất bại thường quan trọng hơn khi điều tra. Ghi mọi kết cục.
• Cho phép sửa/xóa audit. Nếu bản ghi chỉnh được, nó vô giá trị khi cần đối chất. Khóa quyền ở tầng DB.
• Ghi thiếu reasoning. "Agent đã hoàn tiền" không giúp gì; "vì khách xác nhận thiếu hàng qua ảnh X" mới cho hiểu bối cảnh.
• Nhét cả bí mật/PII thô vào audit. Vi phạm quyền riêng tư và biến audit thành mục tiêu tấn công. Redact + hash.
• Trộn audit với log debug. Log debug ồn ào, xoay vòng, mất mát — không đủ tin cậy làm bằng chứng.

Bài sau ta chuyển từ ghi vết bị động sang giám sát chủ động: kill switch, cảnh báo và người-trên-vòng-lặp để chặn sự cố đang diễn ra.