← Blog
Agentic Trust & Protection Platform

Agentic Trust & Protection Platform: danh tính, hồ sơ ghi nhận và — sắp tới — một trạm kiểm soát cho mọi tác nhân AI

ATPP mang lại gì cho một tác nhân hôm nay, bản xem trước ATPP Enforce bổ sung gì, và — cũng quan trọng không kém — những gì chúng tôi chưa khẳng định.

Đội ngũ Redthread · 26 tháng 9 năm 2026 · 7 phút đọc

Hãy hỏi một nhóm đang vận hành tác nhân AI trong production bốn câu hỏi. Nó thực sự đã làm gì? Nó vẫn còn được phép làm gì? Bạn chứng minh điều đó với khách hàng bằng cách nào? Bạn có thể dừng nó nhanh đến mức nào? Phần lớn câu trả lời trung thực hiện nay chỉ là một cái nhún vai. Tác nhân xác thực bằng một khóa tồn tại lâu dài, phạm vi của nó được quyết định một lần trong tệp cấu hình, và lịch sử của nó là bất cứ thứ gì mà người viết tình cờ ghi log lại.

Agentic Trust & Protection Platform (ATPP) là câu trả lời của chúng tôi cho bốn câu hỏi đó. Nền tảng có ba lớp, và cần nói chính xác lớp nào đã có hôm nay và lớp nào vẫn là bản xem trước.

Lớp 1 — danh tính không phải là một khóa dùng chung

Mỗi tác nhân đã đăng ký có danh tính kiểu SPIFFE riêng và một thông tin xác thực có chữ ký, thời hạn ngắn, thay vì một API key nằm trong biến môi trường. Danh tính là duy nhất cho từng tác nhân, nên câu hỏi “tác nhân nào đã làm việc đó?” có câu trả lời, và nó được xoay vòng, nên thông tin xác thực bị lộ sẽ tự hết hạn.

Lớp 2 — hồ sơ có chữ ký về những gì nó đã làm

Trong khi tác nhân làm việc, các hành động của nó được báo cáo và chuyển thành sự kiện trạng thái tin cậy có chữ ký trong một sổ cái chỉ ghi thêm. Một huy hiệu — xanh khi tác nhân ở trong phạm vi được cấp, đỏ khi không — được tạo từ sổ cái đó, và một tài liệu xác minh cho phép người khác kiểm tra chữ ký ở chế độ offline. Mục đích của chữ ký là để hồ sơ không chỉ là lời khẳng định của chủ sở hữu tác nhân.

Cần nói rõ lớp này là gì: nó là một hồ sơ ghi nhận. Nó cho bạn biết, nhanh chóng và có thể kiểm chứng, rằng một tác nhân đã bước ra ngoài phạm vi. Tự bản thân nó không chặn được yêu cầu vượt phạm vi đó — yêu cầu ấy đã đi rồi vào lúc nó được báo cáo.

Lớp 3 — ATPP Enforce, một trạm kiểm soát (bản xem trước)

ATPP Enforce đưa quyết định ra trước yêu cầu. Một gateway nội tuyến đánh giá từng yêu cầu đi ra dựa trên quyền cấp của tác nhân và trả lời cho phép, từ chối hoặc tạm dừng. Quyền cấp có cấu trúc — host, method, path và giới hạn kích thước body — chứ không chỉ là danh sách tên công cụ, vì một cuộc tấn công gửi qua một công cụ được phép sẽ trông như trong phạm vi nếu bạn chỉ kiểm tra công cụ. Một vài đặc tính mà chúng tôi coi là không thể thương lượng:

  • Đóng khi lỗi (fail closed). Không có chính sách nghĩa là từ chối.
  • Mặc định chỉ đọc. Quy tắc không nêu tên method ghi thì không cho phép method ghi nào, và body của yêu cầu bị giới hạn kích thước.
  • Một danh sách chặn mà không quy tắc nào ghi đè được — các endpoint metadata đám mây và dải địa chỉ riêng luôn không thể tiếp cận.
  • Shadow trước tiên. Cùng một quyết định được tính toán ở chế độ shadow và chỉ được ghi lại, để bạn thấy những gì lẽ ra sẽ bị chặn trước khi bất cứ thứ gì thực sự bị chặn.

Cổng burn-in

Kiểu thất bại của mọi biện pháp kiểm soát có chặn là một kết quả dương tính giả làm sập production, nên chúng tôi biến thứ tự an toàn thành một quy tắc trong mã. Một danh tính không thể chuyển từ shadow sang enforce cho đến khi gateway đã theo dõi nó làm việc thực tế trong một khoảng thời gian tối thiểu với đủ số quyết định, và mọi yêu cầu mà gateway lẽ ra đã chặn đều được nhà vận hành rà soát và đồng ý. Việc rà soát được nhóm theo host và method để nhà vận hành phán quyết trên khoảng một chục mẫu thay vì hàng trăm dòng.

Biên nhận mà bên thứ ba có thể kiểm tra

Lưu lượng được thực thi mang theo một header biên nhận có chữ ký. Trang web nhận yêu cầu từ một tác nhân có thể gửi cho chúng tôi header đó và nhận một trong ba câu trả lời: được bao phủ và cho phép, được bao phủ và từ chối, hoặc hoàn toàn không được bao phủ. Câu trả lời cuối chỉ có ý nghĩa khi trang web đã xác định lưu lượng nào nó nghi là tác nhân — giới hạn phạm vi là việc của bên gọi — nhưng đó là phần duy nhất của ATPP giúp được cả một bên chưa từng áp dụng bất cứ thứ gì.

Máy chủ MCP của bên thứ ba

Tác nhân cũng cài đặt mã mà chúng không viết. Máy chủ MCP của bên thứ ba được thêm vào cấu hình của tác nhân mà hầu như không được thẩm định, và không ai chịu trách nhiệm về rủi ro: registry thì từ chối trách nhiệm, tác giả không có quan hệ gì với người cài đặt, còn framework tác nhân coi nó là cấu hình. ATPP chấm điểm các máy chủ MCP công khai và cho phép nhà phát hành nhúng một huy hiệu có thể xác minh, để người cài đặt kiểm tra máy chủ trước khi thêm vào.

Những gì chúng tôi không khẳng định

ATPP Enforce là bản xem trước. Engine quyết định, quyền cấp, gói chính sách có chữ ký, biên nhận và cổng burn-in đã được xây dựng và kiểm thử, và một prototype gateway đã chạy trước một lần quét tác nhân thật. Chúng tôi chưa chạy nó ở chế độ enforce trên workload của khách hàng, và chưa chọn data plane cho production. Vì vậy chúng tôi không nói rằng nó ngăn chặn tấn công nói chung. Điều chúng tôi nói hẹp hơn: một khi danh tính đã qua bước rà soát burn-in, các yêu cầu ngoài phạm vi có thể bị chặn trước khi chúng được gửi đi.

Sự thẳng thắn đó là có chủ ý. Một biện pháp kiểm soát bảo mật nói quá khả năng của mình còn tệ hơn không có gì, vì người ta sẽ thôi để ý. Đó cũng là nguyên tắc chúng tôi áp dụng cho các phát hiện kiểm thử xâm nhập: ghi rõ chúng tôi biết một điều bằng cách nào.

Dùng thử

Đăng ký tác nhân và đọc huy hiệu của chúng là miễn phí cho mười tác nhân đầu tiên. Bắt đầu tại trust.redthreadsec.com, hoặc đọc tài liệu về danh tính và Tài liệu tham chiếu API. Nếu bạn vận hành tác nhân có cài máy chủ MCP của bên thứ ba và muốn trở thành đối tác thiết kế cho Enforce, hãy cho chúng tôi biết.

Đọc tiếp

Các bài viết khác trên blog.

Bảo mật tác nhân
Tác nhân bị chặn nên đã tìm đường khác: bài học từ sự cố Services Australia
Một tác nhân nghiên cứu AI gặp rào cản truy cập trên một dịch vụ của chính phủ Úc và tiếp tục thử cho đến khi có cách thành công. Điều gì thực sự đã thất bại, và chúng tôi thiết kế thế nào để phòng tránh.
Nền tảng
Không cần agent và lấy đồ thị làm trung tâm: vì sao chúng tôi bắt đầu bằng một bản đồ, và thời gian lẫn chi phí thực sự nằm ở đâu
Cài agent ở khắp nơi và phân loại những danh sách phát hiện phẳng là hai chi phí ẩn lớn nhất của công cụ bảo mật. Đây là cách một đồ thị không cần agent loại bỏ cả hai.
Kiểm thử xâm nhập
Một đợt kiểm thử xâm nhập bằng AI tốn bao nhiêu — và nó không thay thế được điều gì
Kiểm thử xâm nhập thủ công là một khoản mua lớn và thưa thớt. Tác nhân tự động biến nó thành khoản nhỏ và thường xuyên. Đây là phép so sánh trung thực, kể cả những phần con người vẫn làm tốt hơn.