ਮੁੱਖ ਸਮੱਗਰੀ 'ਤੇ ਜਾਓ
ਤੁਲਨਾ

Proof of Actor ਵਿਰੁੱਧ API bot protection: keys ਦੱਸਦੇ ਹਨ ਕੌਣ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ, actor context ਦੱਸਦਾ ਹੈ ਕੌਣ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ

API gateways, WAF bot rules, API keys ਅਤੇ rate limits ਤੁਹਾਡੇ API ਨੂੰ ਉਪਲਬਧ ਅਤੇ ਜਵਾਬਦੇਹ ਰੱਖਦੇ ਹਨ। ਇਹ ਇਸ ਲਈ ਨਹੀਂ ਬਣਾਏ ਗਏ ਸਨ ਕਿ ਤੁਹਾਨੂੰ ਦੱਸ ਸਕਣ ਕਿ ਕੋਈ request app ਵਿੱਚ ਕਿਸੇ ਵਿਅਕਤੀ ਤੋਂ ਆਈ ਸੀ, ਕਿਸੇ assistant ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਵਿਅਕਤੀ ਤੋਂ, ਜਾਂ ਕਿਸੇ autonomous agent ਤੋਂ। ਇੱਥੇ ਇਹ ਹੈ ਕਿ APIs ਲਈ bot management Proof of Actor ਨਾਲ ਕਿਵੇਂ ਤੁਲਨਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਇਕੱਠੇ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦੇ ਹਨ।

Toshendra Sharma

ਦੁਆਰਾ Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

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 ਨੂੰ ਉਸ ਦੇ ਆਪਣੇ ਕੰਮ ਲਈ ਵਰਤਦਾ ਹੈ:

  1. Edge 'ਤੇ, WAF ਦੁਰਵਿਵਹਾਰ ਵਾਲੇ ਅਤੇ malformed traffic ਨੂੰ filter ਕਰਦਾ ਹੈ।
  2. Gateway 'ਤੇ, keys ਦੀ authentication ਹੁੰਦੀ ਹੈ, quotas ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ usage record ਹੁੰਦਾ ਹੈ।
  3. API ਦੇ ਅੰਦਰ, Proof of Actor ਹਰ request ਨੂੰ classify ਕਰਦਾ ਹੈ ਜੋ ਅੱਗੇ ਲੰਘਦੀ ਹੈ ਅਤੇ ਉਸ ਦੀ basis ਦੱਸਦਾ ਹੈ।
  4. ਤੁਹਾਡੇ handlers ਵਿੱਚ, policies class ਅਤੇ basis ਨੂੰ ਵਰਤ ਕੇ response ਚੁਣਦੀਆਂ ਹਨ: human-driven call ਲਈ ਆਮ handling, verified agent ਲਈ structured response, agent-driven high-impact write ਲਈ confirmation step, Unknown ਲਈ fallback।
  5. 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 ਬਾਰੇ ਦੱਸੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਸਮਝਣਾ ਚਾਹੁੰਦੇ ਹੋ।

ਡਿਵੈਲਪਰਾਂ ਲਈ

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent ਜਾਂ Unknown।
basis
ਸਬੂਤ ਕਿੰਨਾ ਮਜ਼ਬੂਤ ਹੈ: verified, declared, inferred ਜਾਂ unknown।
evidence
result ਦੇ ਪਿੱਛੇ ਦੇ signals, ਤਾਂ ਜੋ ਤੁਹਾਡੀ team ਵੇਖ ਸਕੇ ਕਿ ਕਿਉਂ।

observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ: results ਨੂੰ ਆਪਣੇ logs ਦੇ ਨਾਲ record ਕਰੋ ਅਤੇ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕੋਈ policy ਨਾ ਚੁਣੋ, ਕੁਝ ਵੀ ਨਾ ਬਦਲੋ। Node.js integration guide ਪੜ੍ਹੋ

ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ

ਕੀ Proof of Actor ਮੇਰੇ API gateway ਜਾਂ WAF ਦੀ ਜਗ੍ਹਾ ਲੈਂਦਾ ਹੈ?

ਨਹੀਂ। ਤੁਹਾਡਾ gateway ਫਿਰ ਵੀ keys ਦੀ authentication ਕਰਦਾ ਹੈ ਅਤੇ quotas ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ WAF ਫਿਰ ਵੀ ਦੁਰਵਿਵਹਾਰ ਵਾਲਾ traffic filter ਕਰਦਾ ਹੈ। Proof of Actor ਤੁਹਾਡੇ API ਦੇ ਅੰਦਰ ਚਲਦਾ ਹੈ ਅਤੇ ਜੋ requests ਅੱਗੇ ਲੰਘਦੀਆਂ ਹਨ ਉਨ੍ਹਾਂ ਵਿੱਚ actor context ਜੋੜਦਾ ਹੈ। ਆਪਣੇ ਮੌਜੂਦਾ controls ਬਣੇ ਰਹਿਣ ਦਿਓ।

ਜੇ ਹਰ caller ਕੋਲ API key ਹੈ, ਤਾਂ ਮੈਨੂੰ actor context ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

API key ਉਸ account ਦੀ ਪਛਾਣ ਕਰਦੀ ਹੈ ਜੋ integration ਦਾ ਮਾਲਕ ਹੈ। ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਕੋਈ ਦਿੱਤੀ ਗਈ request ਤੁਹਾਡੇ customer ਦੇ app ਵਿੱਚ click ਕਰ ਰਹੇ ਵਿਅਕਤੀ ਵੱਲੋਂ ਚਲਾਈ ਗਈ ਸੀ, ਕਿਸੇ AI assistant ਵਰਤ ਰਹੇ ਵਿਅਕਤੀ ਵੱਲੋਂ, ਜਾਂ ਕਿਸੇ autonomous agent ਵੱਲੋਂ ਜੋ ਕੋਈ task ਚਲਾ ਰਿਹਾ ਸੀ। Proof of Actor ਇਹ, ਉਸ ਦੀ basis ਦੇ ਨਾਲ, report ਕਰਦਾ ਹੈ।

ਕੀ Proof of Actor ਇਹ verify ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਮੇਰੇ API ਨੂੰ ਕਿਹੜਾ agent call ਕਰ ਰਿਹਾ ਹੈ?

ਜਦੋਂ ਕੋਈ client ਆਪਣੀਆਂ requests ਨੂੰ HTTP Message Signatures (RFC 9421) ਨਾਲ sign ਕਰਦਾ ਹੈ ਅਤੇ ਆਪਣੀ key publish ਕਰਦਾ ਹੈ, Proof of Actor signature ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ verified basis report ਕਰਦਾ ਹੈ। ਇੱਕ valid signature ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜੀ key ਨੇ request sign ਕੀਤੀ। ਇਹ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ agent ਕਾਰਵਾਈ ਕਰਨ ਲਈ authorized ਹੈ, ਇਸ ਲਈ authorization ਤੁਹਾਡੇ code ਵਿੱਚ ਹੀ ਰਹਿੰਦੀ ਹੈ।

ਕੀ Proof of Actor ਮੇਰੇ API traffic ਨੂੰ rate-limit ਜਾਂ block ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੇਗਾ?

ਨਹੀਂ। ਇਹ observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ by default ਕੁਝ ਵੀ block ਨਹੀਂ ਕਰਦਾ। Rate-limit ਇੱਕ outcome ਹੈ ਜੋ ਤੁਸੀਂ policy ਵਿੱਚ ਚੁਣ ਸਕਦੇ ਹੋ, ਹਰ route, actor class ਅਤੇ basis ਲਈ, ਅਤੇ enforcement ਤੁਹਾਡੇ ਆਪਣੇ code ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ।

ਮੈਂ ਕਿਸੇ API ਵਿੱਚ Proof of Actor ਕਿਵੇਂ ਜੋੜਾਂ?

Founding teams Node.js middleware, Next.js, ਇੱਕ edge integration ਜਾਂ generic HTTP API ਵਰਤ ਸਕਦੀਆਂ ਹਨ। MCP servers ਦੀ ਆਪਣੀ integration ਹੈ। Details ਲਈ integrations page ਵੇਖੋ।

ਜਿਨ੍ਹਾਂ callers ਨੂੰ ਤੁਸੀਂ classify ਨਹੀਂ ਕਰ ਸਕਦੇ, ਉਨ੍ਹਾਂ ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ?

ਉਨ੍ਹਾਂ ਨੂੰ Unknown ਵਜੋਂ report ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਇੱਕ first-class result ਹੈ। ਤੁਸੀਂ ਹਰ route ਲਈ fallback ਚੁਣਦੇ ਹੋ, ਜਿਵੇਂ read-only endpoints 'ਤੇ allow ਕਰਨਾ ਅਤੇ write endpoints 'ਤੇ ਆਪਣੇ ਸਖ਼ਤ checks ਜਾਰੀ ਰੱਖਣਾ।

ਜਾਣੋ ਤੁਹਾਡਾ app ਕੌਣ ਵਰਤ ਰਿਹਾ ਹੈ।

Founding developers ਦੇ ਇੱਕ ਛੋਟੇ group ਲਈ private beta।

ਪਹਿਲਾਂ ਗੱਲ ਕਰਨੀ ਪਸੰਦ ਕਰੋਗੇ? founders ਨਾਲ ਗੱਲ ਕਰੋ