મુખ્ય સામગ્રી પર જાઓ
DETECTION & LIMITATIONS

Proof of Actor શું સ્થાપિત કરી શકે છે, અને શું નથી કરી શકતું.

વર્ગીકરણોનું સીધું વર્ણન, તેમની પાછળનું evidence, તેઓ કયા context માં લાગુ પડે છે, અને અમે કઈ મર્યાદાઓને ધ્યાનમાં રાખીને ડિઝાઇન કરીએ છીએ તે.

સંકેતો · પ્રત્યેક સ્ત્રોત માટે છેલ્લી વિનંતી
  • request signaturevalid · sample-crawler.exampleverified
  • client declaration"research-assistant/2.1"declared
  • બ્રાઉઝર ઇન્ટરૅક્શનpointer + keyboard eventsinferred
  • કોઈ supported signals નથીroute not instrumentedunknown

ટૂંકું સંસ્કરણ

Proof of Actor તમને શું કહી શકે છે અને શું ખાતરી આપી શકતું નથી
Proof of Actor તમને શું કહી શકે છે (જ્યારે supported હોય ત્યારે)તે શું ખાતરી આપી શકતું નથી
supported agent request signature માન્ય થાય છે કે નહીં તેકે એજન્ટ સચ્ચાઈભર્યો, સુરક્ષિત, અથવા કોઈપણ ક્રિયા કરવા માટે મંજૂર છે
session ચોક્કસ interactive અથવા automation signals દેખાડે છે કે નહીં તેકે માનવએ તમારી observable integrationની બહાર કોઈ AI ઉપયોગ કર્યો નહોતો
supported workflowમાં AIનો ઉપયોગ declared હતો કે observable હતો તેAI assistance, copied content અથવા બીજા deviceની સર્વત્ર શોધ
કે evidence અપૂરતું હતુંકે કોઈ unknown interaction દુર્ભાવનાપૂર્ણ છે

ઉપલબ્ધતા તમારી ઇન્ટિગ્રેશન અને સક્રિય કરાયેલા ચેક પર આધાર રાખે છે. એપ્લિકેશનના માલિક પાસે અમલના નિર્ણયોનો નિયંત્રણ રહે છે.

વર્ગીકરણો

ચાર public classes. દરેકનો નિર્ધારિત અર્થ અને સ્પષ્ટ મર્યાદા છે.

  • માનવ

    સમર્થિત અવલોકનીય સંકેતો માનવ-નિર્દેશિત ક્રિયા સૂચવે છે.

    અર્થ નથી કે: કે કોઈ AI ઉપયોગમાં લેવાયો નહોતો, અથવા વ્યક્તિની વાસ્તવિક ઓળખ ચકાસાયેલી છે.

  • માનવ + AI

    AI assistance જાહેર કરવામાં આવી હતી, અથવા તેને એવી supported integration દ્વારા detect કરવામાં આવી હતી જે તેને ખરેખર observe કરી શકે.

    અર્થ નથી કે: કે તમામ છુપાયેલા AI ઉપયોગને શોધી શકાય છે, જેમાં બીજા tab અથવા બીજા deviceનો સમાવેશ થાય છે.

  • એજન્ટ

    Automated અથવા agent-origin interaction, verifiable identity અથવા ધ્યાનપૂર્વક સીમિત inference દ્વારા સમર્થિત.

    અર્થ નથી કે: કે એજન્ટ અધિકૃત છે, સુરક્ષિત છે, અથવા વ્યક્તિ તરફથી માન્ય delegation સાથે કાર્ય કરી રહ્યો છે.

  • અજ્ઞાત

    ઉપલબ્ધ evidence વિશ્વસનીય નિર્ધારણને સમર્થન આપતું નથી.

    અર્થ નથી કે: કે interaction શંકાસ્પદ અથવા દુર્ભાવનાપૂર્ણ છે.

Verified, declared, inferred, unknown

દરેક result સાથે તેનું આધાર જોડાયેલું હોય છે. કોઈ class inferenceને ક્યારેય cryptographic verification તરીકે રજૂ કરતી નથી, જે security-sensitive applications માટે સૌથી વધુ મહત્વનું છે.

verified
સત્યાપિત. ક્રિપ્ટોગ્રાફિક અથવા અન્ય રીતે ચકાસી શકાય તેવું assertion માન્ય થયું હોય, જેમ કે published key સામે request signature. તે ફક્ત એ ચકાસણી સાબિત કરે છે, તેનાથી વધુ નહીં.
declared
ઘોષિત. એ actor અથવા તમારી applicationએ તે જણાવ્યું છે, ઉદાહરણ તરીકે AI-assistance disclosure અથવા પોતાને agent તરીકે ઓળખાવતો client. declaration ખોટું પણ હોઈ શકે છે.
inferred
અનુમાનિત. વર્તણૂકીય અથવા સંદર્ભાત્મક signals પરથી કાઢેલો નિષ્કર્ષ. Inferences ખોટી હોઈ શકે છે અને હંમેશા inference તરીકે જ લેબલ થાય છે.
unknown
અજ્ઞાત. નિર્ધારણ માટે પૂરતું evidence નથી. પરિણામ અંદાજ લગાવવાને બદલે Unknown તરીકે રિપોર્ટ થાય છે.

જ્યાં confidence આંકડાને પાછળ tested, calibrated modelની જરૂર હોય, ત્યાં અમે તેના બદલે ગુણાત્મક evidence strengthનો ઉપયોગ કરીએ છીએ. જો તે માપવામાં અને સમજાવવામાં આવ્યું ન હોય તો તમે અમારી તરફથી 99.7% human જેવા આંકડા નહીં જુઓ.

સમર્થિત contexts અને તેમની મર્યાદાઓ

  • બ્રાઉઝર

    બ્રાઉઝર કલેક્ટેર તે જ્યાં ચાલે છે તે પેજો પર interactive sessions જોઈ શકે છે. તે એવા clients જોઈ શકતું નથી જે JavaScript ચલાવતા નથી, અન્ય tabs, applications અથવા devices માંની activity, અથવા વ્યક્તિએ બીજી જગ્યાથી કોપી કરેલો ટેક્સ્ટ.

  • સર્વર અને API

    server-side integration request context જુએ છે અને, જ્યાં clients તેનો support કરે છે, ત્યાં request signatures પણ. તે વ્યક્તિની screen જોઈ શકતું નથી, અને મોટા ભાગના unsigned clients પોતાનું વર્ણન જેમ ઇચ્છે તેમ કરી શકે છે.

  • MCP

    MCP server ક્લાયંટની declared વિગતો અને તે કરેલા tool calls જોઈ શકે છે. declared client name એ declaration છે, verification નથી.

સમજવા યોગ્ય બે મર્યાદાઓ

બીજા tab અથવા device માંથી AI-generated text

જો કોઈ વ્યક્તિ બીજા tabમાં, અથવા પોતાના ફોન પર, chatbotને પૂછે અને જવાબને તમારા formમાં paste કરે, તો સામાન્ય web traffic સામાન્ય રીતે તેના વિશે કંઈ બતાવતું નથી. session માનવ-નિર્દેશિત લાગે છે કારણ કે તેને માનવે નિર્દેશિત કર્યું છે.

Proof of Actor Human + AI ત્યારે જ દર્શાવે છે જ્યારે assistance declared હોય, અથવા supported integration દ્વારા observed હોય જે તેને ખરેખર જોઈ શકે, જેમ કે તમારી appની પોતાની assistant feature.

signed bot request શું સાબિત કરે છે

published key સામે માન્ય થતી HTTP message signature બતાવે છે કે request એ એવા key વડે signed હતી જે તે identifier સાથે જોડાયેલી છે, જેમ કે operator's domain.

તે વિનંતી પાછળ કોણ છે તેની વાસ્તવિક વિશ્વની ઓળખ સ્થાપિત કરતું નથી, કોઈ વ્યક્તિએ તેને authority સોંપી છે કે નહીં, અથવા આ ક્રિયા સુરક્ષિત છે કે મંજૂર છે કે નહીં તે પણ બતાવતું નથી. આ ક્ષેત્રના standards, જેમાં IETF Web Bot Auth work પણ શામેલ છે, હજુ Internet-Drafts જ છે.

મૂળભૂત blocking નથી

Proof of Actor મૂળભૂત રીતે કંઈપણ block, reject અથવા challenge કરતું નથી. અમે માત્ર inferred actor resultના આધાર પર block અથવા reject કરવાની ભલામણ કરતા નથી, અને ખાસ કરીને તેના આધાર પર લોકો વિશે મહત્વપૂર્ણ નિર્ણયો (employment, credit, financial services, education અથવા essential services સુધીનો access) લેવાની ભલામણ કરતા નથી.

enforcement તમારા applicationમાં થાય છે, એવી policies હેઠળ જે તમારી team પસંદ કરે અને ખાતરી કરે, Unknown અને timeouts માટે explicit fallbacks સાથે.

Unknown અને abstention

જ્યારે પુરાવો વિશ્વસનીય નિર્ધારણને સમર્થન આપતો નથી, ત્યારે પરિણામ Unknown રહે છે. Unknown ને ક્યારેય Human માં બદલવામાં આવતું નથી, અને તેનો અર્થ શંકાસ્પદ એવો નથી. તેને દેખીતું રાખવાથી તમને ખબર પડે છે કે તમારી coverage ક્યાં પૂરતી થાય છે, અને કંઈપણ enforce કરતા પહેલાં આ માહિતી જરૂરી છે.

ગોપનીયતા અને governance સિદ્ધાંતો

  • ઉદ્દેશ મર્યાદા

    Evidence application ownerને interactionsનું વર્ણન કરે છે. તેનો ઉપયોગ cross-site profiles બનાવવા માટે થતો નથી.

  • ન્યૂનતમ સંગ્રહ

    દરેક integration તેના contextને જે જરૂરી હોય તે જ એકત્ર કરે છે. Sensitive telemetry માટે explicit opt-in જરૂરી છે.

  • tenant isolation

    એક customerનું evidence ક્યારેય બીજા customerને દેખાતું નથી.

  • રૂપરેખાંકનીય retention

    onboarding દરમિયાન દરેક founding team સાથે retention પર સંમતિ થાય છે.

  • ગ્રાહક-નિયંત્રિત ઍક્સેસ

    તમે નક્કી કરો છો કે તમારી ટીમમાં કોણ પુરાવા અને પરિણામો જોઈ શકે.

  • કોઈ identity checks નહીં

    biometric collection અને identity verification Proof of Actorનો ભાગ નથી.

દરેક team સાથે સહમત

retention periods, data fields અને processors onboarding દરમિયાન નક્કી થાય છે અને દરેક founding team માટે documented થાય છે.

પ્રદર્શન અને પદ્ધતિ

Coverage, unknown rate, false positives અને calibration ને દરેક supported context માં founding teams સાથે, અને જે outcomes those teams પહેલેથી જાણે છે તેના સામે માપવામાં આવે છે. દરેક context mature થાય તેમ methodology અને results અહીં પ્રકાશિત કરવામાં આવે છે.

Early Access માટે અરજી કરોતે કેવી રીતે કાર્ય કરે છે

privacy અથવા security વિશે પ્રશ્નો? [email protected]

સુરક્ષા અને જવાબદાર disclosure