AI ਏਜੰਟ ਪਛਾਣ

API ਲਈ AI ਏਜੰਟ ਪਛਾਣ

ਤੁਹਾਡਾ API ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਹੈ ਕਿ ਕਿਹੜੀ key ਨੇ request ਕੀਤੀ। Proof of Actor ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਉਸ ਦੇ ਪਿੱਛੇ ਕਿਹੜਾ actor ਸੀ, ਉਸ ਨੂੰ ਕਿਹੜਾ ਸਬੂਤ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ code ਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਦਿੰਦਾ ਹੈ ਕਿ ਅੱਗੇ ਕੀ ਹੋਵੇ।

ਅਗਾਊਂ ਪਹੁੰਚ ਲਵੋ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਵੇਖੋ

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

ਤੁਹਾਡਾ API key ਜਾਣਦਾ ਹੈ। actor ਨਹੀਂ ਜਾਣਦਾ।

ਹਰ API request ਨਾਲ ਇਹ ਸਬੂਤ ਆਉਂਦਾ ਹੈ ਕਿ ਇਸ ਦੀ ਲਾਗਤ ਕੌਣ ਭਰ ਰਿਹਾ ਹੈ: ਇੱਕ API key, ਇੱਕ OAuth token, ਇੱਕ session। ਉਹ ਸਬੂਤ ਇੱਕ ਸਵਾਲ ਦਾ ਚੰਗਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ call ਲਈ ਕਿਹੜਾ account ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਇਸ ਵੇਲੇ ਅਸਲ ਵਿੱਚ call ਕੌਣ ਕਰ ਰਿਹਾ ਹੈ।

ਇੱਕ ਹੀ API key terminal ਵਿੱਚ test ਕਰ ਰਹੇ developer, schedule 'ਤੇ ਚੱਲ ਰਹੇ backend job, AI assistant ਰਾਹੀਂ ਕੰਮ ਕਰ ਰਹੇ ਵਿਅਕਤੀ, ਅਤੇ ਉਸ autonomous agent ਦੁਆਰਾ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜਿਸ ਨੂੰ key ਦਿੱਤੀ ਗਈ ਸੀ ਅਤੇ task ਪੂਰਾ ਕਰਨ ਲਈ ਕਿਹਾ ਗਿਆ ਸੀ। ਇਹ ਸਾਰੇ ਵੱਖਰੇ actor ਹਨ। ਉਨ੍ਹਾਂ ਦੇ rhythm, failure modes ਅਤੇ risk profiles ਵੱਖਰੇ ਹਨ। ਜੇ ਉਨ੍ਹਾਂ ਸਭ ਨੂੰ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ treat ਕੀਤਾ ਜਾਵੇ, ਤਾਂ ਜਾਂ ਤੁਸੀਂ ਆਪਣੇ customers ਦੀ ਭਰੋਸੇਯੋਗ automation ਨੂੰ ਹੱਦ ਤੋਂ ਵੱਧ restrict ਕਰ ਦਿੰਦੇ ਹੋ, ਜਾਂ ਆਪਣੇ API ਦੇ ਉਹ ਹਿੱਸੇ ਘੱਟ ਸੁਰੱਖਿਅਤ ਛੱਡ ਦਿੰਦੇ ਹੋ ਜੋ unattended agent ਦੁਆਰਾ ਕਦੇ ਵੀ drive ਨਹੀਂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ।

API ਲਈ AI agent identification ਇਹ ਖਾਲੀ ਥਾਂ ਭਰਦਾ ਹੈ। ਸਭ ਕੁਝ key ਤੋਂ infer ਕਰਨ ਦੀ ਬਜਾਇ, ਤੁਹਾਨੂੰ ਹਰ request ਦੇ ਪਿੱਛੇ actor ਦੀ classification ਮਿਲਦੀ ਹੈ, ਉਸ ਸਬੂਤ ਸਮੇਤ ਜੋ ਇਸ ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇਹੀ ਕੰਮ Proof of Actor ਪੇਸ਼ ਕਰਨ ਲਈ ਬਣਿਆ ਹੈ, ਅਤੇ APIs use case ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ API teams ਇਸ ਨੂੰ route ਦਰ route ਕਿਵੇਂ ਲਾਗੂ ਕਰਦੀਆਂ ਹਨ।

API teams ਨੂੰ ਹੁਣ actor context ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ

APIs ਵੱਲ automated traffic ਨਵਾਂ ਨਹੀਂ ਹੈ। scripts, integrations ਅਤੇ crawlers ਹਮੇਸ਼ਾ ਇਸ ਤਸਵੀਰ ਦਾ ਹਿੱਸਾ ਰਹੇ ਹਨ। ਜੋ ਬਦਲਿਆ ਹੈ, ਉਹ automation ਦੀ ਕਿਸਮ ਹੈ। AI agents documentation ਪੜ੍ਹ ਸਕਦੇ ਹਨ, calls ਨੂੰ ਇਕੱਠਾ ਜੋੜ ਸਕਦੇ ਹਨ, creatively retry ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਦੀ ਓਰੋਂ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਹਰ ਕਦਮ ਨਹੀਂ ਦੇਖ ਰਹੇ ਹੁੰਦੇ। ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਈ ਉਪਯੋਗੀ ਅਤੇ ਸਵਾਗਤਯੋਗ ਹਨ। ਕੁਝ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਬਣੇ। ਕੁਝ ਹਮਲਾਵਰ ਹੁੰਦੇ ਹਨ।

Actor context ਤੋਂ ਬਿਨਾਂ, API teams ਅਕਸਰ ਮੋਟੇ ਹਥਿਆਰਾਂ ਵੱਲ ਮੁੜ ਜਾਂਦੀਆਂ ਹਨ:

ਹਰ key ਲਈ rate limits, ਜੋ ਚੰਗੇ agents ਅਤੇ ਮਾੜੇ agents ਦੋਵਾਂ ਨੂੰ ਇੱਕੋ ਜਿਹਾ slow down ਕਰ ਦਿੰਦੀਆਂ ਹਨ।
User-agent rules, ਜੋ ਉਸੇ ਪਲ ਟੁੱਟ ਜਾਂਦੀਆਂ ਹਨ ਜਦੋਂ client ਆਪਣਾ header ਬਦਲ ਲੈਂਦਾ ਹੈ।
ਸਾਰਵਭੌਮ blocks, ਜੋ legitimate automation ਨੂੰ ਤੁਹਾਡੇ web app ਨੂੰ scrape ਕਰਨ ਵੱਲ ਧੱਕ ਦਿੰਦੀਆਂ ਹਨ।

Actor context ਤੁਹਾਨੂੰ ਸਹੀਤਾ ਨਾਲ ਜਵਾਬ ਦੇਣ ਦਿੰਦਾ ਹੈ। ਇੱਕ operator ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਪਹਿਚਾਣਦੇ ਹੋ, ਉਸ ਦਾ signed agent read routes 'ਤੇ ਵਧੇਰੇ limit ਲੈ ਸਕਦਾ ਹੈ। ਇੱਕ unknown caller ਜੋ write route ਨੂੰ hit ਕਰਦਾ ਹੈ, ਉਸ ਤੋਂ stronger credential ਮੰਗਿਆ ਜਾ ਸਕਦਾ ਹੈ। AI assistant ਵਰਤ ਰਹੇ human ਲਈ normal experience ਜਾਰੀ ਰਹਿ ਸਕਦੀ ਹੈ। ਮਕਸਦ agents ਨੂੰ ਰੋਕਣਾ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਹਰ ਕਿਸਮ ਦੇ caller ਲਈ ਸਹੀ ਰਾਹ ਦੇਣਾ ਹੈ। Signed request ਤੁਹਾਨੂੰ ਕੀ ਦੱਸ ਸਕਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ, ਇਸ ਲਈ what signed AI agent requests prove ਪੜ੍ਹੋ।

Proof of Actor ਵਿੱਚ AI agent identification ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

Proof of Actor ਹਰ request ਲਈ ਇੱਕੋ evidence-first flow ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਪੂਰਾ walkthrough How It Works 'ਤੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ; ਇੱਥੇ API teams ਲਈ ਛੋਟਾ ਸੰਸਕਰਣ ਹੈ।

1. ਤੁਹਾਡੀ integration ਤੋਂ signals

ਤੁਹਾਡੀ integration ਉਸ context ਵਿੱਚ ਉਪਲਬਧ signals Proof of Actor ਨੂੰ ਦਿੰਦੀ ਹੈ। ਇੱਕ API ਲਈ, ਇਸਦਾ ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ request context ਹੁੰਦਾ ਹੈ ਜਿਵੇਂ headers ਅਤੇ protocol details, ਕੋਈ ਵੀ cryptographic request signatures ਜੋ client ਦਿੰਦਾ ਹੈ, ਅਤੇ client ਆਪਣੇ ਬਾਰੇ ਜੋ declarations ਕਰਦਾ ਹੈ। ਹਰ signal ਨੂੰ ਉਸ ਦੇ ਸਰੋਤ ਨਾਲ label ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

2. ਅਧਾਰ ਸਮੇਤ classification

Signals ਨੂੰ ਜਾਂਚ ਕੇ ਅਤੇ ਜੋੜ ਕੇ ਚਾਰ public classes ਵਿੱਚੋਂ ਇੱਕ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ:

Human: ਵੇਖਣਯੋਗ signals ਇੱਕ human-directed interaction ਦਰਸਾਉਂਦੇ ਹਨ।
Human + AI: AI assistance declare ਕੀਤੀ ਗਈ ਸੀ ਜਾਂ ਉਸ integration ਦੁਆਰਾ ਪਤਾ ਲੱਗੀ ਸੀ ਜੋ ਇਸ ਨੂੰ observe ਕਰ ਸਕਦੀ ਹੈ।
Agent: automated ਜਾਂ agent-origin traffic, ਜੋ verifiable identity ਜਾਂ ਧਿਆਨ ਨਾਲ qualify ਕੀਤੀ inference ਨਾਲ ਸਮਰਥਿਤ ਹੈ।
Unknown: ਸਬੂਤ reliable determination ਨੂੰ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ।

ਹਰ ਨਤੀਜੇ ਨਾਲ ਉਸ ਦਾ basis ਵੀ ਹੁੰਦਾ ਹੈ: verified, declared, inferred ਜਾਂ unknown। ਇਹ ਉਹ ਹਿੱਸਾ ਹੈ ਜਿਸ ਨੂੰ API teams ਸਭ ਤੋਂ ਵੱਧ ਮਹੱਤਵ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ request ਜਿਸ ਦਾ HTTP message signature, ਜਿਵੇਂ RFC 9421 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਹੈ, published key ਨਾਲ validate ਹੁੰਦਾ ਹੈ, ਉਸ ਨੂੰ verified ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ। ਇੱਕ client ਜੋ ਸਿਰਫ਼ ਆਪਣੇ ਆਪ ਨੂੰ agent ਦੱਸਦਾ ਹੈ, ਉਹ declared ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ। ਇੱਕ pattern ਜੋ automated ਲੱਗਦਾ ਹੈ, ਉਹ inferred ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਕਦੇ ਇਹ ਸੋਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਨਤੀਜਾ cryptography 'ਤੇ ਆਧਾਰਿਤ ਹੈ ਜਾਂ heuristic 'ਤੇ। evidence basis answer ਦਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ।

3. ਇੱਕ ਨਤੀਜਾ ਜਿਸ 'ਤੇ ਤੁਹਾਡਾ code ਕਾਰਵਾਈ ਕਰ ਸਕੇ

ਨਤੀਜਾ class, basis ਅਤੇ ਇੱਕ readable evidence summary ਨਾਲ ਤੁਹਾਡੀ application ਨੂੰ ਵਾਪਸ ਮਿਲਦਾ ਹੈ। ਤੁਹਾਡਾ code ਨਿਰਣੈ ਕਰਦਾ ਹੈ ਕਿ ਉਸ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ। observation mode ਵਿੱਚ, ਤੁਸੀਂ ਸਿਰਫ਼ ਉਸ ਨੂੰ record ਕਰਦੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋ, ਤੁਸੀਂ ਉਸ ਦੇ ਆਧਾਰ 'ਤੇ route ਕਰਦੇ ਹੋ।

ਤੁਹਾਡੀ team ਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ: Detect, Understand, Route

Proof of Actor ਇੱਕ ਹੀ product ਹੈ ਜਿਸ ਵਿੱਚ ਤਿੰਨ capabilities ਹਨ।

Detect

ਉਹ actor signals ਇਕੱਠੇ ਕਰੋ ਜੋ ਤੁਹਾਡਾ API ਦੇਖ ਸਕਦਾ ਹੈ ਅਤੇ verified assertions ਨੂੰ behavioral inferences ਤੋਂ ਵੱਖ ਕਰੋ। Signed agent requests, declared clients, automation signals ਅਤੇ Unknown results ਸਾਰੇ ਵੱਖਰੇ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਕੁਝ ਵੀ ਚੁਪਚਾਪ ਇੱਕੋ score ਵਿੱਚ ਨਾ ਮਿਲੇ।

Understand

ਦੇਖੋ ਕਿਹੜੇ actors ਕਿਹੜੇ routes ਨੂੰ call ਕਰਦੇ ਹਨ, ਇਹ ਸਮੇਂ ਦੇ ਨਾਲ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਹਰ classification ਦੇ ਪਿੱਛੇ ਕਿਹੜਾ ਸਬੂਤ ਹੈ। Unknown rate ਦਿਖਾਈ ਦਿੰਦੀ ਰਹਿੰਦੀ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਦੱਸਦੀ ਹੈ ਕਿ ਤੁਹਾਡੀ coverage ਕਿੱਥੇ ਖਤਮ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕਿੱਥੇ stronger signal ਮਦਦਗਾਰ ਹੋਵੇਗਾ।

Route

ਹਰ route ਅਤੇ ਹਰ risk tier ਲਈ policies ਲਿਖੋ: allow, adapt, challenge, review ਜਾਂ rate-limit। verified agents ਲਈ read-only endpoints 'ਤੇ ਇੱਕ structured, generous path ਰੱਖੋ। high-impact operations 'ਤੇ stronger credentials ਮੰਗੋ। Unknown ਅਤੇ timeouts ਲਈ explicit fallback define ਕਰੋ, ਤਾਂ ਜੋ ਜੋ ਕੁਝ ਵੀ ਹੋਵੇ ਤੁਹਾਡਾ API predictably behave ਕਰੇ। ਤੁਸੀਂ ਇਹ ਤੈਅ ਕਰਦੇ ਹੋ ਕਿ ਹਰ policy ਕਿਵੇਂ fail ਕਰੇਗੀ, open ਜਾਂ closed, ਉਸ route 'ਤੇ ਗਲਤੀ ਦੀ ਲਾਗਤ ਦੇ ਆਧਾਰ 'ਤੇ।

Identity evidence, credentials ਅਤੇ authorization ਤਿੰਨ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ

Agent-aware API design ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਗਲਤੀ ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲਾਂ ਨੂੰ ਇੱਕ ਵਿੱਚ ਮਿਲਾ ਦੇਣੀ ਹੈ। Proof of Actor ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ design ਨੂੰ ਵੀ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

Identity evidence: ਕਿਹੜਾ actor call ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਸ ਦਾ ਸਬੂਤ ਕੀ ਹੈ? ਇਹੀ AI agent identification ਦਿੰਦੀ ਹੈ। ਇੱਕ verified signature request ਨੂੰ ਇੱਕ key ਅਤੇ ਉਸ ਦੇ published operator identifier ਨਾਲ ਜੋੜਦੀ ਹੈ। IETF Web Bot Auth working group ਨੂੰ automated clients ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਦੀ cryptographic authentication standardize ਕਰਨ ਲਈ charter ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਉਸ ਦਾ scope agent ਨੂੰ authenticate ਕਰਨ 'ਤੇ ਹੈ, ਨਾ ਕਿ end user 'ਤੇ।
Credentials: ਇਸ call ਲਈ ਕਿਹੜਾ account ਜ਼ਿੰਮੇਵਾਰ ਹੈ? ਇਹ ਤੁਹਾਡੀ API key, token ਜਾਂ session ਹੈ, ਜੋ ਤੁਹਾਡੇ ਦੁਆਰਾ issue ਅਤੇ manage ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
Authorization: ਕੀ ਇਸ caller ਨੂੰ ਇਹ ਖਾਸ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ? ਇਹ ਤੁਹਾਡਾ permission model ਹੈ।

ਇੱਕ verified agent ਆਪਣੇ ਆਪ authorized agent ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ valid signature ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਕਿਸੇ person ਨੇ agent ਨੂੰ authority delegate ਕੀਤੀ ਸੀ, ਅਤੇ ਇਹ requested action ਨੂੰ safe ਨਹੀਂ ਬਣਾਉਂਦੀ। Proof of Actor ਤੁਹਾਨੂੰ ਪਹਿਲੇ ਸਵਾਲ ਲਈ ਭਰੋਸੇਯੋਗ context ਦਿੰਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਅਤੇ ਤੀਜੇ ਨੂੰ ਬਿਲਕੁਲ ਉੱਥੇ ਛੱਡਦਾ ਹੈ ਜਿੱਥੇ ਉਹ belong ਕਰਦੇ ਹਨ: ਤੁਹਾਡੀ application ਵਿੱਚ। ਹੋਰ ਪੜ੍ਹੋ agent authorization 'ਤੇ ਅਤੇ Detection & Limitations 'ਤੇ ਇਸ ਬਾਰੇ ਕਿ ਸਬੂਤ ਕੀ establish ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ।

Unknown ਇੱਕ feature ਹੈ, failure ਨਹੀਂ

Request signing optional ਹੈ, ਅਤੇ ਇੱਕ unsigned client ਆਪਣੇ ਆਪ ਨੂੰ ਜਿਵੇਂ ਚਾਹੇ ਤਿਵੇਂ describe ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ system ਜੋ ਹਰ request ਨੂੰ Human ਜਾਂ Agent ਵਿੱਚ force ਕਰਦਾ ਹੈ, ਉਹ ਕੁਝ ਵਾਰ confidently wrong ਹੋਵੇਗਾ, ਅਤੇ ਤੁਹਾਨੂੰ ਇਹ ਪਤਾ ਨਹੀਂ ਹੋਵੇਗਾ ਕਿ ਕਦੋਂ।

ਜਦੋਂ ਸਬੂਤ ਕਿਸੇ determination ਨੂੰ support ਨਹੀਂ ਕਰਦਾ, Proof of Actor Unknown report ਕਰਦਾ ਹੈ। Unknown ਨੂੰ ਕਦੇ ਵੀ Human ਵਿੱਚ convert ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਅਤੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਕਦੇ malicious ਨਹੀਂ ਮੰਨਿਆ ਜਾਂਦਾ। ਤੁਹਾਡੀ policy ਹਰ route ਲਈ Unknown ਦਾ ਅਰਥ define ਕਰਦੀ ਹੈ: public reads 'ਤੇ ਇਸ ਨੂੰ allow ਕਰੋ, account changes 'ਤੇ ਆਪਣੀਆਂ ਮੌਜੂਦਾ checks ਰੱਖੋ, ਜਿੱਥੇ stakes high ਹਨ ਉੱਥੇ ਇਸ ਨੂੰ review ਲਈ queue ਕਰੋ। Unknown ਨੂੰ visible ਰੱਖਣਾ ਹੀ ਤੁਹਾਡੀਆਂ ਹੋਰ classifications ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। handling unknown traffic ਵਾਲਾ guide ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇਸ ਲਈ ਕਿਵੇਂ design ਕਰਨਾ ਹੈ।

ਤੁਹਾਡੇ stack ਵਿੱਚ AI agent identification ਕਿੱਥੇ fit ਹੁੰਦੀ ਹੈ

Proof of Actor ਤੁਹਾਡੇ ਮੌਜੂਦਾ gateway, authentication ਅਤੇ rate limiting ਦੇ ਨਾਲ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ। ਆਮ placements ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

Server-side middleware, route handlers ਤੋਂ ਪਹਿਲਾਂ, ਤਾਂ ਜੋ ਤੁਹਾਡੀ business logic ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ request evaluate ਹੋ ਜਾਵੇ।
At the edge, ਤਾਂ ਜੋ requests origin ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ signals evaluate ਹੋ ਜਾਣ।
ਇੱਕ generic HTTP integration, ਤਾਂ ਜੋ ਕੋਈ ਵੀ stack request context ਭੇਜ ਸਕੇ ਅਤੇ ਉਸ ਦਾ basis ਸਮੇਤ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕੇ।

Integrations ਹਰ founding team ਨਾਲ onboarding ਦੌਰਾਨ hands-on delivered ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ path ਤੁਹਾਡੀ architecture ਨਾਲ ਮੇਲ ਖਾਏ, ਉਲਟ ਨਹੀਂ। developer hub ਅੱਜ ਉਪਲਬਧ integration paths ਦਿਖਾਉਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ agents ਲਈ tools ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ MCP Servers use case tool calls ਲਈ ਖਾਸ patterns ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।

Observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ

Proof of Actor install ਕਰਨ ਨਾਲ ਤੁਹਾਡਾ API ਕਿਵੇਂ respond ਕਰਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਬਦਲਦਾ। Results record ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਜੋ ਤੁਹਾਡੀ team ਉਨ੍ਹਾਂ ਦੀ ਤੁਲਨਾ ਉਹਨਾਂ outcomes ਨਾਲ ਕਰ ਸਕੇ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹੋ, ਦੇਖ ਸਕੇ ਕਿ agents ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਜਾਂਦੇ ਹਨ, ਹਰ route 'ਤੇ unknown rate ਮਾਪ ਸਕੇ, ਅਤੇ ਕੋਈ ਵੀ classification ਜੋ ਗਲਤ ਲੱਗਦੀ ਹੈ, ਉਸ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕੇ। ਇਸ ਤੋਂ ਬਾਅਦ ਹੀ ਤੁਸੀਂ ਇੱਕ policy enable ਕਰਦੇ ਹੋ, route ਦਰ route, ਜਿੱਥੇ ਸਬੂਤ ਇਸ ਨੂੰ support ਕਰਦਾ ਹੈ।

ਇਹੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ AI agent identification ਨੂੰ ਆਪਣੇ customers ਨੂੰ ਹੈਰਾਨ ਕੀਤੇ ਬਿਨਾਂ ਜਾਂ ਉਹ integrations ਤੋड़े ਬਿਨਾਂ roll out ਕਰਦੇ ਹੋ, ਜਿਨ੍ਹਾਂ 'ਤੇ ਉਹ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। rolling out actor-aware policies safely ਵਾਲਾ guide ਇਹ sequence step by step ਸਮਝਾਉਂਦਾ ਹੈ।

founding developer program ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ

Proof of Actor private beta ਵਿੱਚ ਇੱਕ ਛੋਟੀ founding development teams ਦੀ group ਨਾਲ ਹੈ। ਚੁਣੀਆਂ ਗਈਆਂ teams onboarding ਦੌਰਾਨ agreed usage limits ਦੇ ਅੰਦਰ up to 12 months free access ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਨਾਲ ਹੀ ਸਾਡੇ engineers ਵਲੋਂ direct integration support ਅਤੇ ਅਸੀਂ ਅੱਗੇ ਕੀ ਬਣਾਉਂਦੇ ਹਾਂ, ਇਸ 'ਤੇ ਅਸਲੀ influence।

ਜੇ ਤੁਸੀਂ ਇੱਕ API ਚਲਾਉਂਦੇ ਹੋ ਅਤੇ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਸ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੌਣ call ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ apply for early access ਕਰੋ। ਸਾਨੂੰ ਆਪਣੇ API ਬਾਰੇ, ਉਹ routes ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਪਰਵਾਹ ਹੈ, ਅਤੇ ਉਹ decisions ਬਾਰੇ ਦੱਸੋ ਜੋ ਤੁਸੀਂ actor context ਹੋਣ 'ਤੇ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਲੈਂਦੇ। ਅਸੀਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗੇ ਕਿ Proof of Actor ਕਿੱਥੇ fit ਹੁੰਦਾ ਹੈ।

ਸਰੋਤ

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.

ਡਿਵੈਲਪਰਾਂ ਲਈ

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 ਪੜ੍ਹੋ

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

AI agent identification API key authentication ਤੋਂ ਕਿਵੇਂ ਵੱਖ ਹੈ?

API key ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜੇ account ਨੇ request ਭੇਜੀ। AI agent identification ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ request ਦੇ ਪਿੱਛੇ ਕਿਹੜਾ actor ਹੈ ਅਤੇ ਉਸ ਨਤੀਜੇ ਨੂੰ ਕਿਹੜਾ ਸਬੂਤ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਦੋਵੇਂ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਇਹ ਵੱਖ-ਵੱਖ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ।

ਕੀ Proof of Actor ਮੇਰੇ API ਨੂੰ ਕਾਲ ਕਰਨ ਵਾਲੇ ਹਰ AI agent ਦੀ ਪਛਾਣ ਕਰ ਸਕਦਾ ਹੈ?

Proof of Actor ਹਰ request ਨੂੰ Human, Human + AI, Agent ਜਾਂ Unknown ਵਜੋਂ ਵਰਗੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ ਨਤੀਜੇ ਲਈ ਅਧਾਰ ਦੱਸਦਾ ਹੈ। ਜਦੋਂ ਸਬੂਤ ਕਾਫ਼ੀ ਮਜ਼ਬੂਤ ਨਹੀਂ ਹੁੰਦਾ, ਨਤੀਜਾ Unknown ਹੁੰਦਾ ਹੈ, ਅਨੁਮਾਨ ਨਹੀਂ।

ਕੀ ਕਿਸੇ agent ਦੀ ਪਛਾਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਸ ਨੂੰ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ?

ਨਹੀਂ। ਪਛਾਣ ਅਤੇ authorization ਵੱਖ ਹਨ। Proof of Actor ਤੁਹਾਡੀ application ਨੂੰ caller ਬਾਰੇ context ਦਿੰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਆਪਣੇ authorization rules ਫ਼ੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਉਹ caller ਕੀ ਕਰ ਸਕਦਾ ਹੈ।

ਕੀ Proof of Actor ਮੇਰੇ API ਲਈ requests ਨੂੰ block ਕਰੇਗਾ?

ਨਾ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਹ ਨਾ ਚਾਹੋ। ਹਰ integration observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ enforcement ਸਿਰਫ਼ ਉਹਨਾਂ policies ਰਾਹੀਂ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਹਾਡੀ team ਲਿਖਦੀ ਅਤੇ enable ਕਰਦੀ ਹੈ।

ਮੈਨੂੰ access ਕਿਵੇਂ ਮਿਲੇਗਾ?

Proof of Actor private beta ਵਿੱਚ ਹੈ। early access ਲਈ apply ਕਰੋ, ਅਤੇ ਚੁਣੀਆਂ ਗਈਆਂ founding developer teams agreed usage limits ਦੇ ਅੰਦਰ up to 12 months free access ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀਆਂ ਹਨ।

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

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

ਅਗਾਊਂ ਪਹੁੰਚ ਲਵੋ ਕੀਮਤ ਵੇਖੋ

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