Chuyển đến nội dung chính
Một agent đã bị prompt-injected, cấu hình sai, hoặc đơn giản được cho quá nhiều quyền tự do có thể gọi các tool mà nó không bao giờ có ý định chạm đến — hoặc gọi tool hợp lệ với đối số nguy hiểm: shell.exec với rm -rf /, payment API với số tiền chuyển khoản quá lớn, tool database nhắm vào replica production. Đây là agent tool abuse, và đây là một trong những rủi ro nghiêm trọng nhất trong các hệ thống agentic vì lời gọi tool có tác dụng phụ ngoài đời thực thường không thể đảo ngược. Agent Firewall có ba lớp phòng thủ. Bạn có thể triển khai chúng độc lập hoặc kết hợp.

1. Allow-listing: từ chối mọi thứ bạn không tường minh cho phép

Kiểm soát mạnh nhất là allow-list. Thay vì cố liệt kê mọi tool nguy hiểm, bạn liệt kê các tool mà agent hợp pháp cần — và từ chối mọi thứ khác. Đây là baseline zero-trust. Một chính sách với default_verdict: deny và quy tắc allow tường minh cho mỗi tool được phê duyệt đạt được điều này. Ví dụ: một agent chỉ nên đọc từ CRM:
[
  {
    "priority": 10,
    "label": "allow crm reads",
    "tool_name_glob": "crm.get*",
    "verdict": "allow"
  },
  {
    "priority": 20,
    "label": "allow crm search",
    "tool_name_glob": "crm.search",
    "verdict": "allow"
  },
  {
    "priority": 9999,
    "label": "deny everything else",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
Bất kỳ cuộc gọi nào đến shell.exec, db.delete, payment.transfer — dù được phát ra có chủ ý hay được kích hoạt bởi hướng dẫn bị tiêm nhiễm — hit catch-all * và trả về lỗi HTTP 400 firewall_blocked. Agent thấy lỗi tool có cấu trúc và không thể retry (block được đánh dấu skip-retry), nên nó không thể loop quanh sự từ chối.
Đặt default_verdict của chính sách thành deny để thực thi allow-list đầy đủ. Với verdict audit mặc định, các cuộc gọi không khớp được cho phép và ghi log nhưng không bị block — hữu ích trong quá trình triển khai nhưng không phải kiểm soát bảo mật độc lập.
Pattern glob cho phép bạn cho phép toàn bộ họ tool với một quy tắc. Các pattern phổ biến:
PatternNhững gì nó bao phủ
crm.*Tất cả tool trong namespace crm
*.readBất kỳ tool read-verb nào trên tất cả server
db.queryChính xác tool đơn này
*Mọi thứ (dùng cho catch-all deny)
So khớp tool là first-match-wins theo thứ tự priority tăng dần. Đặt quy tắc allow cụ thể của bạn ở số priority thấp và catch-all deny ở số cao.

2. Argument validation: cho phép tool, chặn invocation nguy hiểm

Một allow-list trên tên tool là thô — nó block shell.exec hoàn toàn. Đôi khi bạn muốn cho phép tool nhưng ràng buộc cách nó có thể được gọi. Argument clause cho phép bạn khớp trên các trường cụ thể bên trong đối số lời gọi tool, dùng JSONPath và một tập toán tử. Ví dụ: cho phép shell.exec nhưng block rm -rf
{
  "priority": 10,
  "label": "block destructive rm",
  "tool_name_glob": "shell.exec",
  "args_match": {
    "clauses": [
      {
        "path": "$.command",
        "op": "regex",
        "value": "rm\\s+-[^\\s]*r[^\\s]*f|mkfs|dd\\s+if=|:\\(\\)\\{.*\\}"
      }
    ]
  },
  "verdict": "deny"
}
Quy tắc này chỉ kích hoạt khi shell.exec được gọi đối số $.command khớp regex lệnh phá hủy. Một lời gọi shell.exec bình thường với lệnh an toàn rơi xuống quy tắc tiếp theo (hoặc verdict mặc định). Đặt quy tắc này ở số priority thấp hơn bất kỳ quy tắc allow shell.exec chung nào để nó kích hoạt trước. Toàn bộ tập toán tử đối số:
Toán tửDùng khi
eqSo khớp chính xác trên giá trị scalar (chuỗi hoặc số)
containsSo khớp chuỗi con — vd: $.query contains DROP TABLE
regexSo khớp pattern RE2 — an toàn trên hot path, không backtracking
inGiá trị phải có trong mảng đã cho — vd: chỉ cho phép môi trường cụ thể
cidr_matchĐịa chỉ IP trong CIDR block — hữu ích để kiểm tra đích đến egress
gt / ltSo sánh số — vd: $.amount gt 10000 cho payment cap
Tất cả clause trong block args_match đều được AND. Nếu path không tồn tại trong đối số của cuộc gọi, clause đánh giá false và quy tắc không kích hoạt — cuộc gọi rơi xuống quy tắc tiếp theo hoặc mặc định. Ví dụ payment guard — từ chối bất kỳ lời gọi payment tool nào với số tiền vượt ngưỡng:
{
  "priority": 5,
  "label": "cap payment amount",
  "tool_name_glob": "payment.*",
  "args_match": {
    "clauses": [
      { "path": "$.amount_cents", "op": "gt", "value": 100000 }
    ]
  },
  "verdict": "deny"
}

3. Human-in-the-loop: giữ các cuộc gọi cổ phần cao để phê duyệt

Đối với các tool thực sự cần thiết nhưng cổ phần cao — kích hoạt deployment, phê duyệt refund, gửi bulk email — bạn có thể yêu cầu con người ký trước khi cuộc gọi tiếp tục. Verdict pending_approval giữ cuộc gọi và trả về phản hồi firewall_approval_pending cho agent:
{
  "priority": 20,
  "label": "hold deployment calls for review",
  "tool_name_glob": "deploy.*",
  "verdict": "pending_approval"
}
Agent (hoặc framework của bạn) poll approval id. Reviewer phê duyệt hoặc từ chối từ console hoặc qua webhook callback. Nếu được phê duyệt, agent gửi lại cuộc gọi gốc với token phê duyệt dùng một lần và gateway cho nó qua một lần. pending_approval tương thích với argument clause — bạn có thể chỉ giữ các invocation khớp ngưỡng, và cho các cái thông thường qua:
[
  {
    "priority": 10,
    "label": "hold large deploys",
    "tool_name_glob": "deploy.release",
    "args_match": {
      "clauses": [
        { "path": "$.environment", "op": "eq", "value": "production" }
      ]
    },
    "verdict": "pending_approval"
  },
  {
    "priority": 20,
    "label": "allow staging deploys",
    "tool_name_glob": "deploy.*",
    "verdict": "allow"
  }
]

4. Một cuộc gọi bị block trông như thế nào

Một cuộc gọi bị từ chối trên bề mặt inbound (tool được quảng bá trong request) trả về HTTP 400 với mã lỗi firewall_blocked. Phản hồi bao gồm metadata có cấu trúc — nhãn quy tắc đã khớp, mã lý do, và các yếu tố rủi ro — và được đánh dấu skip-retry để loop không thể đập vào cùng cuộc gọi bị từ chối. Một cuộc gọi bị block trên bề mặt response (mô hình đã phát ra tool_calls) trả về lỗi tool hiển thị cho mô hình, cho nó cơ hội phản ứng — chọn tool khác, hỏi người dùng, hoặc dừng lại — thay vì crash.

5. Thứ tự first-match-wins

Thứ tự priority quan trọng. Engine duyệt quy tắc theo thứ tự priority tăng dần và dừng ở lần khớp đầu tiên. Một pattern phổ biến:
PriorityQuy tắcVerdict
5shell.exec + destructive regexdeny
10shell.* (chung)allow
20crm.*allow
9999* (catch-all)deny
Priority 5 kích hoạt trước priority 10 — nên shell.exec với lệnh phá hủy bị từ chối ngay cả khi có allow chung cho shell.*. Không có deny priority thấp, quy tắc allow shell.* sẽ thắng trước.

6. Triển khai an toàn với shadow mode

Trước khi chuyển chính sách mới sang thực thi, bật shadow mode. Chính sách đánh giá mọi lời gọi tool và ghi log verdict chính xác như nó sẽ làm trong production, nhưng mọi verdict thực thi (deny, pending_approval, sanitize) bị hạ cấp thành audit — không có gì bị block. Lý do trong event log có tiền tố [shadow] would deny để bạn có thể đo lường tác động trong các chế độ xem EventsRuns. Một khi bạn đã xác nhận chính sách kích hoạt trên những gì bạn mong đợi — và không có gì bạn không có ý định — tắt shadow mode. Cuộc gọi tiếp theo được thực thi.
Autonomy level tight áp dụng preset block_destructive_shell tự động. Nếu bạn cần tư thế nhanh mà không cần viết quy tắc, áp dụng tight từ console và nó ship một chính sách deny cho lời gọi destructive shell trong một bước. Bạn có thể xếp chồng quy tắc allow-list của riêng bạn lên trên. Xem Autonomy level.

7. Mối đe dọa liên quan

Lạm dụng tool agent hiếm khi đến một mình. Một lời gọi tool trái phép thường là hậu quả của một vector tấn công khác:
  • Prompt injection — kẻ tấn công nhúng hướng dẫn trong nội dung được truy xuất hướng agent đến các tool mà nó không có ý định gọi.
  • Excessive agency — agent được cấp quyền truy cập tool nhiều hơn nhiệm vụ của nó yêu cầu, làm cho mọi injection hoặc cấu hình sai ngay lập tức nguy hiểm.
  • Mô hình đe dọa — cách tool abuse phù hợp trong bề mặt tấn công đầy đủ cho hệ thống agentic.
Agent Firewall là lớp thực thi; nguyên tắc least privilege (tool allow-list hẹp, scoped key) là tư thế thiết kế làm cho nó hiệu quả.

Tham chiếu Firewall rules

Ngôn ngữ so khớp hoàn chỉnh — tool glob, argument clause, tất cả toán tử, verdict, và API.

Tổng quan Firewall

Chính sách, bề mặt, autonomy level, phê duyệt HITL, và khả năng quan sát.