APIs ਦੇ ਕੋਲ ਪਹਿਲਾਂ traffic ਦਾ ਇੱਕ ਸਧਾਰਨ model ਸੀ। ਕੋਈ developer ਰਜਿਸਟਰ ਕਰਦਾ, key ਲੈਂਦਾ, integration ਲਿਖਦਾ, ਅਤੇ ਉਹ integration ਤੁਹਾਡੇ endpoints ਨੂੰ ਇੱਕ schedule 'ਤੇ ਜਾਂ ਜਦੋਂ ਕੋਈ user ਕੁਝ click ਕਰਦਾ, call ਕਰਦੀ ਸੀ। APIs ਲਈ bot management ਉਸੇ model ਦੇ ਆਸ-ਪਾਸ ਵਿਕਸਿਤ ਹੋਇਆ: key ਦੀ authentication ਕਰੋ, volume ਸੀਮਿਤ ਕਰੋ, ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦੁਰਵਿਵਹਾਰ ਵਾਲੇ traffic ਨੂੰ filter ਕਰੋ, ਅਤੇ service ਨੂੰ ਬਾਕੀਆਂ ਲਈ available ਰੱਖੋ।
ਉਹ model ਅਜੇ ਵੀ ਲਾਗੂ ਹੈ, ਅਤੇ ਉਸ ਲਈ ਬਣੇ tools ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਜੋ ਬਦਲਿਆ ਹੈ ਉਹ ਇਹ ਕਿ calls ਦੇ ਪਿੱਛੇ ਕੌਣ ਹੈ। ਹੁਣ ਉਹੀ API key ਕਿਸੇ customer ਦੇ app ਨੂੰ ਵਰਤ ਰਹੇ ਵਿਅਕਤੀ, ਕਿਸੇ AI assistant ਨੂੰ ਕੰਮ ਕਰਨ ਲਈ ਕਹੇ ਵਿਅਕਤੀ, ਅਤੇ ਰਾਤ ਭਰ ਇੱਕ multi-step task ਚਲਾ ਰਹੇ autonomous agent ਦੇ requests ਲਿਆ ਸਕਦੀ ਹੈ। ਤੁਹਾਡੇ ਮੌਜੂਦਾ controls ਇੱਕ key ਅਤੇ ਇੱਕ request rate ਦੇਖਦੇ ਹਨ। ਤੁਹਾਡੇ product, support ਅਤੇ policy decisions ਨੂੰ ਅਕਸਰ ਹੋਰ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
Proof of Actor ਉਸ ਖਾਲੀ ਥਾਂ ਨੂੰ ਭਰਦਾ ਹੈ। ਇਹ ਤੁਹਾਡੇ API ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਹਰ request 'ਤੇ ਕੌਣ ਜਾਂ ਕੀ ਕਾਰਵਾਈ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ evidence ਦੱਸਦਾ ਹੈ, ਫਿਰ decision ਤੁਹਾਡੇ code 'ਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇਹ page ਇਸ ਨੂੰ APIs ਲਈ ਮੁੱਖ bot protection layers ਨਾਲ compare ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕਿ ਹਰ ਇੱਕ ਕਿੱਥੇ fit ਹੁੰਦਾ ਹੈ।
ਸੰਖੇਪ ਸੰਸਕਰਣ
| API bot protection | Proof of Actor | |
|---|---|---|
| ਮੁੱਖ ਸਵਾਲ | ਕੀ ਇਹ request allowed ਹੈ, authenticated ਹੈ ਅਤੇ limits ਦੇ ਅੰਦਰ ਹੈ? | ਕੌਣ ਜਾਂ ਕੀ ਕਾਰਵਾਈ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ evidence ਕੀ ਹੈ? |
| ਆਮ layers | API gateway, WAF bot rules, API keys, rate limits | ਤੁਹਾਡੇ API ਜਾਂ MCP server ਦੇ ਅੰਦਰ actor classification |
| ਕੀ ਪਛਾਣਦਾ ਹੈ | ਉਹ account ਜਾਂ integration ਜੋ key ਦੀ ਮਾਲਕ ਹੈ | ਹਰ request ਦੇ ਪਿੱਛੇ actor: Human, Human + AI, Agent ਜਾਂ Unknown |
| ਨਤੀਜਾ | Allow, reject, throttle; ਕਦੇ-ਕਦੇ bot score | ਇੱਕ class ਨਾਲ basis: verified, declared, inferred ਜਾਂ unknown |
| ਅਸਪਸ਼ਟ traffic | ਜੇ key valid ਹੋਵੇ ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ allow, ਜਾਂ ਕਿਸੇ rule ਨਾਲ reject | Unknown, ਇੱਕ fallback ਨਾਲ ਜੋ ਤੁਸੀਂ ਹਰ route ਲਈ ਚੁਣਦੇ ਹੋ |
| ਜਵਾਬ ਕੌਣ ਤੈਅ ਕਰਦਾ ਹੈ | Gateway ਅਤੇ WAF configuration | ਤੁਹਾਡਾ application code |
| Install 'ਤੇ default | Enforcement | Observation; ਜਦ ਤੱਕ ਤੁਸੀਂ policy ਨਹੀਂ ਜੋੜਦੇ, ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ |
| ਸਭ ਤੋਂ ਵਧੀਆ | Availability, abuse filtering, quotas, accountability | ਹਰ actor ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ serve ਕਰਨਾ ਅਤੇ API usage ਨੂੰ ਸਮਝਣਾ |
ਹੇਠਲੇ ਭਾਗ ਹਰ ਹਿੱਸੇ ਨੂੰ ਸਮਝਾਉਂਦੇ ਹਨ।
API bot protection ਕੀ ਚੰਗਾ ਕਰਦਾ ਹੈ
ਇਹ ਸਪੱਸ਼ਟ ਹੋਣਾ ਲਾਭਕਾਰੀ ਹੈ ਕਿ ਹਰ layer ਕਿਹੜਾ ਕੰਮ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ Proof of Actor ਉਨ੍ਹਾਂ ਸਾਰਿਆਂ ਦੇ ਨਾਲ ਬੈਠਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਕਿਸੇ ਦੀ ਥਾਂ ਲੈਣ ਲਈ ਨਹੀਂ।
API gateways
Gateway ਤੁਹਾਡੇ API ਦਾ front door ਹੁੰਦਾ ਹੈ। ਇਹ connections ਨੂੰ terminate ਕਰਦਾ ਹੈ, API keys ਜਾਂ tokens ਦੀ authentication ਕਰਦਾ ਹੈ, requests ਨੂੰ ਸਹੀ service ਵੱਲ route ਕਰਦਾ ਹੈ, quotas ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ ਅਕਸਰ billing ਅਤੇ analytics ਲਈ usage record ਕਰਦਾ ਹੈ। ਇਹ ਤੇਜ਼ੀ ਅਤੇ ਇਕਸਾਰਤਾ ਨਾਲ ਹਰ endpoint 'ਤੇ ਇਹ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: "ਕੀ ਇਸ caller ਨੂੰ ਅੰਦਰ ਆਉਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਅਤੇ ਕਿਸ ਦਰਵਾਜ਼ੇ ਰਾਹੀਂ?"
WAF bot rules
Bot rules ਵਾਲਾ web application firewall traffic ਨੂੰ ਜਾਣੇ-ਪਹਿਚਾਣੇ attack patterns ਅਤੇ ਦੁਰਵਿਵਹਾਰ ਵਾਲੀ automation ਲਈ inspect ਕਰਦਾ ਹੈ। ਇਹ injection ਦੇ ਯਤਨਾਂ ਨੂੰ filter ਕਰ ਸਕਦਾ ਹੈ, abuse ਦੇ ਇਤਿਹਾਸ ਵਾਲੇ sources ਤੋਂ traffic block ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹ requests challenge ਜਾਂ drop ਕਰ ਸਕਦਾ ਹੈ ਜੋ scraping ਜਾਂ credential attacks ਵਰਗੀਆਂ ਲੱਗਦੀਆਂ ਹਨ। ਇਹ ਉਸ traffic ਤੋਂ ਤੁਹਾਡੀ ਸਭ ਤੋਂ ਵਧੀਆ ਰੱਖਿਆ ਹੈ ਜੋ ਤੁਹਾਡੇ code ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ।
API keys ਅਤੇ tokens
Keys ਅਤੇ tokens ਤੁਹਾਨੂੰ accountability ਦਿੰਦੇ ਹਨ। ਹਰ request ਇੱਕ account ਨਾਲ map ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਸ ਦੀ integration ਨੇ call ਕੀਤੀ, ਤੁਸੀਂ access revoke ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ usage ਨੂੰ attribute ਕਰ ਸਕਦੇ ਹੋ। Scoped tokens ਇਸ ਤੋਂ ਅੱਗੇ ਜਾ ਕੇ ਸੀਮਿਤ ਕਰਦੇ ਹਨ ਕਿ caller ਕੀ ਕਰ ਸਕਦਾ ਹੈ।
Rate limits
Rate limits availability ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ। ਇਹ ਇੱਕ integration ਨੂੰ ਉਸ capacity ਨੂੰ consume ਕਰਨ ਤੋਂ ਰੋਕਦੇ ਹਨ ਜੋ ਸਭ ਲਈ ਹੈ, ਅਤੇ ਇਹ brute-force ਅਤੇ enumeration ਦੇ ਯਤਨਾਂ ਨੂੰ slow ਕਰਦੇ ਹਨ। Per-key ਅਤੇ per-route limits ਇੱਕ standard, ਪ੍ਰਭਾਵਸ਼ਾਲੀ control ਹਨ।
ਇਕੱਠੇ ਮਿਲ ਕੇ ਇਹ layers protection ਅਤੇ accountability ਦੇ ਸਵਾਲਾਂ ਦਾ ਬਹੁਤ ਵਧੀਆ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ। ਇਨ੍ਹਾਂ ਨੂੰ ਰੱਖੋ।
ਉਹ ਸਵਾਲ ਜਿਸ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਇਹ ਨਹੀਂ ਬਣੇ ਸਨ
ਉਹਨਾਂ layers ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਣ ਲਈ ਨਹੀਂ ਬਣੀ ਕਿ ਇੱਕ authenticated request ਦੇ ਪਿੱਛੇ ਕਿਸ ਤਰ੍ਹਾਂ ਦਾ actor ਹੈ। ਇੱਕ valid key ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜਾ account integration ਦੀ ਮਾਲਕੀ ਰੱਖਦਾ ਹੈ। ਇਹ ਇਹ ਨਹੀਂ ਦੱਸਦੀ:
- ਕੀ ਇਹ specific call ਤੁਹਾਡੇ customer ਦੇ app ਵਿੱਚ ਬਟਨ ਦਬਾਉਂਦੇ ਵਿਅਕਤੀ ਤੋਂ ਆਈ ਸੀ,
- ਕੀ ਕਿਸੇ ਵਿਅਕਤੀ ਨੇ ਕਿਸੇ AI assistant ਨੂੰ ਕਾਰਵਾਈ ਕਰਨ ਲਈ ਕਿਹਾ ਸੀ,
- ਕੀ ਕਿਸੇ autonomous agent ਨੇ ਇੱਕ ਵੱਡੇ task ਦੇ ਇੱਕ ਕਦਮ ਵਜੋਂ call ਕੀਤੀ ਸੀ,
- ਜਾਂ ਕੀ ਇਹ ਪਤਾ ਨਹੀਂ ਲਗ ਸਕਦਾ।
ਇਹ ਫ਼ਰਕ ਹਰ ਮਹੀਨੇ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਹੋ ਰਿਹਾ ਹੈ। ਇੱਕ API ਜੋ CRM integration, scheduling tool ਜਾਂ developer platform ਨੂੰ serve ਕਰਦੀ ਹੈ, ਉਹ increasingly ਉਹੀ keys ਵਰਤ ਕੇ agent traffic ਪ੍ਰਾਪਤ ਕਰ ਰਹੀ ਹੈ ਜੋ human-driven apps ਨੂੰ serve ਕਰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ agents ਨੂੰ structured response ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ, agents ਵੱਲੋਂ ਚਲਾਏ ਗਏ high-impact writes ਲਈ confirmation ਮੰਗਣਾ ਚਾਹੁੰਦੇ ਹੋ, AI-assisted submissions ਨੂੰ label ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਜਾਂ ਸਿਰਫ਼ ਇਹ ਮਾਪਣਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਤੁਹਾਡੇ API usage ਵਿੱਚੋਂ ਕਿੰਨਾ ਹਿੱਸਾ agent-driven ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ actor context ਦੀ ਲੋੜ ਹੈ।
Proof of Actor API ਵਿੱਚ ਕੀ ਜੋੜਦਾ ਹੈ
Proof of Actor ਹਰ interaction ਲਈ ਚਾਰ classes ਵਿੱਚੋਂ ਇੱਕ ਵਾਪਸ ਕਰਦਾ ਹੈ:
- Human: ਦੇਖਣਯੋਗ signals human-directed interaction ਦਰਸਾਉਂਦੇ ਹਨ।
- Human + AI: ਕਿਸੇ ਵਿਅਕਤੀ ਨੇ AI assistance ਦੇ ਨਾਲ interaction ਨੂੰ ਨਿਰਦੇਸ਼ਿਤ ਕੀਤਾ, ਜੋ ਕਿਸੇ supported integration ਰਾਹੀਂ declared ਜਾਂ observed ਹੋਈ ਸੀ।
- Agent: automated ਜਾਂ agent-origin interaction।
- Unknown: evidence reliable determination ਨੂੰ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੀ।
ਹਰ result ਆਪਣੀ evidence basis ਵੀ ਦੱਸਦਾ ਹੈ:
- Verified: ਉਦਾਹਰਨ ਲਈ, ਇੱਕ HTTP Message Signature (RFC 9421) ਜੋ published key ਦੇ ਖਿਲਾਫ਼ checked ਹੋਇਆ ਹੋਵੇ।
- Declared: client ਜਾਂ ਤੁਹਾਡੀ ਆਪਣੀ application ਨੇ ਇਹ ਕਿਹਾ ਹੋਵੇ।
- Inferred: behavioral ਜਾਂ contextual signals, ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ inference ਵਜੋਂ label ਕੀਤੇ ਹੋਏ।
- Unknown: ਕੋਈ reliable basis ਨਹੀਂ।
APIs ਲਈ, verified basis ਖਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੈ। ਉਹ agents ਜੋ ਆਪਣੀਆਂ requests sign ਕਰਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੀਆਂ published keys ਦੇ against check ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜੋ IETF ਦੇ Web Bot Auth work ਦੇ ਪਿੱਛੇ approach ਹੈ। ਪਿਛੋਕੜ ਲਈ product teams ਲਈ Web Bot Auth ਦੀ ਵਿਆਖਿਆ ਪੜ੍ਹੋ, ਅਤੇ implementation ਪੱਖ ਲਈ signed agent requests ਦੀ verification ਵਾਲਾ guide ਵੇਖੋ।
ਇੱਥੇ ਇੱਕ ਸੀਮਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕ valid signature ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜੀ key ਨੇ request sign ਕੀਤੀ। ਇਹ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ agent ਕਾਰਵਾਈ ਕਰਨ ਲਈ authorized ਹੈ। Authorization ਉਸੇ ਜਗ੍ਹਾ ਰਹਿੰਦੀ ਹੈ ਜਿੱਥੇ ਉਸ ਦੀ ਜਗ੍ਹਾ ਹੈ, ਤੁਹਾਡੇ API ਦੇ ਆਪਣੇ access control ਵਿੱਚ। agent authorization entry ਇਹ ਫ਼ਰਕ ਸਮਝਾਉਂਦੀ ਹੈ।
Scores ਅਤੇ keys ਦੇ ਮੁਕਾਬਲੇ actor evidence
ਕੁਝ bot protection products ਹਰ request ਨਾਲ ਇੱਕ score ਜੋੜਦੇ ਹਨ। Block decision ਲਈ score ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦਾ ਹੈ। API product decisions ਲਈ ਇਹ ਘੱਟ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕੋਈ legitimate request human-driven ਸੀ ਜਾਂ agent-driven, ਅਤੇ ਇਹ verified facts ਨੂੰ inference ਤੋਂ ਵੱਖਰਾ ਨਹੀਂ ਕਰਦਾ।
API keys ਦਾ ਉਲਟ ਸੀਮਿਤਪਨ ਹੈ। ਇਹ ownership ਬਾਰੇ precise ਹਨ ਅਤੇ actor ਬਾਰੇ ਚੁੱਪ ਰਹਿੰਦੀਆਂ ਹਨ। ਇੱਕ customer ਦੀ key ਇੱਕ ਹੀ ਘੰਟੇ ਵਿੱਚ ਚਾਰੇ classes carry ਕਰ ਸਕਦੀ ਹੈ।
Proof of Actor ਦੋਵੇਂ distinctions ਨੂੰ visible ਰੱਖਦਾ ਹੈ। ਤੁਹਾਡਾ API key ਤੋਂ account ਦੇਖਦਾ ਹੈ, Proof of Actor ਤੋਂ actor class ਦੇਖਦਾ ਹੈ, ਅਤੇ ਉਸ ਨੂੰ support ਕਰਨ ਵਾਲੀ basis ਦੇਖਦਾ ਹੈ। ਹਰ layer ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਉਹ ਚੰਗੀ ਹੈ।
ਹਰ ਇੱਕ ਕਿੱਥੇ ਚਲਦਾ ਹੈ
Gateways ਅਤੇ WAFs ਤੁਹਾਡੇ network ਦੇ edge 'ਤੇ ਜਾਂ ਤੁਹਾਡੀਆਂ services ਦੇ ਸਾਹਮਣੇ ਚਲਦੇ ਹਨ। ਉਹ ਸਥਿਤੀ protection ਅਤੇ quotas ਲਈ ਠੀਕ ਹੈ।
Proof of Actor ਉੱਥੇ ਚਲਦਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡੀ API logic ਰਹਿੰਦੀ ਹੈ। Founding teams Node.js middleware, Next.js, ਇੱਕ edge layer ਜੋ ਤੁਸੀਂ control ਕਰਦੇ ਹੋ, generic HTTP API, ਜਾਂ MCP server integration ਰਾਹੀਂ integrate ਕਰ ਸਕਦੀਆਂ ਹਨ। ਪੂਰੀ ਸੂਚੀ ਲਈ integrations ਵੇਖੋ। ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੀ application ਦੇ ਅੰਦਰ ਚਲਦਾ ਹੈ, ਇਹ ਉਹ ਚੀਜ਼ਾਂ ਵਰਤ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ API ਜਾਣਦੀ ਹੈ: route, workflow, client ਨੇ ਆਪਣੇ ਆਪ ਨੂੰ declare ਕੀਤਾ ਕਿ ਨਹੀਂ, ਅਤੇ signature verify ਹੋਇਆ ਕਿ ਨਹੀਂ।
Routing decisions ਤੁਹਾਡੇ code ਵਿੱਚ ਹੀ ਰਹਿੰਦੀਆਂ ਹਨ
Proof of Actor by default ਕੁਝ ਵੀ block ਨਹੀਂ ਕਰਦਾ। ਇਹ observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ install ਕਰਨ ਨਾਲ ਤੁਹਾਡੀ API ਦੇ response ਕਰਨ ਦੇ ਢੰਗ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਆਉਂਦਾ। ਤੁਸੀਂ ਹਰ endpoint ਲਈ ਆਪਣੇ actor mix ਨੂੰ ਦੇਖਦੇ ਹੋ, ਵਿਅਕਤੀਗਤ results ਲਈ evidence review ਕਰਦੇ ਹੋ, ਅਤੇ ਆਪਣੀ Unknown rate ਨੂੰ monitor ਕਰਦੇ ਹੋ।
ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋ, ਤੁਸੀਂ ਹਰ route, ਹਰ actor class ਅਤੇ ਹਰ basis ਲਈ application-defined policies ਲਿਖਦੇ ਹੋ। ਆਮ outcomes ਇਹ ਹਨ:
- Allow: request ਨੂੰ ਆਮ ਤਰੀਕੇ ਨਾਲ serve ਕਰੋ।
- Adapt: verified agent ਲਈ ਇੱਕ structured ਜਾਂ reduced response ਵਾਪਸ ਕਰੋ।
- Challenge: ਇੱਕ ਵਾਧੂ confirmation step ਦੀ ਲੋੜ ਰੱਖੋ, ਉਦਾਹਰਨ ਵਜੋਂ high-impact write 'ਤੇ human approval।
- Review: action ਨੂੰ ਕਿਸੇ ਵਿਅਕਤੀ ਵੱਲੋਂ ਚੈਕ ਕਰਨ ਲਈ queue ਕਰੋ।
- Rate-limit: ਕਿਸੇ ਖਾਸ route 'ਤੇ ਕਿਸੇ ਖਾਸ class ਅਤੇ basis ਲਈ tighter limit ਲਾਗੂ ਕਰੋ।
ਤੁਸੀਂ enforcement ਤੋਂ ਪਹਿਲਾਂ policy ਨੂੰ real traffic ਦੇ ਖਿਲਾਫ਼ preview ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ route by route enforce ਕਰ ਸਕਦੇ ਹੋ। actor-aware policies safely rollout ਕਰਨ ਵਾਲਾ guide process ਨੂੰ cover ਕਰਦਾ ਹੈ, ਅਤੇ agents ਨੂੰ block ਕੀਤੇ ਬਿਨਾਂ sensitive actions ਦੀ protection ਆਮ patterns ਦਿਖਾਉਂਦਾ ਹੈ।
Unknown API callers ਨੂੰ handle ਕਰਨਾ
ਹਰ API ਨੂੰ ਅਜਿਹਾ traffic ਮਿਲਦਾ ਹੈ ਜਿਸਨੂੰ confidence ਨਾਲ classify ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। Traditional controls ਨਾਲ, ਇੱਕ valid key ਆਮ ਤੌਰ 'ਤੇ request ਨੂੰ ਅੱਗੇ ਜਾਣ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਇੱਕ invalid key ਨਹੀਂ ਦਿੰਦੀ। ਵਿਚਕਾਰ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ।
Proof of Actor ਤੁਹਾਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ Unknown result ਦਿੰਦਾ ਹੈ ਅਤੇ ਹਰ route ਲਈ fallback ਚੁਣਨ ਦਿੰਦਾ ਹੈ। Read-only catalog endpoints ਖੁੱਲ੍ਹੇ ਰਹਿ ਸਕਦੇ ਹਨ। Account changes ਆਪਣੀਆਂ ਮੌਜੂਦਾ ਕੜੀਆਂ checks ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹਨ। Bulk exports review ਵਿੱਚ ਜਾ ਸਕਦੇ ਹਨ। ਵੇਰਵਿਆਂ ਲਈ Unknown traffic handle ਕਰਨਾ ਅਤੇ unknown automated traffic ਵੇਖੋ।
ਇਹ ਇਕੱਠੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ
ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ API setup ਹਰ layer ਨੂੰ ਉਸ ਦੇ ਆਪਣੇ ਕੰਮ ਲਈ ਵਰਤਦਾ ਹੈ:
- Edge 'ਤੇ, WAF ਦੁਰਵਿਵਹਾਰ ਵਾਲੇ ਅਤੇ malformed traffic ਨੂੰ filter ਕਰਦਾ ਹੈ।
- Gateway 'ਤੇ, keys ਦੀ authentication ਹੁੰਦੀ ਹੈ, quotas ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ usage record ਹੁੰਦਾ ਹੈ।
- API ਦੇ ਅੰਦਰ, Proof of Actor ਹਰ request ਨੂੰ classify ਕਰਦਾ ਹੈ ਜੋ ਅੱਗੇ ਲੰਘਦੀ ਹੈ ਅਤੇ ਉਸ ਦੀ basis ਦੱਸਦਾ ਹੈ।
- ਤੁਹਾਡੇ handlers ਵਿੱਚ, policies class ਅਤੇ basis ਨੂੰ ਵਰਤ ਕੇ response ਚੁਣਦੀਆਂ ਹਨ: human-driven call ਲਈ ਆਮ handling, verified agent ਲਈ structured response, agent-driven high-impact write ਲਈ confirmation step, Unknown ਲਈ fallback।
- Analytics ਵਿੱਚ, ਤੁਹਾਡੀ team ਵੇਖਦੀ ਹੈ ਕਿ ਕਿਹੜੇ endpoints ਅਤੇ workflows ਹਰ actor class ਵਰਤਦੀ ਹੈ, gateway ਦੇ account data ਦੇ ਨਾਲ।
ਇਸ stack ਵਿੱਚ ਕੁਝ ਵੀ ਦੁਹਰਾਇਆ ਨਹੀਂ ਜਾਂਦਾ। Gateway account ਜਾਣਦਾ ਹੈ, WAF threat patterns ਜਾਣਦਾ ਹੈ, ਅਤੇ Proof of Actor actor ਜਾਣਦਾ ਹੈ।
ਕਿਸ 'ਤੇ ਕਦੋਂ ਧਿਆਨ ਦੇਣਾ ਹੈ
ਜਦੋਂ ਤੁਹਾਡੀਆਂ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ abuse, availability ਜਾਂ unmetered usage ਹੋਣ, ਤਾਂ ਪਹਿਲਾਂ API bot protection 'ਤੇ ਧਿਆਨ ਦਿਓ: auth endpoints ਖਿਲਾਫ਼ credential attacks, aggressive scraping, ਜਾਂ ਇੱਕ integration ਦਾ ਬਾਕੀਆਂ ਦੀ capacity ਖਾ ਜਾਣਾ।
ਜਦੋਂ ਤੁਹਾਡੇ ਮੁੱਖ ਸਵਾਲ ਤੁਹਾਡੇ callers ਬਾਰੇ ਹੋਣ, ਤਾਂ Proof of Actor 'ਤੇ ਧਿਆਨ ਦਿਓ: ਤੁਹਾਡੇ API traffic ਵਿੱਚੋਂ ਕਿੰਨਾ ਹਿੱਸਾ agent-driven ਹੈ, ਕਿਹੜੇ agents ਕਿਹੜੇ endpoints call ਕਰਦੇ ਹਨ, human-driven ਅਤੇ agent-driven usage ਕਿੱਥੇ ਵੱਖਰੇ ਹਨ, ਅਤੇ ਕਿਹੜੇ routes ਨੂੰ actor-aware policy ਦੀ ਲੋੜ ਹੈ। APIs use case ਅਤੇ APIs ਲਈ AI agent identification ਹੋਰ ਡੂੰਘਾਈ ਨਾਲ ਸਮਝਾਉਂਦੇ ਹਨ।
ਉਤਪਾਦਨ API ਚਲਾਉਣ ਵਾਲੀਆਂ ਜ਼ਿਆਦਾਤਰ teams ਨੂੰ ਦੋਵੇਂ ਲਈ ਜਵਾਬ ਚਾਹੀਦੇ ਹਨ।
ਸ਼ੁਰੂ ਕਰੋ
Proof of Actor private beta ਵਿੱਚ ਹੈ। ਚੁਣੀਆਂ ਗਈਆਂ founding developer teams agreed usage limits ਦੇ ਅੰਦਰ, ਬਿਨਾਂ automatic billing ਦੇ, 12 ਮਹੀਨੇ ਤੱਕ ਦਾ ਮੁਫ਼ਤ access ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀਆਂ ਹਨ। early access ਲਈ ਅਰਜ਼ੀ ਦਿਓ ਅਤੇ ਸਾਨੂੰ ਉਸ API ਅਤੇ ਉਹਨਾਂ callers ਬਾਰੇ ਦੱਸੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਸਮਝਣਾ ਚਾਹੁੰਦੇ ਹੋ।