ਏਜੰਟ ਖਰਚ ਨਿਯੰਤਰਣ ਸੈਟ ਕਰੋ ਜੋ ਪ੍ਰੰਪਟ ਇੰਜੈਕਸ਼ਨ ਨੂੰ ਸਹਾਰਦੇ ਹਨ।
ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਖਰਚ ਕਰਨ ਦੀ ਆਗਿਆ ਸੈਟ ਕਰੋ - ਇੱਕ ਪ੍ਰਤੀ ਅਵਧੀ ਆਗਿਆ ਅਤੇ ਪ੍ਰਤੀ ਲੈਨ ਕੈਪ - ਅਤੇ ਬੈਕਐਂਡ ਹਰ ਭੁਗਤਾਨ 'ਤੇ ਇਸਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ ਇਹ ਬੈਕਐਂਡ 'ਤੇ ਰਹਿੰਦੀ ਹੈ ਅਤੇ API ਪੜ੍ਹਨ ਲਈ ਸਿਰਫ ਹੈ, ਪ੍ਰੰਪਟ ਇੰਜੈਕਸ਼ਨ ਜੋ ਏਜੰਟ ਦੇ ਯੋਜਕ ਨੂੰ ਹਾਈਜੈਕ ਕਰਦਾ ਹੈ ਫਿਰ ਵੀ ਸੀਮਾ ਨਹੀਂ ਵਧਾ ਸਕਦਾ। ਤੁਹਾਡਾ ਕੋਡ API ਰਾਹੀਂ ਆਗਿਆ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਤਾਂ ਜੋ ਇਸਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰ ਸਕੇ ਜਾਂ ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਯੋਜਨਾ ਬਣਾਉਂਦਾ ਹੈ।
ਤੁਸੀਂ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।
- ਇੱਕ ਮੌਜੂਦਾ ਏਜੰਟ (ਦੇਖੋ add-payments-to-agent guide).
- ਏਜੰਟ ਦੇ ਮਾਲਕ ਕੰਮਕਾਜ ਲਈ ਡੈਸ਼ਬੋਰਡ ਦੀ ਪਹੁੰਚ - ਅਨੁਮਤੀਆਂ ਉੱਥੇ ਸੈੱਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਨਾ ਕਿ API ਰਾਹੀਂ।
- ਉਮੀਦ ਕੀਤੀ ਰੋਜ਼ਾਨਾ ਖਰਚ ਦਾ ਇੱਕ ਖਰਾਬ ਵਿਚਾਰ - ਆਗਿਆ ਨੂੰ 2-3x ਆਮ ਵਰਤੋਂ 'ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, 100x ਨਹੀਂ, ਤਾਂ ਜੋ ਇਹ ਵਾਸਤਵ ਵਿੱਚ ਲੋਡ-ਬੇਅਰਿੰਗ ਹੋਵੇ.
- ਇਜਾਜ਼ਤ ਪੜ੍ਹਨ ਲਈ ਇੱਕ API ਕੁੰਜੀ (ਇੱਕ
sk_test_ਕੁੰਜੀ ਇਸ ਗਾਈਡ ਲਈ ਠੀਕ ਹੈ)। - ਏਜੰਟ ਖਰਚ ਨੀਤੀ ਸੰਕਲਪ ਨਾਲ ਜਾਣੂ ਹੋਣਾ - ਇਹ ਗਾਈਡ ਇਸ ਦਾ ਕਾਰਜਕਾਰੀ ਸਾਥੀ ਹੈ।
ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਆਗਿਆ ਸੈਟ ਕਰੋ।
Blockchain0x ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਏਜੰਟ ਖੋਲ੍ਹੋ ਅਤੇ ਦੋ ਨੰਬਰ ਸੈੱਟ ਕਰੋ: ਇੱਕ ਅਵਧੀ (ਇੱਕ ਦਿਨ, ਇੱਕ ਹਫ਼ਤਾ, ਜਾਂ 30 ਦਿਨ) 'ਤੇ ਇੱਕ ਭੱਤਾ ਅਤੇ ਪ੍ਰਤੀ-ਲੈਣ-ਦੇਣ ਸੀਮਾ। ਭੱਤਾ ਪੂਰੀ ਅਵਧੀ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਖਰਚ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ; ਪ੍ਰਤੀ-ਲੈਣ-ਦੇਣ ਸੀਮਾ ਇੱਕੋ ਹੀ ਅਸਧਾਰਣ ਬੇਨਤੀ ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਾਰਾ ਖਰਚ ਕਰਨ ਤੋਂ ਰੋਕਦੀ ਹੈ। ਇਹ ਜਾਣਬੂਝ ਕੇ ਡੈਸ਼ਬੋਰਡ ਕਾਰਵਾਈ ਹੈ - ਇਹ ਮਨੁੱਖ-ਸੈੱਟ ਕੀਤੀ ਸੀਮਾ ਹੈ ਜਿਸ ਵਿੱਚ ਏਜੰਟ ਚੱਲਦਾ ਹੈ।
Amounts are USDC base units (6 decimals). An allowance_wei of "20000000" is 20 USDC; a per_tx_wei of "2000000" is 2 USDC. The period is a period_seconds value: 86400 for a day, 604800 for a week, 2592000 for 30 days.
API ਰਾਹੀਂ ਆਗਿਆ ਪੜ੍ਹੋ।
ਤੁਹਾਡਾ ਕੋਡ ਜੀਵੰਤ ਆਗਿਆ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਇਸਨੂੰ UI ਵਿੱਚ ਦਿਖਾ ਸਕੇ ਜਾਂ ਏਜੰਟ ਨੂੰ ਇਹ ਜਾਂਚਣ ਦੇ ਸਕੇ ਕਿ ਭੁਗਤਾਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿੰਨਾ ਕਮਰਾ ਬਾਕੀ ਹੈ। ਰੂਟ ਪੜ੍ਹਨ ਲਈ ਹੀ ਹੈ - ਕੋਈ ਬਦਲਣ ਵਾਲਾ ਐਂਡਪੋਇੰਟ ਨਹੀਂ ਹੈ, ਜੋ ਕਿ ਇਸੀ ਲਈ ਹੈ ਕਿ ਏਜੰਟ ਦੀ ਕੁੰਜੀ ਆਪਣੀ ਸੀਮਾ ਨੂੰ ਵਿਆਪਕ ਨਹੀਂ ਕਰ ਸਕਦੀ।
curl https://api.blockchain0x.com/v1/agents/agt_123/spend-permissions \
-H "Authorization: Bearer $BLOCKCHAIN0X_API_KEY"{
"allowance_wei": "20000000",
"per_tx_wei": "2000000",
"period_seconds": 86400,
"start_at": "2026-05-15T00:00:00Z",
"end_at": null,
"revoked_at": null
}ਇਸਨੂੰ ਸਮੇਂ ਵਿੱਚ ਬੰਨ੍ਹੋ, ਜਾਂ ਰੱਦ ਕਰੋ।
ਦੋ ਖੇਤਰ ਆਗਿਆ ਨੂੰ ਸਮੇਂ-ਬੱਧ ਨਿਯੰਤਰਣ ਵਿੱਚ ਬਦਲਦੇ ਹਨ। start_at ਅਤੇ end_at ਉਸ ਵਿੰਡੋ ਨੂੰ ਸੈਟ ਕਰਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਇਹ ਜੀਵੰਤ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਇੱਕ ਸ਼ਡਿਊਲ ਕੀਤੇ ਕੰਮ ਲਈ ਬਜਟ ਪੂਰਵ-ਪੰਕਤ ਕਰ ਸਕੋ ਜਾਂ ਇੱਕ ਨੂੰ ਆਪਣੇ ਆਪ ਸਮਾਪਤ ਹੋਣ ਦੇ ਲਈ ਛੱਡ ਸਕੋ; ਵਿੰਡੋ ਦੇ ਬਾਹਰ ਇਹ ਕੁਝ ਵੀ ਅਧਿਕਾਰਿਤ ਨਹੀਂ ਕਰਦਾ। revoked_at ਮਾਰਨ ਵਾਲਾ ਸਵਿੱਚ ਹੈ: ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਰੱਦ ਕਰੋ ਅਤੇ ਆਗਿਆ ਕਿਸੇ ਵੀ ਭੁਗਤਾਨ ਲਈ ਜੇਕਰ ਬਾਅਦ ਵਿੱਚ ਮੁਲਾਂਕਣ ਕੀਤਾ ਗਿਆ ਤਾਂ ਜ਼ੀਰੋ 'ਤੇ ਡ੍ਰਾਪ ਕਰਦੀ ਹੈ।
ਇੱਕ ਮੁਸ਼ਕਲ ਰੋਕਣ ਲਈ, apiKeys.revoke ਜਾਂ apiKeys.rotate ਨਾਲ ਏਜੰਟ ਦੀ API ਕੁੰਜੀ ਨੂੰ ਰੱਦ ਕਰੋ ਜਾਂ ਘੁਮਾਓ - ਜੋ ਕਿ ਪਛਾਣ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ ਖਰਚ। ਅਨੁਮਤੀ ਰੱਦ ਕਰਨਾ ਸਰਜੀਕਲ ਚਾਲ ਹੈ; ਕੁੰਜੀ ਰੱਦ ਕਰਨਾ ਮਾਰਨ ਵਾਲਾ ਸਵਿੱਚ ਹੈ।
ਇੱਕ ਭੁਗਤਾਨ ਸੰਭਾਲੋ ਜੋ ਸੀਮਾ ਨੂੰ ਪਹੁੰਚਦਾ ਹੈ।
ਜਦੋਂ ਕੋਈ payment active permission ਤੋਂ ਵੱਧ ਹੋਵੇ, backend chain ਨੂੰ ਕੁਝ ਵੀ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇਸਨੂੰ reject ਕਰ ਦਿੰਦਾ ਹੈ - ਕੋਈ funds ਨਹੀਂ ਹਿਲਦੇ। ਤੁਹਾਡੀ payments.create call ਇੱਕ error ਵਾਪਸ ਕਰਦੀ ਹੈ; ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ failed call ਵਾਂਗ handle ਕਰੋ, operator ਨੂੰ ਦਿਖਾਓ, ਅਤੇ ਉਸੇ ਰੁਕਾਵਟ ਵਿੱਚ ਅੰਧੇਵਾਂ retry ਨਾ ਕਰੋ।
ਇੱਕ ਏਜੰਟ ਨੇ ਕੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਇਹ ਦੇਖਣ ਲਈ, ਡੈਸ਼ਬੋਰਡ ਦੇ ਗਤੀਵਿਧੀ ਲੌਗ ਨੂੰ ਦੇਖੋ ਅਤੇ ਵਾਸਤਵਿਕ ਚਲਾਅ ਨੂੰ transactions.get ਨਾਲ ਮੁੜ ਮਿਲਾਓ। ਰੱਦ ਕੀਤੀ ਕੋਸ਼ਿਸ਼ਾਂ ਦਾ ਇੱਕ ਬਰਸਤ ਤੁਹਾਡਾ ਪਹਿਲਾਂ ਤੋਂ ਚੇਤਾਵਨੀ ਸੰਕੇਤ ਹੈ: ਜਾਂ ਤਾਂ ਇੱਕ ਗਲਤ ਸੰਰਚਿਤ ਆਗਿਆ, ਇੱਕ ਭੱਜਦੀ ਲੂਪ, ਜਾਂ ਇੱਕ ਇੰਜੈਕਸ਼ਨ ਪ੍ਰੋਬ। ਇਸ 'ਤੇ ਚੇਤਾਵਨੀ ਦੇਣਾ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਜਿਵੇਂ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਫੇਲ੍ਹ ਕਾਲਾਂ ਦੇ ਸਪਾਈਕ 'ਤੇ ਕਰੋਗੇ।
ਪੰਜ ਗਲਤੀਆਂ ਜੋ ਨਿਯੰਤਰਣ ਨੂੰ ਹਰਾ ਦਿੰਦੀਆਂ ਹਨ।
ਬੈਕਐਂਡ ਦੇ ਬਜਾਏ ਏਜੰਟ ਕੋਡ ਵਿੱਚ ਖਰਚ ਸੀਮਾ ਰੱਖਣਾ
Agent ਦੇ planner ਜਾਂ system prompt ਵਿੱਚ spend rules security boundaries ਨਹੀਂ ਹਨ। ਇੱਕ prompt-injection attack ਜੋ planner ਨੂੰ override ਕਰਦਾ ਹੈ, cap ਨੂੰ ਵੀ override ਕਰ ਦਿੰਦਾ ਹੈ। Spend permission ਦਾ ਮੂਲ ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਇਹ agent ਦੀ manipulable scope ਤੋਂ ਬਾਹਰ ਰਹੇ - backend 'ਤੇ, dashboard ਵਿੱਚ set ਹੋਵੇ - ਤਾਂ ਜੋ agent ਇਸਨੂੰ ਬਦਲ ਨਾ ਸਕੇ। ਇਸਨੂੰ ਉੱਥੇ configure ਕਰੋ, ਨਾ ਕਿ 'agent ਨੂੰ $X ਤੋਂ ਵੱਧ spend ਨਾ ਕਰਨ ਦਿਓ' ਨਾਲ।
ਏਜੰਟ ਦੀ API ਕੁੰਜੀ ਦੀ ਉਮੀਦ ਕਰਨਾ ਕਿ ਸੀਮਾ ਨੂੰ ਵਿਆਪਕ ਕਰੇਗੀ
API spend permissions ਲਈ read-only ਹੈ: allowance ਵਧਾਉਣ ਲਈ ਕੋਈ endpoint ਅਤੇ ਕੋਈ SDK method ਨਹੀਂ ਹੈ। ਇਹ ਜਾਣਬੂਝ ਕੇ ਹੈ। ਜੇ ਕੋਈ compromised ਜਾਂ injected agent ਆਪਣੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ key ਨਾਲ mutate endpoint call ਕਰ ਸਕੇ, ਤਾਂ control ਬੇਕਾਰ ਹੋ ਜਾਵੇਗਾ। Limit ਬਦਲਣ ਲਈ ਤੁਸੀਂ dashboard ਵਰਤਦੇ ਹੋ, ਜਿੱਥੇ change ਇੱਕ human action ਹੁੰਦੀ ਹੈ ਅਤੇ audit trail ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਆਗਿਆ ਇੰਨੀ ਉੱਚੀ ਸੈਟ ਕਰਨਾ ਕਿ ਇਹ ਕਦੇ ਵੀ ਨਹੀਂ ਕੱਟਦੀ
ਇੱਕ ਆਗਿਆ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇਸਨੂੰ ਲੋਡ-ਬੇਅਰਿੰਗ ਹੋਣ 'ਤੇ ਹੀ ਸੁਰੱਖਿਅਤ ਕਰਦੀ ਹੈ. 100x ਆਮ ਵਰਤੋਂ 'ਤੇ ਸੈੱਟ ਕੀਤੀ ਗਈ ਆਗਿਆ ਇੱਕ ਭਟਕਣ ਵਾਲੇ ਲੂਪ ਨੂੰ ਨਹੀਂ ਰੋਕੇਗੀ ਜਦ ਤੱਕ ਇਹ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਚਾਹੀਦੇ ਤੋਂ ਬਹੁਤ ਵੱਧ ਖਰਚ ਨਹੀਂ ਕਰ ਲੈਂਦੀ. ਆਗਿਆ ਅਤੇ ਪ੍ਰਤੀ-ਲੈਨਦੈਨ ਸੀਮਾ ਨੂੰ ਲਗਭਗ 2-3x ਉਮੀਦ ਕੀਤੀ ਵਰਤੋਂ 'ਤੇ ਸਾਈਜ਼ ਕਰੋ, ਫਿਰ ਜੇਕਰ ਅਸਲ ਟ੍ਰੈਫਿਕ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ ਤਾਂ ਜਾਣਬੂਜ ਕੇ ਵਿਆਪਕ ਕਰੋ.
ਪ੍ਰਤੀ-ਲੈਣ-ਦੇਣ ਸੀਮਾ ਨੂੰ ਭੁੱਲਣਾ
allowance_wei ਪੂਰੇ ਸਮੇਂ ਵਿੱਚ ਸਭ ਤੋਂ ਖਰਾਬ ਕੇਸ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ; per_tx_wei ਕਿਸੇ ਵੀ ਇਕੱਲੇ ਭੁਗਤਾਨ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਵੱਖਰੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਇੱਕ ਦਿਆਲੂ ਸਮੇਂ ਦੀ ਆਗਿਆ ਜਿਸ ਵਿੱਚ ਕੋਈ ਪ੍ਰਤੀ-ਲੈਣ-ਦੇਣ ਸੀਮਾ ਨਹੀਂ ਹੈ, ਫਿਰ ਵੀ ਇੱਕ ਅਸਧਾਰਣ ਬੇਨਤੀ - ਇੱਕ ਬੱਗੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼, ਇੱਕ ਦੁਰਾਭਾਸ਼ਿਤ ਕੀਮਤ - ਇੱਕ ਹੀ ਵਾਰੀ ਵਿੱਚ ਵੱਡੀ ਰਕਮ ਨੂੰ ਹਿਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਦੋਹਾਂ ਨੂੰ ਸੈਟ ਕਰੋ।
ਕੋਈ ਤੇਜ਼ ਕਿਲ ਸਵਿੱਚ ਨਹੀਂ ਕੀਤਾ ਗਿਆ
ਜਦੋਂ 2am 'ਤੇ ਕੁਝ ਗਲਤ ਲੱਗੇ, ਤੁਹਾਨੂੰ ਉਹੀ action ਚਾਹੀਦੀ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਪਹਿਲਾਂ practice ਕਰ ਚੁੱਕੇ ਹੋ। ਦੋ options ਹਨ: dashboard ਵਿੱਚ permission revoke ਕਰੋ (revoked_at set ਕਰਦਾ ਹੈ, allowance ਨੂੰ zero ਕਰ ਦਿੰਦਾ ਹੈ), ਜਾਂ agent ਦੀ API key ਨੂੰ apiKeys.revoke / apiKeys.rotate ਨਾਲ revoke/rotate ਕਰੋ (credential ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੱਟ ਦਿੰਦਾ ਹੈ)। ਜਾਣੋ ਕਿ ਕਿਸ ਲਈ ਹੱਥ ਵਧਾਉਣਾ ਹੈ ਅਤੇ ਇਹ ਤੁਹਾਡੇ ਤੋਂ ਤੁਰੰਤ ਹੋ ਸਕੇ।
ਇਜਾਜ਼ਤ ਹੋਣ ਦੇ ਬਾਅਦ।
Permission enforce ਹੋਣ ਤੋਂ ਬਾਅਦ, ਸਭ ਤੋਂ ਵੱਧ ਫਾਇਦਾ ਦੇਣ ਵਾਲੇ follow-ups ਹਨ dependable webhook handling (ਤਾਂ ਜੋ payment events ਸੱਚਮੁੱਚ ਤੁਹਾਡੇ handler ਤੱਕ ਪਹੁੰਚਣ), identity verification (ਤਾਂ ਜੋ counterparties agent ਦੇ profile 'ਤੇ ਭਰੋਸਾ ਕਰਨ), ਅਤੇ ਇੱਕ pre-launch security review (ਤਾਂ ਜੋ ਤੁਸੀਂ ਕੋਈ ਹੋਰ ਦਰਵਾਜ਼ਾ ਖੁੱਲਾ ਨਾ ਛੱਡਿਆ ਹੋਵੇ)।
ਵੈਬਹੂਕ ਪੈਟਰਨ ਜੋ ਵਿਕਾਸਕਾਂ ਨੇ ਸਭ ਤੋਂ ਵੱਧ ਪੁੱਛੇ ਹਨ
GitHub ਅਤੇ ਡੋਮੇਨ ਪੁਸ਼ਟੀਕਰਨ ਬੈਜ ਪ੍ਰਾਪਤ ਕਰੋ
ਲਾਈਵ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਏਜੰਟ ਵਾਲਿਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ
ਪੂਰੀ ਹਵਾਲਾ docs.blockchain0x.com 'ਤੇ ਹੈ। ਉਤਪਾਦ ਸਤਹ: Spending controls.