ମୁଖ୍ୟ ବିଷୟବସ୍ତୁକୁ ଛାଡ଼ନ୍ତୁ
ଶିଖନ୍ତୁଶବ୍ଦକୋଷଏଜେଣ୍ଟ ଖର୍ଚ୍ଚ ନୀତି
ଶବ୍ଦକୋଷ

ଏଜେଣ୍ଟ ବ୍ୟୟ ନୀତି କଣ।

ପରିଭାଷା

ଏକ agent spend policy ହେଉଛି AI-agent wallet ସହିତ ଯୋଡ଼ାଯାଇଥିବା rules ର ସମୁଚ୍ଚୟ, ଯାହା agent କ’ଣ ପେମେଣ୍ଟ କରିବାକୁ ଅନୁମତି ପାଏ ତାହା ନିୟନ୍ତ୍ରଣ କରେ - per-period allowance (daily, weekly, କିମ୍ବା monthly), per-transaction cap, ଏବଂ start ଏବଂ end dates ସହିତ validity window। policy dashboard ରେ set ହୁଏ ଏବଂ wallet API layer ରେ enforced ହୁଏ (agent ର manipulable scope ର ବାହାରେ), settle ହେବା ପୂର୍ବରୁ ପ୍ରତ୍ୟେକ payment ଉପରେ check କରାଯାଏ। API ଏହାକୁ read-only ଭାବେ ପ୍ରଦର୍ଶନ କରେ।

କାହିଁକି ଏହା ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ

autonomous payment କୁ ସୁରକ୍ଷିତ କରୁଥିବା ଏକମାତ୍ର ଜିନିଷ।

ଏକ ବ୍ୟୟ ନୀତି ବିନା, ଏକ ଏଜେଣ୍ଟକୁ ଏକ ୱାଲେଟ୍ ଦେବା ହେଉଛି ଏକ LLM କୁ ଡଲାର-ନିର୍ଦ୍ଧାରିତ ଚେକ୍‌ବୁକ୍ କୁ ଅସୀମିତ ଆକ୍ସେସ୍ ଦେବା। ଦୁଇଟି ବିଫଳତା ମୋଡ୍ ଅବଶ୍ୟ ଘଟିବ। ପ୍ରଥମଟି ହେଉଛି ରନଅୱେ ଲୁପ୍: ଏକ ଏଜେଣ୍ଟର ପ୍ଲାନର୍ ଏକ ପେଡ୍ ଟୁଲ୍ କୁ ପୁନରାବୃତ୍ତି କରିବାରେ ଫସିଯାଏ ଏବଂ କିଛି ମିନିଟ୍ ମଧ୍ୟରେ କାର୍ଯ୍ୟସ୍ଥଳର ବ୍ୟାଲେନ୍ସ କୁ ଜଳାଇଦେଇଥାଏ। ଦ୍ୱିତୀୟଟି ହେଉଛି ପ୍ରମ୍ପ୍ଟ ଇଞ୍ଜେକ୍ସନ୍: ଏକ ଆକ୍ରମଣକାରୀ ଏଜେଣ୍ଟକୁ ଏକ ଆକ୍ରମଣକାରୀ-ନିୟନ୍ତ୍ରିତ ୱାଲେଟ୍ କୁ ଦେୟ କରିବାକୁ ବିଶ୍ବାସ କରାଏ ଯାହା ସାଧାରଣ କାମ ଭାବରେ ଦେଖାଯାଏ।

ଏକ ଖର୍ଚ୍ଚ ନୀତି ନିର୍ମାଣ ଦ୍ୱାରା ଦୁଇଟି ବିଫଳତା ମୋଡ୍କୁ ସୀମିତ କରେ। ଅବ୍ୟବହାର ଲୁପ୍ ସମୟ ଅନୁମତିକୁ ନିଷ୍ପ୍ରଭ କରେ ଏବଂ ବନ୍ଦ କରେ। ଇଞ୍ଜେକ୍ଟ କରାଯାଇଥିବା ଦେୟ ପର-ଲେନଦେନ ସୀମାକୁ (କିମ୍ବା ବାକୀ ଅନୁମତି) ଅତିକ୍ରମ କରେ ଏବଂ କେବେ ବସିବାକୁ ନାହିଁ। ଏଜେଣ୍ଟକୁ ସଂପୂର୍ଣ୍ଣ ବିଶ୍ୱସନୀୟ ହେବା ଆବଶ୍ୟକ ନୁହେଁ କାରଣ ୱାଲେଟ୍ ନୀତି ବାହାରେ କିଛି ବସିବାକୁ ଅସ୍ୱୀକୃତ କରେ। ଏହା 'ଦେୟ କରୁଥିବା ଏଜେଣ୍ଟ' ଉତ୍ପାଦନରେ ବ୍ୟବହାର କରାଯିବା ଏବଂ ଏକ ପରୀକ୍ଷା ହେବାର ମଧ୍ୟରେ ତଫାତ।

କେମିତି ଏହା କାମ କରେ

ଏକ ଥର ସଂରଚନା କରନ୍ତୁ, ପ୍ରତି କଲ୍ ମୂଲ୍ୟାଙ୍କନ କରନ୍ତୁ।

  1. Configure. ମାନବ user dashboard ରେ policy ସେଟ୍ କରନ୍ତି: per-period allowance, per-transaction cap, ଏବଂ ଏକ ଇଚ୍ଛାନୁସାରେ validity window (ଆରମ୍ଭ ଏବଂ ଶେଷ ତାରିଖ)। API policy କୁ read-only ଭାବେ expose କରେ; ପରିବର୍ତ୍ତନଗୁଡ଼ିକ audit-logged ହୁଏ।
  2. Bind to identity. ନୀତି ଏଜେଣ୍ଟର ଭୁଗତାନ ପରିଚୟକୁ ଲଗାଇଥାଏ। ମଲ୍ଟି-ଏଜେଣ୍ଟ ଓର୍କସ୍ପେସ୍ ପ୍ରତ୍ୟେକ ଏଜେଣ୍ଟ ପାଇଁ ଏକ ନୀତି ରହିଛି, ତାହା ସହିତ ବିକଳ୍ପ ଭାବେ ଏକ ଓର୍କସ୍ପେସ୍-ସ୍ତର କ୍ୟାପ୍ ଯାହା ମୋଟକୁ ସୀମିତ କରେ।
  3. ପ୍ରତ୍ୟେକ intent ଉପରେ ମୂଲ୍ୟାୟନ କରନ୍ତୁ। ଯେତେବେଳେ agent ଏକ payment intent ଦାଖଲ କରେ (ସାଧାରଣତଃ 402 response ଦ୍ୱାରା ଚାଳିତ), wallet API policy କାର୍ଯ୍ୟାନ୍ବୟନ କରେ: per-transaction cap ଯାଞ୍ଚ କରନ୍ତୁ, remaining period allowance ଯାଞ୍ଚ କରନ୍ତୁ, validity window ଯାଞ୍ଚ କରନ୍ତୁ।
  4. Settle or reject. ସମସ୍ତ checks pass ହେଲେ, wallet payment କୁ settle କରେ ଏବଂ remaining allowance କୁ କମାଏ। କୌଣସି check ବିଫଳ ହେଲେ, wallet payment କୁ reject କରେ (ଏହା limit ଅତିକ୍ରମ କରେ କିମ୍ବା window ବାହାରେ ଥାଏ) ଏବଂ settle କରେ ନାହିଁ।
  5. Audit. ପ୍ରତିଟି ଗ୍ରହଣ କରାଯାଇଥିବା ଏବଂ ପ୍ରତିଟି ଖାରିଜ କରାଯାଇଥିବା ଇଚ୍ଛା ନୀତି ନିଷ୍ପତ୍ତି ସହିତ ଲଗ୍ କରାଯାଏ। ମାନବ ଯେତେବେଳେ ଚାହାଁନ୍ତି ତେବେ ଲଗ୍ ପୁନରାଲୋଚନା କରିପାରିବେ ଯାହା ଏଜେଣ୍ଟ ଚେଷ୍ଟା କରିଥିଲେ ଏବଂ କଣ ନୀତି ଅନୁମତି ଦେଇଥିଲା।

କେତେ agent wallet share କରୁଛନ୍ତି ତାହା ସତ୍ତ୍ୱେ policy ସମାନ ପ୍ରକାରର object ହିଁ। Per-agent policy ବଜେଟ୍ କୁ ସ୍ପଷ୍ଟଭାବେ isolate କରେ; parent level ର workspace policy ସମସ୍ତ child agent ମିଶିଥିବା ଉପରେ ଏକ କଠୋର ceiling ଲାଗୁ କରେ।

ଉଦାହରଣଗୁଡିକ

ତିନି ନୀତି ଆକୃତି ଯାହା ଆମେ ଉତ୍ପାଦନରେ ଦେଖୁଛୁ।

ଉଦାହରଣ 1

ଗୋଟିଏ-କଲ୍ ସିଲିଂ ସହିତ ଏଜେଣ୍ଟ ପ୍ରତି ଦୈନିକ କ୍ୟାପ୍

ଏକ research agent ପାଖରେ $5/day cap ଏବଂ $0.50/call ceiling ଅଛି। ଏହା $0.50 ର 10ଟି call, କିମ୍ବା $0.05 ର 100ଟି call, କିମ୍ବା daily total ମଧ୍ୟରେ ଯେକୌଣସି combination କରିପାରେ। tool ଠାରୁ ଆସିଥିବା ଆଶ୍ଚର୍ଯ୍ୟଜନକ $2.00 invoice call ceiling ରେ settle ହେବା ପୂର୍ବରୁ reject ହୁଏ। ଉଭୟ limit ସମୟକୁ ସକ୍ରିୟ ରହେ; ପ୍ରତି call ରେ tighter one wins।

ଉଦାହରଣ 2

କେବଳ ଗ୍ରହଣ ପାଇଁ lockdown

ଯେଉଁ agent କେବଳ ପେମେଣ୍ଟ ଗ୍ରହଣ କରେ, ତାହାର allowance ଏବଂ per-transaction cap ଦୁଇଟିକୁ ଶୂନ୍ୟ ରେ set କରାଯାଏ। ଏହାକୁ ଯେକୌଣସି ସମୟରେ ଯେକେହି ପେ କରିପାରେ, କିନ୍ତୁ ଏହା USDC କୁ ସମ୍ପୂର୍ଣ୍ଣ ଭାବେ ପଠାଇପାରେ ନାହିଁ - ଏହାର code କିମ୍ବା prompt injection ଯାହା କରିବାକୁ ଚେଷ୍ଟା କଲେ ମଧ୍ୟ। ଦୁଇଟି limit କୁ ଶୂନ୍ୟ ରେ set କରିବା prompt-injection-driven payment redirection ବିରୁଦ୍ଧରେ ସବୁଠାରୁ ଶକ୍ତିଶାଳୀ defense: wallet ପ୍ରତ୍ୟେକ outgoing payment କୁ ଅସ୍ୱୀକାର କରେ।

ଉଦାହରଣ 3

ସମୟ-ସୀମିତ engagement window

ଏକ contractor agent କୁ ଏମିତି spend permission ଦିଆଯାଏ ଯାହା କେବଳ engagement ର 30-day window ପାଇଁ ବ valid ହୁଏ (ଆରମ୍ଭ ଏବଂ ଶେଷ ତାରିଖ ସହିତ)। window ମଧ୍ୟରେ ସେ ତାହାର weekly allowance ପର୍ଯ୍ୟନ୍ତ spend କରିପାରେ; end date ପରେ permission expire ହୁଏ ଏବଂ ଆଉ କୌଣସି payment settle ହୁଏ ନାହିଁ, କାହାକୁ ମଧ୍ୟ ଏହାକୁ ବନ୍ଦ କରିବାକୁ ମନେ ରଖିବାକୁ ପଡ଼େ ନାହିଁ।

ସାଧାରଣ ପ୍ରଶ୍ନୋତ୍ତର

ତିନି ସାଧାରଣ ପ୍ରଶ୍ନ।

ଖର୍ଚ୍ଚ ନୀତି ଏବଂ ହାର ସୀମାରେ କଣ ତଫାତ?

rate limit call ସଂଖ୍ୟାକୁ ନିୟନ୍ତ୍ରଣ କରେ; spend policy call ଗୁଡ଼ିକର ସମୁଦାୟ dollar value କୁ ନିୟନ୍ତ୍ରଣ କରେ। ଏକ agent କୁ ପ୍ରତିମିନିଟ 100 calls ପାଇଁ rate-limit କରାଯାଇପାରେ, କିନ୍ତୁ ଯଦି ପ୍ରତ୍ୟେକ call $1 ହୋଇଥାଏ ଏବଂ agent ଏହାକୁ ଏକ ଘଣ୍ଟା ଧରି କରେ, workspace ତଥାପି bankrupt ହୋଇପାରେ। spend policy call ସଂଖ୍ୟା ନିର୍ବିଶେଷରେ dollar exposure କୁ cap କରେ। ଦୁଇଟି control ପରସ୍ପରକୁ ପୂରକ - rate limits agent runtime ଉପରେ denial-of-service କୁ ରୋକେ, spend policies agent ର wallet ଉପରେ denial-of-funds କୁ ରୋକେ।

ନୀତି କେଉଁଠି ଲାଗୁ କରାଯାଏ - ଏଜେଣ୍ଟ କୋଡ୍‌ରେ କିମ୍ବା ବାଲେଟ୍‌ରେ?

ୱାଲେଟ୍‌ରେ, ପେମେଣ୍ଟ API ଲେୟରରେ। ଏହାକୁ ଏଜେଣ୍ଟ କୋଡ୍‌ରେ ଲାଗୁ କରିବାରୁ ଅର୍ଥ ହେଉଛି କୌଣସି ପ୍ରମ୍ପ୍ଟ-ଇଞ୍ଜେକ୍ସନ୍ ଆକ୍ରମଣ ଯାହା ଏଜେଣ୍ଟର ପ୍ଲାନରକୁ ବାଇପାସ୍ କରେ ସେହି ବଜେଟ୍‌କୁ ବାଇପାସ୍ କରେ। ଏହାକୁ ୱାଲେଟ୍ API ମାଧ୍ୟମରେ ଲାଗୁ କରିବା ଦ୍ୱାରା, ନୀତି ଏଜେଣ୍ଟର ମାନିପୁଲେବଲ୍ ସ୍କୋପ୍‌ରୁ ବାହାର। ଏଜେଣ୍ଟ ଏକ ପେମେଣ୍ଟ ଇଣ୍ଟେଣ୍ଟ ସମର୍ପଣ କରେ; ୱାଲେଟ୍ ନୀତି ସହିତ ଇଣ୍ଟେଣ୍ଟକୁ ମୂଲ୍ୟାଙ୍କନ କରେ; ୱାଲେଟ୍ କିମ୍ବା ନିଷ୍ପତ୍ତି କରେ କିମ୍ବା ଖାରିଜ କରେ। ଏଜେଣ୍ଟ ତାଙ୍କର ନିଜସ୍ୱ ସୀମା ବୃଦ୍ଧି କରିପାରିବେ ନାହିଁ।

ଯଦି କୌଣସି ବୈଧ ବ୍ୟୟ ଅସ୍ବୀକୃତ ହୁଏ, ତେବେ ବ୍ୟବହାରକାରୀ ମଧ୍ୟରେ ନୀତିକୁ ସମଯୋଜନ କରିପାରିବ କି?

ହଁ, କିନ୍ତୁ କେବଳ human user (କିମ୍ବା ଅନ୍ୟ authorized human) ଏହାକୁ ଠିକ୍ କରିପାରେ - agent ନିଜେ କଦାପି ନୁହେଁ। wallet ର admin panel policy editor କୁ ଦେଖାଏ; changes କେ ଏବଂ କେବେ କଲା ତାହା audit-logged ହୁଏ। ଏହା agent କୁ default ଭାବରେ guardrails ଭିତରେ ରଖେ, ଯେତେବେଳେ legitimate ବଡ଼ spend ଆସେ ସେତେବେଳେ human କୁ ଆବଶ୍ୟକ override ଦେଇଥାଏ। agent ତାହାର planning loop ଭିତରେ 'please raise my limit' ପଚାରିବାର ଉପାୟ ପାଉନାହିଁ, କାରଣ ଏହା limit ର ଉଦ୍ଦେଶ୍ୟକୁ ନଷ୍ଟ କରିଦେବ।
ଶେଷ ସମୀକ୍ଷା: 2026-05-15. CC BY 4.0 ଅନୁସାରେ ପ୍ରକାଶିତ।

ଆପଣଙ୍କର ଏଜେଣ୍ଟକୁ ଏକ ବଜେଟ୍ ଖୋଲା ଦିଅନ୍ତୁ।

ପରିୟୋଜନା ଅନୁମତି ଓ ପର-ଲେନଦେନ କ୍ୟାପ୍, ଡ୍ୟାସ୍‌ବୋର୍ଡରେ ସେଟ୍ କରାଯାଇଛି। ଆରମ୍ଭ କରିବାକୁ ମାଗଣା।