AI એજન્ટ ઓળખાણ

API માટે AI એજન્ટ ઓળખાણ

તમારું API પહેલેથી જ જાણે છે કે કઈ key એ request કરી. Proof of Actor તમને જણાવે છે કે તેના પાછળ કયો પ્રકારનો actor હતો, કયો પુરાવો તેને આધાર આપે છે, અને તમારો code આગળ શું થશે તે નક્કી કરવા દે છે.

પ્રારંભિક ઍક્સેસ મેળવો તે કેવી રીતે કાર્ય કરે છે તે અન્વેષણ કરો

દ્વારા Toshendra Sharmaસ્થાપક અને CEO, AgentCredia · Updated November 13, 2026

તમારું API key જાણે છે. તે actor જાણતું નથી.

દરેક API request સાથે કોણ તેના માટે ચૂકવણી કરે છે તેનો કંઈક પુરાવો આવે છે: એક API key, એક OAuth token, એક session. એ પુરાવો એક પ્રશ્નનો સારો જવાબ આપે છે. તે તમને જણાવે છે કે call માટે કયું account જવાબદાર છે. તે તમને નથી જણાવતું કે હાલ ખરેખર call કોણ અથવા શું કરી રહ્યું છે.

એક જ API key નો ઉપયોગ terminal માં પરીક્ષણ કરતો developer, schedule પર ચાલતો backend job, AI assistant સાથે કામ કરતો person, અને task પૂરો કરવા માટે key આપવામાં આવેલ autonomous agent - બધાં કરી શકે છે. આ બધાં અલગ actors છે. તેમની ગતિ અલગ છે, failure modes અલગ છે, અને risk profiles પણ અલગ છે. બધાને એક જ રીતે扱વાથી તમે તો તમારા customers આધાર રાખે છે તેવી legitimate automation પર વધારે પ્રતિબંધ મૂકો છો, અથવા તમારી API ના એવા ભાગોને ઓછું સુરક્ષિત કરો છો જેને unattended agent ક્યારેય ચલાવવો ન જોઈએ.

API માટે AI agent ઓળખાણ આ ખાલી જગ્યા ભરે છે. માત્ર key પરથી બધું અનુમાન કરવાની બદલે, તમને દરેક request પાછળના actor નું વર્ગીકરણ મળે છે, સાથે તેને આધાર આપતો પુરાવો પણ. Proof of Actor આ જ આપવા માટે બનાવાયું છે, અને APIs use case બતાવે છે કે API teams તેને route-by-route કેવી રીતે લાગુ કરે છે.

API teams ને હવે actor context કેમ જોઈએ

APIs પર automated traffic નવું નથી. Scripts, integrations અને crawlers હંમેશાં ચિત્રનો ભાગ રહ્યા છે. જે બદલાયું છે તે automation નો પ્રકાર છે. AI agents documentation વાંચી શકે છે, calls ને જોડીને કામ કરી શકે છે, સર્જનાત્મક રીતે retry કરી શકે છે, અને એવા લોકોની તરફથી કાર્ય કરી શકે છે જે દરેક પગથિયું જોઈ રહ્યા નથી. તેમામાંથી ઘણા ઉપયોગી અને સ્વાગતનીય છે. કેટલાક નબળા બનેલા છે. થોડાક hostile છે.

Actor context વગર, API teams સામાન્ય રીતે કડક સાધનો તરફ વળે છે:

પ્રતિ key rate limits, જે સારા agents અને ખરાબ agents બંનેને સમાન રીતે ધીમા કરે છે.
User-agent નિયમો, જે client header બદલતાં જ તૂટી જાય છે.
વ્યાપક blocks, જે legitimate automation ને બદલે તમારી web app ને scrape કરવા ધકેલી દે છે.

Actor context તમને ચોકસાઈ સાથે પ્રતિસાદ આપવા દે છે. તમે ઓળખતા operator તરફથી signed agent ને read routes પર વધારે limit આપી શકો છો. write route ને સ્પર્શતો unknown caller વધુ મજબૂત credential માટે કહેવામાં આવી શકે છે. AI assistant સાથે કામ કરતો person સામાન્ય અનુભવ જાળવી શકે છે. મુદ્દો agents ને અટકાવવાનો નથી. મુદ્દો દરેક પ્રકારના caller ને યોગ્ય માર્ગ આપવા નો છે. signed request શું કહી શકે છે અને શું નહીં, તે માટે what signed AI agent requests prove વાંચો.

Proof of Actor માં AI agent ઓળખાણ કેવી રીતે કામ કરે છે

Proof of Actor દરેક request માટે evidence-first flow અપનાવે છે. સંપૂર્ણ walkthrough How It Works પર છે; અહીં API teams માટે ટૂંકો સાર છે.

1. તમારી integrationમાંથી signals

તમારી integration તે context માં ઉપલબ્ધ signals Proof of Actor ને આપે છે. API માટે, તેમાં સામાન્ય રીતે headers અને protocol વિગતો જેવા request context, client આપે તેવા કોઈપણ cryptographic request signatures, અને client પોતે વિશે કરેલી કોઈપણ declarations સામેલ હોય છે. દરેક signal ને તે ક્યાંથી આવ્યું તેના સાથે label કરવામાં આવે છે.

2. આધાર સાથેનું વર્ગીકરણ

Signals તપાસીને અને જોડીને ચાર public classes માંથી એકમાં મૂકવામાં આવે છે:

Human: જોવા મળતા signals human-directed interaction દર્શાવે છે.
Human + AI: AI સહાય જાહેર કરવામાં આવી હતી અથવા તેને જોઈ શકતી integration દ્વારા શોધવામાં આવી હતી.
Agent: automated અથવા agent-origin traffic, verifiable identity અથવા કાળજીપૂર્વક qualified inference દ્વારા આધારિત.
Unknown: પુરાવો વિશ્વસનીય નિર્ધારણને ટેકો આપતો નથી.

દરેક પરિણામ સાથે તેનો basis પણ હોય છે: verified, declared, inferred અથવા unknown. API teams ને આ ભાગ સૌથી વધુ ઉપયોગી લાગે છે. HTTP message signature, જેમ કે RFC 9421 માં વ્યાખ્યાયિત છે, જો published key સામે માન્ય થાય, તો પરિણામ verified તરીકે જણાવવામાં આવે છે. જે client પોતાને agent તરીકે નામ આપે છે, તે declared તરીકે જણાવવામાં આવે છે. જે pattern automated લાગે છે, તે inferred તરીકે જણાવવામાં આવે છે. તમને ક્યારેય વિચારવું પડતું નથી કે પરિણામ cryptography પર આધારિત છે કે heuristic પર. evidence basis જવાબનો ભાગ છે.

3. એવું પરિણામ જેને તમારો code ઉપયોગમાં લઈ શકે

પરિણામ class, basis અને વાંચી શકાય એવો evidence summary સાથે તમારી application ને પાછું મળે છે. તમારો code નક્કી કરે છે કે તેની સાથે શું કરવું. observation mode માં, તમે તેને માત્ર record કરો છો. જ્યારે તમે તૈયાર હો, ત્યારે તમે તેના આધાર પર route કરો છો.

તમારી ટીમને શું મળે છે: Detect, Understand, Route

Proof of Actor એક જ product છે, પરંતુ તેની ત્રણ ક્ષમતાઓ છે.

Detect

તમારું API જે actor signals જોઈ શકે છે તે ભેગાં કરો અને verified assertions ને behavioral inferences થી અલગ કરો. Signed agent requests, declared clients, automation signals અને Unknown results બધા અલગ રાખવામાં આવે છે, જેથી કશુંપણ ચૂપચાપ એક જ score માં ભળી ન જાય.

Understand

કયા actors કયા routes પર કૉલ કરે છે, તે સમય સાથે કેવી રીતે બદલાય છે, અને દરેક classification પાછળ કયો પુરાવો છે તે જુઓ. Unknown rate દેખાતી રહે છે, જેથી તમને ચોક્કસ ખબર પડે છે કે તમારી coverage ક્યાં સમાપ્ત થાય છે અને ક્યાં વધુ મજબૂત signal મદદરૂપ થશે.

Route

દરેક route અને risk tier માટે policies લખો: allow, adapt, challenge, review અથવા rate-limit. read-only endpoints પર verified agents માટે રચનાત્મક, ઉદાર માર્ગ રાખો. high-impact operations માટે વધુ મજબૂત credentials માગો. Unknown અને timeouts માટે સ્પષ્ટ fallback નિર્ધારિત કરો, જેથી તમારી API જે કંઈ પણ થાય તેમ છતાં આગોતરા રીતે વર્તે. તમે નક્કી કરો છો કે દરેક policy open કે closed કઈ રીતે fail થશે, તે route પર ભૂલનો ખર્ચ કેટલો છે તેના આધારે.

Identity evidence, credentials અને authorization ત્રણ અલગ વસ્તુઓ છે

agent-aware API design માં સૌથી સામાન્ય ભૂલ એ છે કે ત્રણ અલગ પ્રશ્નોને એકમાં ભેળવી દેવા. Proof of Actor તેમને અલગ રાખે છે, અને તમારું design પણ તેમ જ હોવું જોઈએ.

Identity evidence: કયો પ્રકારનો actor call કરી રહ્યો છે, અને તે શું સાબિત કરે છે? આ જ AI agent ઓળખાણ આપે છે. verified signature request ને key અને તેના published operator identifier સાથે જોડે છે. IETF Web Bot Auth working group automated clients માટે આ પ્રકારની cryptographic authentication ને standardize કરવા માટે chartered છે, અને તેની scope end user નહીં, પરંતુ agent ની authentication સુધી વિસ્તરે છે.
Credentials: આ call માટે કયું account જવાબદાર છે? આ તમારું API key, token અથવા session છે, જે તમે જારી કરો છો અને મેનેજ કરો છો.
Authorization: શું આ caller ને આ ચોક્કસ કામ કરવા દેવામાં આવ્યું છે? આ તમારું permission model છે.

Verified agent આપમેળે authorized agent બનતો નથી. માન્ય signature એ સાબિત કરતું નથી કે કોઈ person એ agent ને authority સોંપી હતી, અને તે માંગેલી action સુરક્ષિત છે એવું પણ સાબિત કરતું નથી. Proof of Actor તમને પહેલો પ્રશ્ન માટે વિશ્વસનીય context આપે છે અને બીજો તથા ત્રીજો પ્રશ્ન એ જ જગ્યાએ છોડી દે છે જ્યાં તેમનું સ્થાન છે: તમારી application માં. agent authorization અને પુરાવો શું સ્થાપિત કરી શકે છે અને શું નહીં, તેના વિશે Detection & Limitations પર વધુ વાંચો.

Unknown એક feature છે, નિષ્ફળતા નહીં

Request signing વૈકલ્પિક છે, અને unsigned client પોતાને જેમ ઈચ્છે તેમ વર્ણવી શકે છે. જે system દરેક request ને Human અથવા Agent માં જબરદસ્તી ધકેલે છે, તે ક્યારેક નિશ્ચિત રીતે ખોટું થશે, અને તમને ખબર પણ નહીં પડે.

જ્યારે પુરાવો નિર્ધારણને ટેકો આપતો નથી, ત્યારે Proof of Actor Unknown જણાવે છે. Unknown ને ક્યારેય Human માં ફેરવવામાં આવતું નથી અને default રૂપે ક્યારેય malicious ગણવામાં આવતું નથી. તમારી policy નક્કી કરે છે કે દરેક route માટે Unknown નો અર્થ શું છે: public reads પર તેને મંજૂરી આપો, account changes પર તમારા અસ્તિત્વમાં રહેલા checks જાળવો, stakes ઊંચા હોય ત્યાં review માટે queue કરો. Unknown દેખાતું રાખવું જ તમારી અન્ય classifications ને વિશ્વસનીય બનાવે છે. handling unknown traffic માટેની guide બતાવે છે કે તેની આસપાસ કેવી રીતે design કરવું.

AI agent ઓળખાણ તમારી stack માં ક્યાં ફિટ થાય છે

Proof of Actor તમારા હાલના gateway, authentication અને rate limiting સાથે બેસે છે. તે इनमेंથી કોઈની જગ્યા લેતું નથી. સામાન્ય placements માં સામેલ છે:

Server-side middleware route handlersની આગળ, જેથી business logic ચાલે એ પહેલાં દરેક requestનું મૂલ્યાંકન થાય.
Edge પર, જેથી requests તમારા origin સુધી પહોંચે એ પહેલાં signals નું મૂલ્યાંકન થાય.
Generic HTTP integration, જેથી કોઈપણ stack request context મોકલી શકે અને તેનો આધાર સાથે પરિણામ મેળવી શકે.

Onboarding દરમ્યાન દરેક founding team સાથે integrations હાથથી આપવામાં આવે છે, જેથી માર્ગ તમારી architecture ને અનુસરે, તેનો ઉલટો નહીં. developer hub આજે ઉપલબ્ધ integration paths બતાવે છે. જો તમે agents માટે tools ચલાવો છો, તો MCP Servers use case tool calls માટેની ખાસ patterns આવરી લે છે.

Observation mode માં શરૂઆત કરો

Proof of Actor install કરવાથી તમારું API કેવી રીતે respond કરે છે તેમાં ફેરફાર થતો નથી. પરિણામો record થાય છે જેથી તમારી ટીમ તેમને પહેલેથી જાણીતા outcomes સાથે સરખાવી શકે, agents ખરેખર ક્યાં જાય છે તે જોઈ શકે, દરેક route પર unknown rate માપી શકે, અને ખોટું લાગે તેવા કોઈપણ classification ની સમીક્ષા કરી શકે. ત્યારબાદ જ તમે route by route policy enable કરો છો, જ્યાં પુરાવો તેને ટેકો આપે.

આ રીતે તમે તમારા customers ને આશ્ચર્યમાં મૂક્યા વિના અથવા તેઓ આધાર રાખે છે તેવી integrations તોડ્યા વિના AI agent ઓળખાણ rollout કરો છો. rolling out actor-aware policies safely પરની guide આ ક્રમને પગલુંદર પગલું સમજાવે છે.

founding developer program માં જોડાઓ

Proof of Actor private beta માં છે, અને founding development teams ના નાના સમૂહ સાથે છે. પસંદ કરાયેલા teams ને onboarding દરમિયાન agreed usage limits અંદર up to 12 months માટે free access મળી શકે છે, સાથે અમારા engineers તરફથી direct integration support અને અમે આગળ શું બનાવીએ તેમાં વાસ્તવિક પ્રભાવ પણ મળે છે.

જો તમે API ચલાવો છો અને ખરેખર કોણ તેને કૉલ કરે છે તે જાણવા માંગો છો, તો apply for early access. તમારી API, તમને સૌથી વધુ મહત્વના routes અને actor context સાથે તમે કયા નિર્ણયો અલગ રીતે લેશો તે અમને જણાવો. અમે તમને જણાવીશું કે Proof of Actor કેવી રીતે ફિટ થાય છે.

Sources

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: પરિણામ પાછળના signals, જેથી તમારી team કારણ જોઈ શકે.

observation mode માં શરૂ કરો: પરિણામોને તમારા logsની બાજુમાં નોંધો અને તમે policy પસંદ કરો ત્યાં સુધી કંઈ બદલશો નહીં. Node.js integration guide વાંચો

વારંવાર પૂછાતા પ્રશ્નો

AI એજન્ટ ઓળખાણ API key authentication થી કેવી રીતે અલગ છે?

API key તમને જણાવે છે કે request કોણે મોકલી. AI એજન્ટ ઓળખાણ તમને જણાવે છે કે request પાછળ કયો પ્રકારનો actor છે અને તે નિષ્કર્ષને કયો પુરાવો આધાર આપે છે. તમને બંનેની જરૂર છે, અને તેઓ અલગ પ્રશ્નોના જવાબ આપે છે.

શું Proof of Actor મારા API ને કૉલ કરતા દરેક AI એજન્ટની ઓળખ કરી શકે છે?

Proof of Actor દરેક request ને જે તે જુએ છે તેને Human, Human + AI, Agent અથવા Unknown તરીકે વર્ગીકૃત કરે છે, અને દરેક પરિણામ માટેનો આધાર જણાવે છે. જ્યારે પુરાવો પૂરતો મજબૂત ન હોય, ત્યારે પરિણામ Unknown રહે છે, અંદાજ નહીં.

શું એજન્ટની ઓળખ એટલે તેને કાર્ય કરવાની મંજૂરી છે?

ના. ઓળખ અને authorization અલગ છે. Proof of Actor તમને caller વિશે તમારી application ને context આપે છે, અને તમારા પોતાના authorization નિયમો નક્કી કરે છે કે તે caller શું કરી શકે.

શું Proof of Actor મારા API માટે requests બ્લૉક કરશે?

તમે નક્કી કરો ત્યારે જ. દરેક integration observation mode માં શરૂ થાય છે, અને enforcement માત્ર તમારી ટીમે લખેલી અને સક્રિય કરેલી policies દ્વારા જ થાય છે.

મને access કેવી રીતે મળશે?

Proof of Actor private beta માં છે. early access માટે અરજી કરો અને પસંદ કરાયેલા founding developer teams agreed usage limits અંદર up to 12 months free મેળવી શકે છે.

તમારા app નો ઉપયોગ કોણ કરે છે તે જાણો.

Founding developers ના નાના સમૂહ માટે private beta.

પ્રારંભિક ઍક્સેસ મેળવો કિંમત જુઓ

પહેલાં વાત કરવી પસંદ કરો છો? સ્થાપકો સાથે વાત કરો