Excessive agency & confused deputy

Một agent có nhiều khả năng hơn mức nhiệm vụ cần là một rủi ro đang chờ bị khai thác. Đánh cắp key của nó, đánh lừa nó bằng một hướng dẫn bị tiêm nhiễm, hoặc tấn công một dependency — và mọi thứ mà key đó có thể làm giờ đây nằm trong tay kẻ tấn công. Đây là vấn đề excessive agency, và nó kết hợp với một pattern liên quan chặt chẽ được gọi là confused deputy: agent không bị xâm phạm trực tiếp, nó bị lừa dùng quyền hạn hợp pháp của mình thay mặt kẻ tấn công. Cả hai vấn đề có cùng một nguyên nhân gốc rễ: key mà một agent bị xâm phạm nắm giữ quá mạnh so với nhiệm vụ nó thực hiện. Biện pháp phòng thủ là least agency — cấp cho mỗi agent chính xác khả năng mà nhiệm vụ của nó yêu cầu, và không hơn.

​

1. Điều gì khiến một agent có quá nhiều khả năng

Khi mọi agent trong một workspace dùng chung một key, hoặc khi một key được phát hành một lần và không bao giờ được xem xét lại, khả năng tích lũy dần dần:

• Model không bị hạn chế — agent có thể gọi bất kỳ model nào trong workspace, kể cả những model đắt tiền hay có khả năng cao mà nó không bao giờ cần.
• Không có giới hạn chi tiêu — một vòng lặp mất kiểm soát, một injection được kích hoạt, hoặc một cuộc tấn công billing có thể làm cạn kiệt số dư workspace trước khi bạn kịp chú ý.
• Không có ngày hết hạn — một key được phát hành trong một sprint vẫn còn hiệu lực một năm sau, lâu hơn nhiều so với thời gian agent được tạo ra cho nó đã bị ngừng hoạt động.
• Không có ràng buộc IP — credential hoạt động từ bất kỳ đâu, nên một key bị rò rỉ không có giới hạn địa lý.
• Không có tool allow-list — agent có thể gọi bất kỳ tool nào, kể cả những tool không liên quan đến chức năng của nó.

Bất kỳ một trong những điều này đơn lẻ đã là một bán kính nổ được mở rộng. Kết hợp lại, một agent bị xâm phạm duy nhất có thể làm mọi thứ mà một workspace admin có thể làm — gọi model mạnh nhất, tiêu hết số dư, tiếp cận mọi tool.

​

2. Pattern confused deputy

Confused deputy là một dạng chuyên biệt của excessive agency. Agent không bị chiếm quyền điều khiển; nó bị thuyết phục. Một payload prompt-injection trong một trang web được truy xuất, tài liệu, hoặc kết quả tool yêu cầu agent thực hiện một hành động mà nó được phép hợp pháp thực hiện — chuyển tiền, xóa một bản ghi, gửi một tin nhắn — thay mặt kẻ tấn công. Agent hành động. Nó được ủy quyền làm chính xác điều đó. Kiểm tra ủy quyền vượt qua. Thiệt hại đã xảy ra. Phòng thủ đòi hỏi hai thứ hoạt động cùng nhau:

1. Phạm vi hẹp — agent không thể bị lừa để làm điều gì đó mà nhiệm vụ của nó không bao giờ có ý định, vì nó không được ủy quyền làm điều đó ngay từ đầu.
2. Phê duyệt của con người cho các hành động không thể đảo ngược — ngay cả trong phạm vi được ủy quyền, một lời gọi cổ phần cao cần một con người xác nhận trước khi nó thực thi.

​

3. Phòng thủ theo chiều sâu: bốn lớp

OrcaRouter thực thi least agency qua bốn điều khiển độc lập kết hợp trên một API key duy nhất. Không cái nào yêu cầu thay đổi code trong agent của bạn.

​

Lớp 1 — Key có phạm vi (danh tính + giới hạn cứng)

Mỗi agent nên có API key riêng của mình. Key mang các giới hạn cứng mà gateway thực thi bất kể agent yêu cầu gì: Các giới hạn này được thực thi ở cấp key — trước bất kỳ chính sách nào, trước bất kỳ lời gọi model nào. Chúng là ranh giới bán kính nổ ngoài cùng.

​

Lớp 2 — Chính sách firewall (tool allow-list)

Gắn một chính sách firewall vào key qua firewall_policy_id. Chính sách quản trị mọi lời gọi tool mà key đó phát ra:

• Viết các quy tắc allow tên tool mà agent hợp pháp sử dụng (glob tên tool được hỗ trợ — vd: db.query*).
• Đặt default_verdict của chính sách thành deny để bất kỳ thứ gì không được liệt kê tường minh đều bị block.
• Thêm argument predicate để hạn chế ngay cả các tool được phép — vd: chỉ cho phép db.query khi đối số database khớp với một schema cụ thể.

Một key không có attachment firewall fallback về chính sách mặc định của workspace. Đối với các agent có nhu cầu tool hẹp, một attachment tường minh với chính sách chặt chẽ luôn được ưu tiên hơn là dựa vào mặc định của workspace. Xem Quy tắc Firewall để biết ngôn ngữ so khớp đầy đủ.

​

Lớp 3 — Phê duyệt của con người cho các hành động cổ phần cao (pending_approval)

Đối với các lời gọi tool không thể đảo ngược hoặc giá trị cao — một giao dịch thanh toán, xóa bản ghi, gửi email — thêm một quy tắc pending_approval. Luồng xử lý:

1. Agent phát ra lời gọi tool. Firewall giữ lại và trả về phản hồi “held” mang theo một approval id. Lời gọi không đến được tool.
2. Một reviewer phê duyệt hoặc từ chối ngoài luồng — từ console (Developer+) hoặc qua webhook ký HMAC tới hệ thống phê duyệt của riêng bạn.
3. Agent của bạn poll approval id. Một khi được phê duyệt, nó gửi lại lời gọi gốc với một header dùng một lần X-OrcaRouter-Firewall-Approval. Gateway cho nó đi qua đúng một lần.

Confused deputy bị dừng tại đây ngay cả khi phạm vi hợp lệ: một con người xác nhận hành động là có chủ ý trước khi nó thực thi.

​

Lớp 4 — Giới hạn chi phí mỗi lần chạy (cap_cost)

Một quy tắc cap_cost từ chối bất kỳ lời gọi tool nào khi chi tiêu tích lũy của lần chạy agent vượt quá một ngưỡng trần theo từng quy tắc (tính bằng cents). Đây là cầu dao ngắt mạch cho:

• Vòng lặp mất kiểm soát được kích hoạt bởi injection.
• Các cuộc tấn công billing đẩy chi tiêu trước khi bất kỳ con người nào chú ý.
• Đệ quy vô tình trong các kế hoạch nhiều bước.

cap_cost hoạt động ở cấp lần chạy, không phải cấp trọn đời key — nên nó đặt lại mỗi lần gọi agent, và một lần chạy bị lỗi duy nhất không thể làm cạn kiệt trần credit_limit_usd của key.

​

4. Một key agent có phạm vi tốt — ví dụ

Một agent tóm tắt ticket của khách hàng dùng gpt-4o-mini và truy vấn một replica chỉ đọc nên có dạng như sau:

• model_limits: ["openai/gpt-4o-mini"] — không thể leo thang lên một model có khả năng hơn hoặc đắt hơn.
• allow_ips: CIDR egress của worker pool — key không hoạt động ở bất kỳ nơi nào khác.
• credit_limit_usd: một trần hàng tuần tương ứng với chi phí dự kiến của nhiệm vụ, có thêm một khoảng dự phòng — vd: 5.00.
• expired_time: cuối sprint hoặc giai đoạn triển khai — key tự hết hạn mà không cần dọn dẹp thủ công.
• environment: "prod" — xuất hiện trong bộ lọc log và chế độ xem bất thường.
• guardrail_id: một guardrail được giới hạn phạm vi theo độ nhạy cảm dữ liệu của agent này (che PII, không có secrets trong output).
• firewall_policy_id: một chính sách cho phép db.query* và ticket.read* trong allow-list, verdict mặc định deny.

Khi agent này bị lừa để lọc dữ liệu qua một hướng dẫn bị tiêm nhiễm, bán kính nổ là: một model, một dải IP, một namespace tool, một trần chi phí. Phần còn lại của workspace không bị ảnh hưởng.

​

5. Vai trò cần thiết

​

6. Quan hệ với các mối đe dọa khác

Excessive agency là yếu tố kích hoạt cho hầu hết mọi mối đe dọa agent khác:

• Lời gọi tool nguy hiểm — một key với tool allow-list hẹp không thể bị buộc gọi một tool không có trong danh sách, ngay cả khi injection thành công.
• Prompt injection — giới hạn phạm vi thu hẹp thiệt hại mà injection có thể gây ra; các cổng phê duyệt chặn các hành động không thể đảo ngược mà injection cố kích hoạt.
• Mô hình đe dọa — bản đồ bề mặt tấn công đầy đủ, cho thấy vị trí của excessive agency so với các vector khác.

Least agency không ngăn chặn injection. Nó thu hẹp những gì injection có thể đạt được. Least agency — một key hẹp mỗi agent, một tool allow-list chặt chẽ, một giới hạn chi tiêu, và phê duyệt của con người cho các hành động không thể đảo ngược — là biện pháp phòng thủ chính chống các cuộc tấn công excessive agency llm và pattern confused deputy.