HƯỚNG DẪN

Cách triển khai chính sách nhận biết tác nhân một cách an toàn

Một quy trình theo giai đoạn để chuyển từ quan sát lưu lượng của người, AI-assist và agent sang thực thi chính sách theo từng route, với đo lường và rollback ở mỗi bước.

Bởi Toshendra SharmaNhà sáng lập và CEO, AgentCredia · Updated November 13, 2026

Trung cấp · Đọc 10 phút

Điều gì có thể xảy ra sai khi bạn triển khai chính sách nhận biết tác nhân?

Chính sách nhận biết tác nhân thay đổi cách ứng dụng của bạn phản hồi dựa trên ai hoặc cái gì đang thực hiện hành động. Làm đúng, nó tạo trải nghiệm mượt cho người dùng, cho agent hợp lệ một lộ trình có cấu trúc, và chỉ thêm ma sát ở nơi thực sự cần. Làm sai, nó chặn nhầm người dùng thật, làm hỏng các tích hợp mà khách hàng phụ thuộc, và tạo ra các ticket hỗ trợ không ai giải thích được.

Khác biệt hiếm khi nằm ở logic policy. Nó nằm ở rollout. (Về chính mô hình policy, xem thiết kế policy ở cấp ứng dụng cho con người và agent AI.) Hướng dẫn này mô tả một quy trình theo giai đoạn mà các team có thể áp dụng cho bất kỳ route nào: quan sát, xem trước, áp dụng cho một phần, rồi mở rộng. Mỗi giai đoạn có một tiêu chí thoát rõ ràng và một cách quay lại nhanh.

Ba chế độ

Hãy xem mỗi policy như đang chạy ở một trong ba chế độ theo từng route:

Quan sát. Các phân loại được ghi lại. Ứng dụng phản hồi đúng như khi không có chúng.
Xem trước. Policy được đánh giá và quyết định của nó được ghi lại, nhưng không được áp dụng. Bạn có thể thấy điều gì đã xảy ra.
Áp dụng. Quyết định được áp dụng cho các request thực.

Chế độ thuộc về cặp route và policy, không thuộc về toàn bộ ứng dụng. Các trang tài liệu của bạn có thể đang áp dụng trong khi checkout của bạn vẫn đang quan sát.

Bước 1: Quan sát cho đến khi bạn biết đường cơ sở của mình

Bắt đầu với mọi route ở chế độ quan sát. Thu thập, ít nhất:

route và method,
actor class (Human, Human + AI, Agent hoặc Unknown) và basis của nó (verified, declared, inferred hoặc unknown), như được định nghĩa trong taxonomy của chúng tôi cho lưu lượng ứng dụng,
trạng thái phản hồi và một chỉ báo kết quả đơn giản cho route, chẳng hạn "tạo tài khoản thành công" hoặc "tìm kiếm trả về kết quả".

Chạy đủ lâu để bao quát các chu kỳ hằng tuần bình thường và mọi lần release bạn đưa ra trong khoảng thời gian đó. Sau đó ghi lại đường cơ sở cho từng route bạn quan tâm: thành phần class, tỷ lệ Unknown và tỷ lệ kết quả theo từng class. Bạn sẽ so sánh mọi thứ tiếp theo với các con số này.

Tiêu chí thoát: bạn có thể mô tả, cho từng route ứng viên, ai đang dùng nó và kết quả khác nhau ra sao theo class.

Bước 2: Viết policy dưới dạng dữ liệu

Policy dễ review, test và rollback hơn khi chúng là dữ liệu thay vì các câu lệnh if rải rác.

type ActorClass = "human" | "human_ai" | "agent" | "unknown";
type Basis = "verified" | "declared" | "inferred" | "unknown";
type Action = "allow" | "adapt" | "challenge" | "review" | "limit";
type Mode = "observe" | "preview" | "enforce";

interface Rule {
  actor: ActorClass | "*";
  basis?: Basis[];
  action: Action;
}

interface RoutePolicy {
  route: string;
  mode: Mode;
  enforcePercent: number;
  rules: Rule[];
  fallback: Action;
}

export const policies: RoutePolicy[] = [
  {
    route: "GET /api/catalog",
    mode: "preview",
    enforcePercent: 0,
    rules: [
      { actor: "agent", basis: ["verified"], action: "allow" },
      { actor: "agent", basis: ["declared", "inferred"], action: "limit" },
    ],
    fallback: "allow",
  },
];

Mỗi policy có một fallback rõ ràng. Đây là hành động được dùng cho các kết quả Unknown, cho timeout và cho mọi trường hợp mà không có rule nào bao phủ. Chọn nó một cách có chủ đích là quyết định an toàn quan trọng nhất trong toàn bộ quy trình.

Bước 3: Đánh giá ở một nơi duy nhất

Một hàm đánh giá duy nhất giữ cho hành vi nhất quán giữa các chế độ.

export function decide(policy: RoutePolicy, actor: ActorClass, basis: Basis): Action {
  for (const rule of policy.rules) {
    const actorMatch = rule.actor === "*" || rule.actor === actor;
    const basisMatch = !rule.basis || rule.basis.includes(basis);
    if (actorMatch && basisMatch) return rule.action;
  }
  return policy.fallback;
}

Sau đó áp dụng chế độ:

export function applyPolicy(policy: RoutePolicy, actor: ActorClass, basis: Basis, requestKey: string) {
  const decision = decide(policy, actor, basis);
  const inSlice = bucket(requestKey) < policy.enforcePercent;
  const enforced = policy.mode === "enforce" && inSlice;
  record({ route: policy.route, mode: policy.mode, actor, basis, decision, enforced });
  return enforced ? decision : "allow";
}

function bucket(key: string): number {
  let h = 0;
  for (const c of key) h = (h * 31 + c.charCodeAt(0)) >>> 0;
  return h % 100;
}

Bucket ổn định có nghĩa là cùng một session hoặc client sẽ ở trong hoặc ngoài phần được áp dụng, để người dùng không thấy hành vi thay đổi qua từng request.

Bước 4: Làm thế nào để đo false positive trước khi áp dụng?

Chuyển một route sang chế độ xem trước. Lúc này mọi request đều ghi lại quyết định mà nó sẽ nhận được. Đây là lúc bạn biết policy có đúng hay không.

False positive là một request mà policy sẽ hạn chế nhưng lẽ ra phải được cho phép. Bạn không thể đo nó chỉ từ các phân loại, vì chính phân loại là thứ bạn đang kiểm tra. Hãy đo nó dựa trên các tín hiệu độc lập của việc sử dụng hợp lệ:

request đã hoàn tất một luồng thành công bình thường, chẳng hạn người dùng đã đăng nhập lưu thay đổi,
client là một tích hợp đối tác đã biết hoặc một operator đã được xác minh mà bạn đã đồng ý phục vụ,
ticket hỗ trợ hoặc báo cáo của người dùng nhắc đến route bị ảnh hưởng,
một lượt review thủ công trên một mẫu các request lẽ ra bị hạn chế.

Hãy review một mẫu bằng tay. Đọc hai mươi request thực tế mà policy sẽ đã challenge là cách nhanh nhất để tìm ra một rule quá rộng.

Tiêu chí thoát: tập hợp các request lẽ ra bị hạn chế chủ yếu là lưu lượng mà bạn thực sự muốn hạn chế, và bạn có lời giải thích cho mọi nhóm false positive mà bạn tìm thấy.

Bước 5: Áp dụng cho một phần

Chuyển route sang chế độ áp dụng với một enforcePercent nhỏ. Giữ phần này đủ nhỏ để một sai sót chỉ ảnh hưởng đến ít request và đủ lớn để tạo ra tín hiệu có thể đo được trong vòng một hoặc hai ngày.

Theo dõi cùng các chỉ số bạn đã đặt làm đường cơ sở:

tỷ lệ kết quả theo class trên route,
tỷ lệ lỗi và tỷ lệ hoàn thành challenge,
khối lượng hỗ trợ nhắc đến route,
độ trễ, vì khâu đánh giá nằm trên đường đi của request.

Nếu kết quả cho lưu lượng Human giảm trong phần đã áp dụng so với phần còn lại, hãy dừng lại và điều tra trước khi mở rộng.

Bước 6: Mở rộng dần dần

Tăng phần áp dụng theo từng bước, ví dụ từ một phần nhỏ lên một phần tư, rồi một nửa, rồi toàn bộ lưu lượng, và dừng ở mỗi bước đủ lâu để thấy một chu kỳ bình thường. Việc mở rộng sẽ rất yên bình khi các giai đoạn trước đã làm tốt. Đó là mục tiêu.

Chọn fallback và hành vi khi lỗi

Quyết định trước điều gì xảy ra khi thiếu evidence hoặc khi không thể chạy đánh giá.

Fail open nghĩa là request tiếp tục như thể không có actor context. Dùng cho các route ít rủi ro như trang công khai, tài liệu và các endpoint danh mục chỉ đọc.
Fail closed nghĩa là kiểm tra mạnh hiện có của bạn được áp dụng, chẳng hạn xác thực lại hoặc một hàng đợi review. Dùng cho các hành động có tác động cao nơi bạn đã có sẵn kiểm tra như vậy.

Đừng bao giờ để timeout hoặc lỗi tạo ra kết quả Human. Evidence bị thiếu là Unknown, và Unknown sẽ dùng fallback của route. Bài viết của chúng tôi về vì sao Unknown là một kết quả hợp lệ khi phân loại lưu lượng AI giải thích lý do quy tắc này quan trọng.

async function actorWithTimeout(evaluate: () => Promise<{ actor: ActorClass; basis: Basis }>) {
  const timeout = new Promise<{ actor: ActorClass; basis: Basis }>((resolve) =>
    setTimeout(() => resolve({ actor: "unknown", basis: "unknown" }), 150),
  );
  return Promise.race([evaluate(), timeout]);
}

Làm thế nào để rollback một policy nhanh chóng?

Rollback nên là thay đổi cấu hình, không phải deploy. Giữ policy trong một kho mà team có thể chỉnh sửa nhanh, và làm cho các hành động này có hiệu lực ngay:

Đưa một route về chế độ xem trước, điều này dừng thực thi nhưng vẫn giữ đo lường.
Đặt enforcePercent về zero.
Vô hiệu hóa một rule đơn lẻ mà không động đến các rule khác.

Ghi lại mọi thay đổi policy cùng với người thực hiện và thời điểm. Khi kết quả thay đổi, câu hỏi đầu tiên luôn là đã thay đổi điều gì.

Tránh các quyết định có hậu quả về con người

Phân loại tác nhân mô tả evidence về một tương tác. Chúng không phải là sự phán xét về một con người. Đừng dùng một class được suy luận làm cơ sở duy nhất cho các quyết định ảnh hưởng đến việc làm, tín dụng, giáo dục, nhà ở hoặc quyền truy cập các dịch vụ thiết yếu của ai đó. Với những luồng đó, hãy dùng ngữ cảnh tác nhân để chọn quy trình, ví dụ chuyển đến review của con người, thay vì quyết định kết quả.

Truyền đạt trước khi áp dụng

Các policy ảnh hưởng đến client tự động cũng ảnh hưởng đến những người và công ty vận hành chúng. Một chút truyền đạt sẽ giảm rất nhiều công việc hỗ trợ:

Công bố các quy tắc của bạn cho truy cập tự động. Nêu rõ route nào được mở, giới hạn nào được áp dụng và cách client có thể tự nhận diện bằng signed request sử dụng HTTP Message Signatures (RFC 9421) và bản dự thảo giao thức Web Bot Auth của IETF.
Thông báo trước cho đối tác và bên tích hợp. Nếu một tích hợp đã biết rơi vào phần bị hạn chế trong giai đoạn xem trước, hãy liên hệ với chủ sở hữu của nó trước khi bạn áp dụng.
Trả về phản hồi hữu ích. Khi một policy giới hạn hoặc challenge một request, hãy phản hồi bằng một status code rõ ràng, chẳng hạn 429 Too Many Requests với Retry-After, và một link tới tài liệu của bạn. Một body có thể đọc bằng máy theo định dạng Problem Details cung cấp cho client tự động một lý do có cấu trúc. Các agent được xây dựng tốt sẽ thích ứng khi chúng hiểu vì sao.
Cung cấp evidence cho team hỗ trợ của bạn. Khi một ticket đến về request bị chặn, support phải có thể tra cứu route, class, basis và quyết định policy mà không cần hỏi engineering.

Các team thông báo thay đổi và giải thích chúng sẽ gặp ít bất ngờ hơn nhiều so với các team âm thầm đổi rule, và các client thích ứng sẽ dễ nhận ra hơn theo thời gian.

Danh sách kiểm tra cho từng route

Đã ghi lại đường cơ sở cho thành phần class, tỷ lệ Unknown và kết quả.
Policy được viết dưới dạng dữ liệu với fallback rõ ràng.
Đã chạy preview, đã review mẫu, đã giải thích các nhóm false positive.
Đã bắt đầu thực thi trên một phần nhỏ với các chỉ số được theo dõi.
Đã chọn hành vi khi lỗi: fail open hoặc fail closed.
Đã thử rollback trước khi mở rộng.

Proof of Actor phù hợp ở đâu

Proof of Actor được thiết kế xoay quanh quy trình này. Quan sát là mặc định, mọi kết quả đều đi kèm basis của nó, và các policy Route là do bạn định nghĩa và áp dụng trong code của chính bạn, theo từng route. Detect, Understand, Route: theo đúng thứ tự đó.

Để cùng team của chúng tôi thực hiện một rollout trên ứng dụng của bạn, đăng ký truy cập sớm. Để xem luồng quyết định từ đầu đến cuối, hãy đọc Proof of Actor hoạt động như thế nào.

Nguồn

RFC 6585: Additional HTTP Status Codes, Section 4: mã trạng thái 429 Too Many Requests
RFC 9110: HTTP Semantics, Retry-After: cho client biết khi nào thử lại
RFC 9457: Problem Details for HTTP APIs: nội dung lỗi có thể đọc bằng máy
RFC 9421: HTTP Message Signatures: cách client tự động ký request
draft-ietf-webbotauth-httpsig-protocol: bản nháp IETF Web Bot Auth cho lưu lượng tự động đã ký (đang trong quá trình hoàn thiện tính đến November 2026)

Xây dựng cùng chúng tôi.

Hãy tham gia chương trình nhà phát triển sáng lập của Proof of Actor.

Nhận quyền truy cập sớm Trung tâm dành cho nhà phát triển

Bạn muốn trao đổi trước? Trao đổi với những người sáng lập