ସମସ୍ତଙ୍କ ପାଇଁ ଗୋଟିଏ policy ଆଉ ପର୍ଯ୍ୟାପ୍ତ ନୁହେଁ
ଅଧିକାଂଶ application ଗୋଟିଏ ପ୍ରକାର user ଉପରେ ଆଧାରିତ ହୋଇ ଡିଜାଇନ୍ ହୋଇଥିଲା: account ରେ signed in ଥିବା ଏବଂ interface ମାଧ୍ୟମରେ click କରୁଥିବା ଜଣେ person। access control ଏହି ଧାରଣାକୁ ଅନୁସରଣ କରୁଥିଲା। session valid ହେଲେ request ପାର୍ ହୁଏ। automated ଦେଖାଗଲେ CAPTCHA କିମ୍ବା block ଆସେ।
ସେ model ଭାଙ୍ଗୁଛି। ଆଜି ସେଇ application ଲୋକଙ୍କୁ, AI assistants ସହ କାମ କରୁଥିବା ଲୋକଙ୍କୁ, ଏବଂ କାହାରୋ ପକ୍ଷରୁ କାର୍ଯ୍ୟ କରୁଥିବା autonomous agent ମାନଙ୍କୁ ସେବା ଦେଇଥାଏ। କିଛି agent ଗ୍ରାହକଙ୍କ ନିଜ integration। କିଛି agent documentation fetch କରୁଥିବା AI assistant। କିଛି crawler। କିଛି ଆପଣଙ୍କ product କୁ abuse କରିବାକୁ ଚେଷ୍ଟା କରୁଛନ୍ତି। ଗୋଟିଏ yes-or-no rule ସବୁଙ୍କ ପାଇଁ ଭଲ ହୋଇପାରେ ନାହିଁ।
AI agent routing ଏବଂ access policy ସେଇ single rule କୁ deliberate ନିଷ୍ପତ୍ତିମାନଙ୍କର ଏକ ସମୂହ ସହ ପରିବର୍ତ୍ତନ କରେ: କେଉଁ actor କୁ କେଉଁ experience ମିଳିବ, କେଉଁ route ରେ, କେଉଁ condition ତଳେ। Proof of Actor ଆପଣଙ୍କ application କୁ ସେଇ ନିଷ୍ପତ୍ତି ନେବା ପାଇଁ evidence ଦେଇଥାଏ, ଏବଂ ନିଷ୍ପତ୍ତି ନିଜେ ଆପଣଙ୍କ ହାତରେ ଛାଡ଼ି ଦିଏ। ଏହି approach ର design principle ପାଇଁ, designing app policies for humans and AI agents ପଢ଼ନ୍ତୁ, ଏବଂ ପ୍ରକୃତ product workflow ସହ policy କିପରି ମିଳେ ସେଥିପାଇଁ SaaS apps use case ଦେଖନ୍ତୁ।
ଭଲ agent policy କେମିତି ଦେଖାଏ
ଏକ ଉପଯୋଗୀ policy ନିର୍ଦ୍ଦିଷ୍ଟ ହୁଏ। ସେ route କିମ୍ବା workflow, actor class, ଆବଶ୍ୟକ evidence ର strength, ଏବଂ response କୁ ନାମକରଣ କରେ। ଉଦାହରଣ ସ୍ୱରୂପ:
- Read-only catalog route: verified agent ମାନଙ୍କୁ allow କରନ୍ତୁ ଏବଂ structured response ସର୍ଭ୍ କରନ୍ତୁ; standard rate limit ସହ declared agent ମାନଙ୍କୁ allow କରନ୍ତୁ।
- Account ପରିବର୍ତ୍ତନ କରୁଥିବା action: ସମସ୍ତଙ୍କ ପାଇଁ ଆପଣଙ୍କ existing re-authentication ରଖନ୍ତୁ; actor Unknown ଥିଲେ ଏବଂ action high impact ଥିଲେ review ଯୋଗ କରନ୍ତୁ।
- Support submission: disclosed AI-assisted content ଗ୍ରହଣ କରନ୍ତୁ ଏବଂ routing ପାଇଁ ଏହାକୁ label କରନ୍ତୁ।
- Signup: existing check ରଖନ୍ତୁ; inferred actor result ରୁ କଦାପି ସିଦ୍ଧାନ୍ତ ନିଅନ୍ତୁ ନାହିଁ।
ଏହି ପ୍ରତ୍ୟେକଟି ପ୍ରତ୍ୟେକ agent କୁ abuse ଭାବେ ନ ଦେଖି actor ଉପରେ ପ୍ରତିକ୍ରିୟା କରେ, ଏବଂ ସମସ୍ତ agent କୁ ଅନ୍ଧ ଭାବେ trust କରେ ନାହିଁ। ସେଇ ସମତୁଳନ agent-aware access ର ସମ୍ପୂର୍ଣ୍ଣ ଅର୍ଥ, ଏବଂ designing app policies for humans and AI agents ଉପରେ blog post route by route ଅଧିକ ଉଦାହରଣ ମାଧ୍ୟମରେ ଏହାକୁ ବ୍ୟାଖ୍ୟା କରେ।
ପାଞ୍ଚଟି ପ୍ରତିକ୍ରିୟା
Proof of Actor ର Route capability ପାଞ୍ଚଟି ପ୍ରତିକ୍ରିୟାକୁ ଆଧାର କରି ତିଆରି, ଯାହା ମଧ୍ୟରୁ ଆପଣଙ୍କ policy ବାଛିପାରେ।
Allow
Request କୁ ସାଧାରଣ ଭାବରେ ଚାଲିବାକୁ ଦିଅନ୍ତୁ। ଅଧିକାଂଶ traffic, public କିମ୍ବା low-risk route ରେ ଥିବା ଅଧିକାଂଶ agent traffic ସହିତ, ସରଳ ଭାବରେ allow କରାଯିବା ଉଚିତ।
Adapt
Actor ଅନୁଯାୟୀ experience ପରିବର୍ତ୍ତନ କରନ୍ତୁ। human-shaped interface ପରିବର୍ତ୍ତେ verified agent ପାଇଁ structured API response କିମ୍ବା ପୃଷ୍ଠାର Markdown version ସର୍ଭ୍ କରନ୍ତୁ। serving AI agents structured content ଉପରେ guide ଏହି pattern କୁ କଭର୍ କରେ।
Challenge
ଅଧିକ ଶକ୍ତ କିଛି ମାଗନ୍ତୁ: ନୂଆ login, ଅତିରିକ୍ତ credential, account owner ଠାରୁ confirmation। ଯେ route ଗୁଡ଼ିକରେ ଭୁଲ ନିଷ୍ପତ୍ତିର ମୂଲ୍ୟ ଅଧିକ, ସେଠାରେ challenge ବ୍ୟବହାର କରନ୍ତୁ।
Review
Action କୁ ସିଧାସଳଖ completion କୁ ନ ପଠାଇ queue ଭିତରକୁ ଯାଇବାକୁ ଦିଅନ୍ତୁ, କିମ୍ବା human ଦ୍ୱାରା check କରିବା ପାଇଁ flag କରନ୍ତୁ। Blocking legitimate user ମାନଙ୍କୁ କ୍ଷତି କରିବ, କିନ୍ତୁ unattended completion ଅତ୍ୟଧିକ risky ହେବ, ସେଠାରେ review ଉପଯୋଗୀ।
Limit
Actor ଏବଂ route ଅନୁଯାୟୀ ସମଞ୍ଜସ୍ୟ rate କିମ୍ବା volume limit ଲାଗୁ କରନ୍ତୁ, ଯାହାଦ୍ୱାରା automated caller ମାନେ ଲୋକଙ୍କ ପାଇଁ ଡିଜାଇନ୍ ହୋଇଥିବା workflow କୁ overflow କରିପାରିବେ ନାହିଁ।
robots.txt କାହିଁକି access policy ନୁହେଁ
ଅନେକ team robots.txt ରୁ ଆରମ୍ଭ କରନ୍ତି, ଏବଂ crawler ପାଇଁ ସେଟା ଏକ sensible ପ୍ରଥମ signal। କିନ୍ତୁ ସେଟା agent ପାଇଁ access policy ନୁହେଁ। crawler operator ଭିନ୍ନ user agent ପାଇଁ ଭିନ୍ନ behavior document କରନ୍ତି: Anthropic କହିଛି ଯେ ତାଙ୍କ bot ମାନେ robots.txt directive କୁ honor କରନ୍ତି (Anthropic crawler documentation), ଯେତେବେଳେ OpenAI କହିଛି ଯେ ChatGPT-User ପାଇଁ, ଯେଉଁଟି user ChatGPT କୁ ପ୍ରଶ୍ନ କଲେ କାର୍ଯ୍ୟ କରେ, robots.txt rule ଲାଗୁ ହୋଇନପାରେ କାରଣ action ଟି user ଦ୍ୱାରା initiated (OpenAI crawler documentation)। robots.txt API, MCP tool କିମ୍ବା signed-in workflow ବିଷୟରେ କିଛି କହେ ନାହିଁ।
Access policy request ହାତଲ ହେଉଥିବା ସ୍ଥାନରେ run ହେବା ଦରକାର, RFC 9421 ଅଧୀନରେ checked signature ପରି evidence ପଢ଼ିବା ଦରକାର, ଏବଂ ପ୍ରତ୍ୟେକ route ପାଇଁ response ବାଛିବା ଦରକାର। MCP server ପାଇଁ, MCP authorization specification ନିର୍ଦ୍ଦେଶ କରେ ଯେ client କିପରି HTTP ମାଧ୍ୟମରେ access token ପାଉଛନ୍ତି; actor policy ସେଥିର ଉପରେ context ଯୋଡ଼େ, ଏହାକୁ ପରିବର୍ତ୍ତନ କରେ ନାହିଁ।
Proof of Actor କିପରି ଆପଣଙ୍କ policy କୁ feed କରେ
ଆପଣଙ୍କ integration ଯେକୌଣସି request ବିଶ୍ଳେଷଣ କଲେ ଚାରିଟି ଅଂଶ ସହ actor result ମିଳେ, ଯାହାକୁ ଆପଣଙ୍କ policy ପଢ଼ିପାରେ:
- Class: Human, Human + AI, Agent କିମ୍ବା Unknown.
- Basis: verified, declared, inferred କିମ୍ବା unknown, ଯାହାଦ୍ୱାରା ଆପଣଙ୍କ policy validated signature କୁ self-declared client name ଠାରୁ ଭିନ୍ନ ଭାବେ ହାତଲ କରିପାରେ।
- Evidence summary: result କ'ଣ ଆଧାରରେ ଅଛି, ତାହାର readable description, logging ଏବଂ review ପାଇଁ ଉପଯୋଗୀ।
- Context: କେଉଁ integration ଏବଂ କେଉଁ route ଏହାକୁ produce କଲା।
Basis ସ୍ପଷ୍ଟ ଥିବାରୁ, ଆପଣଙ୍କ policy ଅତ୍ୟନ୍ତ ସଠିକ ହୋଇପାରେ। "Allow agents" ର ଅର୍ଥ ହୁଏ "read route ଉପରେ verified agent ମାନଙ୍କୁ allow କରନ୍ତୁ, declared agent ମାନଙ୍କୁ rate-limit କରନ୍ତୁ, ଅନ୍ୟ ସବୁଥିରେ Unknown fallback ଲାଗୁ କରନ୍ତୁ।" request ଠାରୁ decision ପର୍ଯ୍ୟନ୍ତ ସମ୍ପୂର୍ଣ୍ଣ flow How It Works ଉପରେ ବର୍ଣ୍ଣିତ।
Fallback policy ର ଅଂଶ
ଯେତେବେଳେ evidence ନାହିଁ, policy କେମିତି କାମ କରେ, ସେଠି ହିଁ ତାହାର ମୂଲ୍ୟ। Proof of Actor ସେଇ ଅବସ୍ଥାଗୁଡ଼ିକୁ hide କରିବା ପରିବର୍ତ୍ତେ explicit କରେ।
- Unknown: evidence determination କୁ support କରିଲା ନାହିଁ। ପ୍ରତ୍ୟେକ route ରେ Unknown ର ଅର୍ଥ କ'ଣ, ଆପଣଙ୍କ policy କହିଥାଏ। ଏହା କଦାପି Human କୁ convert ହୁଏ ନାହିଁ ଏବଂ default ଭାବେ malicious ବୋଲି ଧରାଯାଏ ନାହିଁ।
- Timeout: result ସମୟରେ ଆସିଲା ନାହିଁ। ଆପଣଙ୍କ integration ସେ route ପାଇଁ ଚୟନ କରିଥିବା fallback ଲାଗୁ କରେ।
- Missing signals: collector run କଲା ନାହିଁ କିମ୍ବା ଗୋଟିଏ header ଅନୁପସ୍ଥିତ ଥିଲା। result ସେହିଥିରେ ପ୍ରତିବିମ୍ବିତ କରେ, ଏବଂ ଆପଣଙ୍କ policy ସେହି ଅନୁଯାୟୀ ହାତଲ କରେ।
ପ୍ରତ୍ୟେକ route ପାଇଁ ଆପଣ fail open କିମ୍ବା fail closed ବାଛନ୍ତି। Fail open ର ଅର୍ଥ request Proof of Actor ନଥିଲେ ଯେପରି ଚାଲିବ, ସେପରି ଚାଲିବ; fail closed ର ଅର୍ଥ ଆପଣଙ୍କ existing stronger check ଲାଗୁ ହେବ। Low-risk route ସାଧାରଣତଃ fail open ହୁଏ। Sensitive action ସାଧାରଣତଃ fail closed ହୁଏ। ଆପଣ ଏହାକୁ ସାର୍ବଜନୀନ ଭାବେ ନୁହେଁ, risk tier ଅନୁଯାୟୀ ସେଟ୍ କରନ୍ତୁ।
Identity, credential ଏବଂ authorization କୁ ଅଲଗା ରଖନ୍ତୁ
Agent access policy ତିନୋଟି ସ୍ପଷ୍ଟ layer ର ଉପରେ ବସିଥାଏ, ଏବଂ ସେଗୁଡ଼ିକୁ ଅଲଗା ରଖିବା ସବୁଠାରୁ କ୍ଷତିକାରକ ଭୁଲକୁ ରୋକେ।
- Identity evidence କହେ କେଉଁ ପ୍ରକାରର actor call କରୁଛି ଏବଂ କ'ଣ ତାହା ପ୍ରମାଣ କରୁଛି। Proof of Actor ଏହା ଯୋଗାଇଥାଏ।
- Credentials କହେ କେଉଁ account ଦାୟୀ। ଆପଣଙ୍କ session, token କିମ୍ବା API key ଏହା ଯୋଗାଇଥାଏ।
- Authorization କହେ ଏହି caller କି ଏହି action କରିପାରିବ। ଆପଣଙ୍କ permission model ଏହା ଯୋଗାଇଥାଏ।
Verified agent identity ର ଅର୍ଥ agent authorized, କିମ୍ବା person ଏହାକୁ authority ଦେଇଛି, କିମ୍ବା ତାହାର action safe, ଏହା ନୁହେଁ। Actor result କୁ routing ଏବଂ context ଯୋଗାଇବା ପାଇଁ ବ୍ୟବହାର କରନ୍ତୁ। Permission ଦେବା ପାଇଁ ଆପଣଙ୍କ authorization model ବ୍ୟବହାର କରନ୍ତୁ। Detection & Limitations ପୃଷ୍ଠା ସ୍ପଷ୍ଟ କରେ ପ୍ରତ୍ୟେକ ପ୍ରକାରର evidence କ'ଣ establish କରିପାରେ।
କିଛି ଭାଙ୍ଗିବା ଛଡ଼ା rollout କରନ୍ତୁ
Agent access policy ପରିଚୟ କରାଇବାର ସବୁଠାରୁ ସୁରକ୍ଷିତ ଉପାୟ ହେଉଛି ପର୍ଯ୍ୟାୟରେ।
- Observe. observation mode ରେ Proof of Actor install କରନ୍ତୁ। ଆପଣଙ୍କ user ପାଇଁ କିଛି ବଦଳେ ନାହିଁ; result ରେକର୍ଡ ହୁଏ।
- Understand. କେଉଁ actor କେଉଁ route ବ୍ୟବହାର କରୁଛି, ପ୍ରତ୍ୟେକର unknown rate କେତେ, ଏବଂ ଆପଣ ଯାହା ଜାଣନ୍ତି ତାହା ସହ ବିରୋଧ କରୁଥିବା result ମାନେ review କରନ୍ତୁ।
- Preview. ପଲିସିକୁ preview ରେ ଚଳାନ୍ତୁ, enforce ନ କରି ସେ କ'ଣ କରିଥାନ୍ତା ତାହା log କରନ୍ତୁ।
- Enforce narrowly. Evidence ସ୍ପଷ୍ଟ ଭାବେ ସମର୍ଥନ କରୁଥିବା ଗୋଟିଏ route ରେ ପଲିସି ସକ୍ରିୟ କରନ୍ତୁ। outcome ଉପରେ ନଜର ରଖନ୍ତୁ।
- Expand. Confidence ବଢ଼ିବା ସହ ଅଧିକ route କୁ ବିସ୍ତାର କରନ୍ତୁ।
rolling out actor-aware policies safely ଉପରେ guide ପ୍ରତ୍ୟେକ stage ମାଧ୍ୟମରେ ନେଇଯାଏ, ଏବଂ protecting sensitive actions without blocking agents high-stakes route ଗୁଡ଼ିକୁ କଭର୍ କରେ।
ଆପଣଙ୍କ team କ'ଣ ପାଏ
Proof of Actor ସହ, ଆପଣଙ୍କ team କୁ ତିନୋଟି capability ସହ ଗୋଟିଏ integration ମିଳେ। Detect actor signal ସଂଗ୍ରହ କରେ ଏବଂ verified assertion କୁ inference ଠାରୁ ଅଲଗା କରେ। Understand actor analytics, trend ଏବଂ ପ୍ରତ୍ୟେକ result ର ପଛର evidence ଦେଖାଏ, Unknown ଦୃଶ୍ୟମାନ ରହିଥାଏ। Route ଆପଣଙ୍କୁ ଏହି ପୃଷ୍ଠାରେ ବର୍ଣ୍ଣିତ policy ଲେଖିବାକୁ ଏବଂ ଆପଣ ଚୟନ କରିଥିବା ସ୍ଥାନରେ ଲାଗୁ କରିବାକୁ ଦେଇଥାଏ। private beta ସମୟରେ, routing policy ପ୍ରତ୍ୟେକ founding team ସହିତ ଡିଜାଇନ୍ ହୁଏ ଏବଂ ଆପଣଙ୍କ ନିଜ application code ରେ ଚାଲେ, ତେଣୁ ଆପଣ ସମ୍ପୂର୍ଣ୍ଣ control ରଖନ୍ତି।
Avoid କରିବାକୁ ସାଧାରଣ policy ଭୁଲ
ପ୍ରଥମ ଥର agent access ଡିଜାଇନ୍ କରୁଥିବା team ଗୋଟିଏ ହାତଗଣିତିକ ଭୁଲ ପୁନରାବୃତ୍ତି କରିଥାନ୍ତି। ସେଗୁଡ଼ିକୁ avoid କରିବା rework ର ସପ୍ତାହ ବଞ୍ଚାଇଦିଏ।
- Default ଭାବେ ପ୍ରତ୍ୟେକ agent କୁ block କରିବା। Legitimate agent ପରେ ଆପଣଙ୍କୁ ଏଡ଼ାଇ ଯାନ୍ତି, ପ୍ରାୟତଃ ଲୋକଙ୍କ ପାଇଁ ତିଆରି interface କୁ scrape କରି, ଯାହାକୁ structured path ଠାରୁ ରକ୍ଷା କରିବା ଅଧିକ କଠିନ।
- Declared name ଉପରେ trust କରିବା। କେବଳ ନିଜକୁ ନାମକରଣ କରୁଥିବା client ଏକ claim କରିଛି, proof ଦେଇନାହିଁ। ଏକ unverified caller ପାଇଁ ଆପଣ ଯେପରି treatment ଦେବେ, ସେପରି treatment ଦିଅନ୍ତୁ।
- ସବୁଠାରେ ଗୋଟିଏ fallback ବ୍ୟବହାର କରିବା। Public pricing page ରେ Unknown ଏବଂ password change ରେ Unknown ଦୁଇଟି ଭିନ୍ନ ପରିସ୍ଥିତି। ପ୍ରତ୍ୟେକ route ପାଇଁ ନିଜ answer ଦରକାର।
- Inference ରୁ ଲୋକଙ୍କ ବିଷୟରେ ନିଷ୍ପତ୍ତି ନେବା। Actor result routing ପାଇଁ context, individual ଉପରେ verdict ନୁହେଁ। Consequential decision ଏବଂ review କୁ ଆପଣଙ୍କ ନିଜ control ରେ ରଖନ୍ତୁ।
- Observation skip କରିବା। Day one ରୁ enforce କଲେ false positive କୁ customer complaint ମାଧ୍ୟମରେ ଆପଣ ଜାଣିବେ। ପ୍ରଥମେ observe କରନ୍ତୁ, ପରେ evidence ସ୍ପଷ୍ଟ ଥିବା ସ୍ଥାନରେ enforce କରନ୍ତୁ।
ପ୍ରତ୍ୟେକ enforcement step ପୂର୍ବରୁ ଆପଣଙ୍କ security, product ଏବଂ support lead ସହିତ ଏକ ସଂକ୍ଷିପ୍ତ policy review ଏହି ଅଧିକାଂଶ ଭୁଲକୁ ପୂର୍ବରୁ ଧରିଦିଏ।
founding developer program ସହିତ ଆରମ୍ଭ କରନ୍ତୁ
Proof of Actor private beta ରେ ଅଛି। selected founding development team ମାନେ agreed usage limit ମଧ୍ୟରେ up to 12 months free access ଏବଂ ଆପଣ ପ୍ରଥମ policy ଡିଜାଇନ୍ କରୁଥିବା ସମୟରେ ଆମ engineer ମାନଙ୍କର direct support ପାଇପାରିବେ।
ଆପଣଙ୍କ application AI agent ମାନଙ୍କୁ କିପରି ହାତଲ କରିବା ଉଚିତ, ସେଥିରେ ଯଦି ଆପଣ ନିଷ୍ପତ୍ତି ନେଉଛନ୍ତି, apply for early access କରନ୍ତୁ। କେଉଁ route ଅତ୍ୟଧିକ important ଏବଂ କେଉଁ decision ନେବାକୁ ଆପଣ ଚାହୁଁଛନ୍ତି, ଆମକୁ କହନ୍ତୁ, ଆମେ ଆପଣଙ୍କୁ ଉପଯୋଗୀ policy ତିଆରି କରିବାରେ ସହଯୋଗ କରିବୁ। ଏହା APIs ଏବଂ MCP servers ଉପରେ କିପରି ଲାଗୁ ହୁଏ, ସେଥିମଧ୍ୟ ଦେଖିପାରିବେ।
Sources
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
- Overview of OpenAI crawlers, OpenAI.
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- MCP authorization, modelcontextprotocol.io.