Brex xây dựng chính sách AI agent của mình bằng cách quan sát hành vi thực tế của các agent, thay vì viết ra các quy tắc trước.
OpenClaw đã trở thành một trong những framework agent được áp dụng rộng rãi nhất, nhưng nó vẫn chưa chứng minh được khả năng ở quy mô doanh nghiệp. Các agent cần có thông tin xác thực thực sự — khóa API, token OAuth, tài khoản dịch vụ — để hoạt động hiệu quả, và Brex nhận thấy rằng các rào cản truyền thống không thể kiểm soát được những gì các agent đang làm với chúng.
Brex đã đặt ra mục tiêu vượt qua những hạn chế này bằng cách xây dựng một nền tảng nội bộ có tên là CrabTrap. Proxy HTTP/HTTPS mã nguồn mở này chặn tất cả lưu lượng mạng, kiểm tra các quy tắc chính sách và sử dụng LLM làm thẩm phán để quyết định xem yêu cầu của agent nên được chấp thuận hay từ chối.
“Điều chúng tôi nhận thấy là lớp mạng là một điểm thực thi chưa được khai thác,” Pedro Franceschi, đồng sáng lập và CEO của Brex, nói với VentureBeat. “Mọi yêu cầu mà một agent thực hiện đều là cơ hội để chặn, suy luận và đưa ra quyết định chính sách.”
Thông điệp mà Franceschi muốn các nhà lãnh đạo CNTT rút ra: quản trị agent nên chuyển từ quyền cấp SDK và rào cản mô hình sang một mặt phẳng kiểm soát mạng tập trung, thực thi và học hỏi từ hành vi agent thực tế ngoài đời.
“Giải pháp rõ ràng” (ít nhất là ban đầu) cho khoảng trống bảo mật agent là các rào cản, và phần lớn công việc ban đầu tập trung vào các công cụ có phạm vi, quyền theo từng hành động và phê duyệt có sự tham gia của con người. Nhưng khi các agent phát triển, mỗi khả năng mới đồng nghĩa với việc có thêm một API cần tinh chỉnh hoặc một bề mặt cần kiểm toán, Franceschi lưu ý.
“Bất kỳ hệ thống agent nào có nhiều công cụ và quyền truy cập vào internet mở đều tạo ra căng thẳng ngay lập tức cho các nhà phát triển: Bạn càng làm cho agent có năng lực, nó càng trở nên nguy hiểm, và bạn càng làm cho nó an toàn, nó càng ít hữu ích,” ông nói.
Các giải pháp hiện có cho sự đánh đổi này là “yếu”: Token API chi tiết giúp ích ở mức biên nhưng vẫn có thể bị lạm dụng và hạn chế chức năng. Các rào cản ngữ nghĩa (như ngữ cảnh, kỹ năng hoặc điều hướng prompt) dễ dàng bị vượt qua bằng cách tiêm prompt, đặc biệt đối với các agent kết nối internet.
Các agent có thể bị “vô hiệu hóa” khi được cấp quyền chỉ đọc hoặc bộ công cụ hạn chế, nhưng sau đó chúng không thể thực hiện công việc có ý nghĩa, Franceschi nói. Mặt khác, cấp quyền ghi rộng rãi và bề mặt công cụ lớn có thể dẫn đến ảo giác và hậu quả sản xuất thực tế.
Các cổng giao thức ngữ cảnh mô hình (MCP) thực thi chính sách ở lớp giao thức — nhưng chỉ cho lưu lượng sử dụng MCP. Trong khi đó, các rào cản từ nhà cung cấp LLM bị ràng buộc với một mô hình duy nhất và có thể “mờ đục” để tùy chỉnh với các chính sách cụ thể của doanh nghiệp. Và các công cụ mạnh mẽ như Nvidia OpenShell cung cấp nhiều hơn “kiểm soát egress trên mỗi sandbox.”
“Khi chúng tôi bắt đầu, chúng tôi chưa tìm ra giải pháp để triển khai các harness như OpenClaw một cách an toàn,” Franceschi nói. “Thay vì chờ đợi ngành công nghiệp bắt kịp, chúng tôi quyết định tự mình giải quyết vấn đề và phát minh ra các công cụ cần thiết.”
Đáng chú ý, họ cần một nền tảng nằm giữa mọi agent và mọi yêu cầu mạng, và có thể đưa ra “các quyết định tinh tế về những gì được phép,” ông nói.
Điều này khiến lớp vận chuyển trở thành một thành phần kiến trúc cốt lõi và điểm khởi đầu tự nhiên, ông nói.
Bằng cách hoạt động ở lớp này, CrabTrap độc lập với framework, độc lập với ngôn ngữ và độc lập với API. Nó không yêu cầu wrapper SDK hay tích hợp theo từng công cụ. Người dùng chỉ cần đặt `HTTP_PROXY` và `HTTPS_PROXY` trong môi trường của agent, và mọi yêu cầu gửi đi sẽ được định tuyến qua proxy trước khi đến đích.
Tuy nhiên, Franceschi nhấn mạnh rằng Brex không bắt đầu từ lớp vận chuyển vì họ nghĩ đó là giải pháp duy nhất; thay vào đó, họ tin vào "bảo mật theo từng lớp".
"Lớp vận chuyển đơn giản là một lớp chưa được đầu tư đúng mức, và chúng tôi thấy cơ hội để thêm các biện pháp thực thi có ý nghĩa ở đó, cùng với mọi thứ khác," ông nói.
CrabTrap kết hợp các quy tắc tĩnh mang tính xác định với một LLM-as-a-judge cho các yêu cầu nằm ngoài các mẫu đã biết, Franceschi giải thích. Judge chỉ "kích hoạt trên phần đuôi dài của các endpoint không quen thuộc hoặc hình dạng yêu cầu bất thường," mà đối với một agent trưởng thành, thường chiếm ít hơn 3% yêu cầu.
Vấn đề cấp bách hơn là làm thế nào để biết một chính sách có đúng hay không? Với các quy tắc tĩnh, việc suy luận về độ chính xác "tương đối đơn giản". Nhưng với một LLM judge, hệ thống là phi xác định, và người dùng cần sự tự tin rằng chính sách chấp thuận các yêu cầu đúng và chặn phần còn lại.
"Hiểu biết chính của chúng tôi là khởi tạo chính sách từ hành vi quan sát được thay vì viết từ đầu," Franceschi nói. Bắt đầu từ hành vi thực tế và chỉnh sửa dựa trên các bài học thực tế hóa ra "hiệu quả hơn đáng kể so với bắt đầu từ một trang giấy trắng."
Nhóm của Brex đã xây dựng một trình tạo chính sách (bản thân nó là một vòng lặp agentic) chạy các agent cơ bản ở chế độ ẩn, phân tích lưu lượng mạng lịch sử, lấy mẫu các cuộc gọi đại diện và soạn thảo một chính sách ngôn ngữ tự nhiên phù hợp với những gì agent thực sự làm.
Từ đó, họ xây dựng một hệ thống đánh giá để kiểm tra các thay đổi chính sách trước khi đưa vào hoạt động. CrabTrap so sánh các bản ghi kiểm toán lịch sử với một chính sách dự thảo và báo cáo các thay đổi chính xác cần thực hiện. Người dùng có thể lọc kết quả theo phương thức, URL, quyết định ban đầu và trạng thái đồng thuận.
Tất cả điều này chạy với các cuộc gọi judge đồng thời, vì vậy việc phát lại hàng nghìn yêu cầu "mất vài phút, không phải vài giờ," Franceschi nói. Brex cũng phát triển một vòng phản hồi trực tiếp: Các bản ghi kiểm toán đầy đủ được lưu trữ trong PostgreSQL và có thể truy vấn thông qua API quản trị và bảng điều khiển. Trong trường hợp một tài nguyên liên tục bị từ chối, hệ thống có thể thông báo cho con người hoặc một agent để đề xuất cập nhật chính sách cho việc xem xét.
"Điều đó khép kín vòng lặp giữa các lần từ chối quan sát được và cải tiến chính sách," Franceschi nói.
Tất nhiên, việc xây dựng không phải không có thách thức. Một thách thức lớn là độ trễ: "Đặt một LLM giữa một agent và mọi yêu cầu API gửi đi nghe có vẻ như sẽ làm mọi thứ chậm lại," ông nói.
Tuy nhiên, nó hóa ra không phải là vấn đề lớn như dự kiến. Điều này có hai lý do: LLM judge chỉ kích hoạt trên một phần nhỏ yêu cầu (3% như đã đề cập). Các agent nhanh chóng ổn định vào các mẫu lưu lượng có thể dự đoán; một khi đã quan sát, các mẫu có khối lượng lớn sẽ trở thành quy tắc tĩnh. Thứ hai, bằng cách sử dụng các mô hình nhỏ,
Các mô hình nhanh như Claude Haiku có nghĩa là, ngay cả khi bộ kiểm tra (judge) có hoạt động, độ trễ thêm vào là "không đáng kể". Điều này có thể được giảm thêm nữa với các mô hình cục bộ và bộ nhớ đệm lời nhắc (prompt caching), Franceschi cho biết.
Thách thức khó hơn và ít rõ ràng hơn là việc chèn lời nhắc (prompt injection), ông nói. Bộ kiểm tra nhận được toàn bộ yêu cầu HTTP và tất cả nội dung đều do người dùng kiểm soát, vì vậy, một URL, tiêu đề hoặc phần thân yêu cầu được chế tạo có thể thao túng quyết định của bộ kiểm tra.
Brex đã giải quyết vấn đề này bằng cách cấu trúc yêu cầu dưới dạng một đối tượng JSON trước khi gửi đến mô hình, để tất cả nội dung do người dùng kiểm soát được "thoát (escape) thay vì được nội suy dưới dạng văn bản thô," Franceschi nói.
Brex theo dõi một số yếu tố để đo lường tác động nội bộ của CrabTrap: Mức độ tương tác với các tác nhân (agent), các mẫu lưu lượng mạng và điểm số quảng bá ròng (NPS). Kết quả có ý nghĩa nhất của CrabTrap là "sự tự tin của tổ chức," Franceschi cho biết.
Trước đây, nhóm đã có "sự do dự thực sự" khi triển khai rộng rãi các tác nhân tự động trên các hoạt động kinh doanh, bởi vì các tùy chọn rào chắn (guardrail) hiện có không cung cấp đủ sự đảm bảo.
"CrabTrap đã thay đổi cách tính toán đó," Franceschi nói. Giờ đây, họ có một lớp thực thi mà họ tin tưởng, giúp tăng sự tự tin xung quanh việc mở rộng triển khai tác nhân sang nhiều bộ phận hơn của doanh nghiệp và ủy quyền nhiều hơn việc cấu hình và quản lý tác nhân cho người dùng.
Franceschi mô tả các chính sách bắt nguồn từ lưu lượng truy cập là "mạnh mẽ một cách đáng ngạc nhiên." Nhóm đã kỳ vọng trình xây dựng chính sách sẽ tạo ra một "điểm khởi đầu thô" đòi hỏi phải chỉnh sửa thủ công nhiều. Tuy nhiên, trên thực tế, việc hướng nền tảng vào một vài ngày lưu lượng truy cập thực tế đã tạo ra các chính sách phù hợp với đánh giá của con người trên "phần lớn các yêu cầu được giữ lại."
Ngoài ra, CrabTrap đã tiết lộ mức độ nhiễu (noise) mà các tác nhân tạo ra. "Nhật ký kiểm toán (audit trail) đã làm cho điều này hiện rõ lần đầu tiên," Franceschi nói. Họ đã sử dụng nhật ký từ chối và phân tích lưu lượng không chỉ để điều chỉnh các chính sách, mà còn để thắt chặt bản thân các tác nhân, loại bỏ các công cụ và cắt bỏ toàn bộ các loại yêu cầu đang lãng phí cả thời gian lẫn token.
