વ્યાખ્યા
એક actor પરિણામનો પુરાવો આધાર તેના પાછળના પુરાવાના પ્રકારનું વર્ણન કરે છે. Proof of Actor ચાર મૂલ્યોનો ઉપયોગ કરે છે:
- verified: એક cryptographic અથવા અન્ય રીતે ચકાસી શકાય તેવો assertion સફળ થયો.
- declared: actor અથવા application એ તે જણાવ્યું.
- inferred: વર્તન અથવા સંદર્ભ સંકેતો પરથી નિષ્કર્ષ કાઢવામાં આવ્યો.
- unknown: નિર્ણય માટે પૂરતું પુરાવો નહોતો.
દરેક પરિણામમાં એક class (Human, Human + AI, Agent અથવા Unknown, અમારી application traffic માટેની taxonomy માં વર્ણવેલ) અને એક basis બંને હોય છે. "Agent, verified" અને "Agent, inferred" અલગ પરિણામો છે અને તેમને અલગ રીતે હાથ ધરવા જોઈએ.
basis કેમ મહત્વનું છે
basis વિના, વર્ગીકરણ એ છુપાવે છે કે તે કેટલો ભાર સહન કરી શકે છે. એક dashboard જેમાં signed request માટે "Agent" અને request timing પર આધારિત અંદાજ માટે પણ "Agent" દેખાય છે, તે ટીમોને બંને માટે એકસરખી policy લાગુ કરવા પ્રેરિત કરે છે. ખાસ કરીને security-sensitive applications માટે, inference ક્યારેય cryptographic verification જેવું દેખાવું જોઈએ નહીં.
class ને basis થી અલગ રાખવાથી policies પુરાવાની મજબૂતી સાથે મેળ ખાતી બને છે:
- એક read-only route કોઈપણ Agent પરિણામને allow કરી શકે છે.
- વધુ અસરવાળા route માં માત્ર verified agents ને known operators તરીકે ગણવામાં આવી શકે છે અને બાકીના બધાથી વધુ મજબૂત credentials માંગવામાં આવી શકે છે.
ચાર મૂલ્યો વિગતમાં
Verified
કશુંક ચકાસાયું અને પાસ થયું. સૌથી સ્પષ્ટ ઉદાહરણ છે એક HTTP message signature (RFC 9421) જે agent ના operator દ્વારા પ્રકાશિત key સામે validate થાય છે. Verified evidence ચોક્કસ check સાબિત કરે છે, અને તેના કરતાં વધુ કંઈ નહીં: માન્ય signature બતાવે છે કે request કઈ key દ્વારા sign થઈ, પરંતુ action authorized હતું તે બતાવતું નથી.
Declared
કોઈએ એમ કહ્યું. પોતાને agent તરીકે ઓળખાવતો client, એક MCP client નામ, અથવા તમારી પોતાની applicationની અંદર AI-assistance disclosure એ declarations છે. તે ઉપયોગી, ઘણી વખત સાચા, અને ક્યારેક ખોટા પણ હોઈ શકે છે. User-agent spoofing ખોટી declaration નું શાસ્ત્રીય ઉદાહરણ છે. User-Agent header ડિઝાઇન મુજબ self-reported છે.
Inferred
સિસ્ટમે સંકેતો પરથી તારણ કાઢ્યું: browser session માં interaction patterns, request timing, browser context ની અછત, protocol details. Inferences ખોટા પણ હોઈ શકે છે, એટલે જ તેમને હંમેશા inferences તરીકે લેબલ કરવામાં આવે છે અને એટલે જ લોકો વિશેના પરિણામકારક નિર્ણયો માત્ર તેમના પર ક્યારેય આધારિત ન હોવા જોઈએ.
Unknown
પુરાવાએ નિર્ણયને સમર્થન આપ્યું નહોતું. આ Unknown classification સાથે જોડાય છે અને તમારી policy માં સ્પષ્ટ fallback સાથે નકશાંકિત થવું જોઈએ. AI traffic ને વર્ગીકૃત કરતી વખતે Unknown કેમ માન્ય પરિણામ છે પરનો અમારો લેખ સમજાવે છે કે કેમ.
basis સામે confidence scores
ઘણી systems પુરાવાને એક જ સંખ્યામાં સંકુચિત કરે છે. એક score છુપાવે છે કે તે cryptographic check પરથી આવ્યું હતું કે heuristic પરથી, અને અંકલિત ટકા એવી ચોકસાઈ સૂચવે છે જે અસ્તિત્વમાં નથી. નામિત bases નો નાનો સમૂહ સમજવા માટે વધુ સરળ, audit કરવા માટે વધુ સરળ, અને દુરુપયોગ કરવો વધુ મુશ્કેલ છે.
સામાન્ય ગેરસમજો
"Declared એટલે અવિશ્વસનીય." Declarations ઘણી વાર સાચી હોય છે અને કેટલીક બાબતો માટે, જેમ કે AI-assistance disclosure, ઉપલબ્ધ એકમાત્ર પુરાવો પણ હોય છે. તેમને માત્ર verification તરીકે ગણવી ન જોઈએ.
"Verified એટલે સુરક્ષિત." Verification signer ની ઓળખ વિશે છે, ઇરાદા અથવા પરવાનગી વિશે નહીં.
Proof of Actor માં પુરાવો આધાર
દરેક Proof of Actor પરિણામ તેનો basis અને પુરાવાનો human-readable સારાંશ જણાવે છે. Policies તમારી application માં ચાલે છે અને class અને basis ને સાથે ઉપયોગ કરી શકે છે. Detection & Limitations જુઓ અથવા early access માટે અરજી કરો.
સ્ત્રોતો
- RFC 9421: HTTP Message Signatures: verified પુરાવાનો સૌથી સ્પષ્ટ સ્ત્રોત
- RFC 9110: HTTP Semantics, User-Agent: એક self-reported, declared identifier