പ്രധാന ഉള്ളടക്കത്തിലേക്ക് കടക്കുക
DETECTION & LIMITATIONS

Proof of Actor എന്ത് സ്ഥാപിക്കാനാകും, എന്ത് കഴിയില്ല എന്നത്.

വർഗീകരണങ്ങൾ, അവയുടെ പിന്നിലുള്ള തെളിവ്, അവ ബാധകമായ സാഹചര്യങ്ങൾ, കൂടാതെ ഞങ്ങൾ ചുറ്റും രൂപകൽപ്പന ചെയ്യുന്ന പരിധികൾ എന്നിവയുടെ ലളിതമായ വിവരണം.

സിഗ്നലുകൾ · ഓരോ ഉറവിടത്തിനും അവസാന അഭ്യർത്ഥന
  • അഭ്യർത്ഥന സിഗ്നേച്ചർvalid · sample-crawler.exampleverified
  • Client പ്രഖ്യാപനം"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 പുറത്താക്കുന്നുണ്ടോ എന്നത്നിങ്ങളുടെ നിരീക്ഷിക്കാനാകുന്ന ഇന്റഗ്രേഷനിന് പുറത്തായി ഒരു മനുഷ്യൻ AI ഉപയോഗിച്ചില്ല എന്നത്
supported workflow ൽ AI ഉപയോഗം declared ആയിരുന്നോ അല്ലെങ്കിൽ കാണാനായിരുന്നോ എന്നത്AI സഹായം, പകർത്തിയ ഉള്ളടക്കം, അല്ലെങ്കിൽ മറ്റൊരു device എന്നിവയുടെ സർവ്വജനീന കണ്ടെത്തൽ
ആ തെളിവ് അപര്യാപ്തമായിരുന്നുഅജ്ഞാതമായ ഒരു interaction ദുഷ്ടമാണെന്ന്

ലഭ്യത നിങ്ങളുടെ ഏകീകരണത്തിലും പ്രവർത്തനക്ഷമമാക്കിയ പരിശോധനകളിലും ആശ്രയിച്ചിരിക്കുന്നു. നടപ്പാക്കൽ തീരുമാനങ്ങളിലെ നിയന്ത്രണം അപ്ലിക്കേഷൻ ഉടമയ്ക്കാണ്.

വർഗീകരണങ്ങൾ

നാല് public class-കൾ. ഓരോന്നിനും നിർവ്വചിച്ച അർത്ഥവും വ്യക്തമായ പരിധിയും ഉണ്ട്.

  • മനുഷ്യൻ

    പിന്തുണയ്ക്കുന്ന നിരീക്ഷിക്കാവുന്ന സിഗ്നലുകൾ മനുഷ്യൻ നിയന്ത്രിക്കുന്ന ഇടപെടലാണ് സൂചിപ്പിക്കുന്നത്.

    ഇതിനർത്ഥമില്ല: AI ഉപയോഗിച്ചില്ല, അല്ലെങ്കിൽ ആ വ്യക്തിയുടെ യഥാർത്ഥ ലോക ഐഡന്റിറ്റി ശരിവെച്ചിരിക്കുന്നു എന്ന്.

  • മനുഷ്യൻ + AI

    AI സഹായം declared ആയിരുന്നു, അല്ലെങ്കിൽ അത് യഥാർത്ഥത്തിൽ observe ചെയ്യാനാകുന്ന ഒരു supported integration അത് detected ചെയ്തു.

    ഇതിനർത്ഥമില്ല: മറഞ്ഞിരിക്കുന്ന എല്ലാ AI ഉപയോഗവും, മറ്റൊരു tab അല്ലെങ്കിൽ മറ്റൊരു device ഉൾപ്പെടെ, കണ്ടെത്താൻ കഴിയുമെന്ന്.

  • ഏജന്റ്

    verifiable identity അല്ലെങ്കിൽ സൂക്ഷ്മമായി യോഗ്യതപ്പെടുത്തിയ ഒരു inference പിന്തുണയ്ക്കുന്ന automated അല്ലെങ്കിൽ agent-origin interaction.

    ഇതിനർത്ഥമില്ല: ഏജന്റ് അധികാരപ്പെടുത്തിയതാണെന്ന്, സുരക്ഷിതമാണെന്ന്, അല്ലെങ്കിൽ ഒരു വ്യക്തിയിൽ നിന്നുള്ള സാധുവായ delegation-ോടെ പ്രവർത്തിക്കുന്നുവെന്ന്.

  • അജ്ഞാതം

    ലഭ്യമായ തെളിവുകൾ വിശ്വസനീയമായ ഒരു നിർണ്ണയം പിന്തുണയ്ക്കുന്നില്ല.

    ഇതിനർത്ഥമില്ല: ആ interaction സംശയാസ്പദമാണോ ദുഷ്ടമാണോ എന്ന്.

Verified, declared, inferred, unknown

ഓരോ result-നും ഒരു basis ഉണ്ട്. ഒരു class ഒരിക്കലും inference-നെ cryptographic verification ആയി മറച്ചു വയ്ക്കുന്നില്ല, ഇത് security-sensitive applications-ക്ക് ഏറ്റവും പ്രധാനമാണ്.

verified
സ്ഥിരീകരിച്ചത്. ഒരു cryptographic അല്ലെങ്കിൽ മറ്റെങ്ങനെ പരിശോധിക്കാവുന്ന അവകാശവാദം സ്ഥിരീകരിച്ചിരിക്കുന്നത്, ഉദാഹരണത്തിന് പ്രസിദ്ധീകരിച്ച key-യ്‌ക്കെതിരായ ഒരു അഭ്യർത്ഥനാ signature. അത് ആ പരിശോധന മാത്രം തെളിയിക്കുന്നു, അതിൽ കൂടുതലൊന്നുമല്ല.
declared
പ്രഖ്യാപിച്ചത്. actor അല്ലെങ്കിൽ നിങ്ങളുടെ application അത് വ്യക്തമാക്കിയിരിക്കുന്നു, ഉദാഹരണത്തിന് AI-assistance disclosure അല്ലെങ്കിൽ സ്വയം ഒരു agent എന്ന് പേരിടുന്ന ഒരു client. ഒരു declaration തെറ്റായിരിക്കാം.
inferred
അനുമാനിച്ചത്. പെരുമാറ്റപരമായ അല്ലെങ്കിൽ സന്ദർഭാത്മക സിഗ്നലുകളിൽ നിന്ന് എടുത്ത ഒരു നിഗമനം. Inferred കണ്ടെത്തലുകൾ തെറ്റായിരിക്കാം, എന്നും inferred എന്ന നിലയിൽ ലേബൽ ചെയ്യും.
unknown
അജ്ഞാതം. തീരുമാനത്തിന് മതിയായ തെളിവില്ല. ഫലം ഊഹിക്കാതെ Unknown ആയി റിപ്പോർട്ട് ചെയ്യുന്നു.

ഒരു confidence figure ന് പിന്നിൽ പരീക്ഷിച്ചും calibrated ചെയ്തും model ആവശ്യമായിടത്ത്, അതിനു പകരം ഞങ്ങൾ qualitative evidence strength ഉപയോഗിക്കുന്നു. അത് അളക്കുകയും വിശദീകരിക്കുകയും ചെയ്തിട്ടില്ലെങ്കിൽ 99.7% human പോലുള്ള figure നിങ്ങളെ ഞങ്ങളിൽ നിന്ന് കാണാൻ കഴിയില്ല.

പിന്തുണയ്ക്കുന്ന contexts-ഉം അവയുടെ പരിധികളും

  • ബ്രൗസർ

    അത് പ്രവർത്തിക്കുന്ന പേജുകളിലെ ഇന്ററാക്ടീവ് സെഷനുകൾ ഒരു ബ്രൗസർ കളക്ടർ കാണുന്നു. JavaScript പ്രവർത്തിപ്പിക്കാത്ത clients-നെയും, മറ്റു ടാബുകളിലോ ആപ്ലിക്കേഷനുകളിലോ ഉപകരണങ്ങളിലോ ഉള്ള പ്രവർത്തനങ്ങളെയും, അല്ലെങ്കിൽ ആരെങ്കിലും മറ്റിടത്തു നിന്ന് പകർത്തി കൊണ്ടുവന്ന എഴുത്തിനെയും അത് കാണാൻ കഴിയില്ല.

  • സെർവർയും APIയും

    ഒരു server-side integration request context കാണുന്നു, കൂടാതെ clients അത് പിന്തുണയ്ക്കുന്നിടത്ത് request signatures-യും കാണുന്നു. അത് ഒരു person ന്റെ സ്ക്രീൻ കാണാൻ കഴിയില്ല, കൂടാതെ ഒപ്പില്ലാത്ത മിക്ക clients-നും തങ്ങൾക്ക് ഇഷ്ടമുള്ള വിധത്തിൽ സ്വയം വിവരണം നൽകാം.

  • MCP

    MCP server client-ന്റെ പ്രഖ്യാപിച്ച വിശദാംശങ്ങളും അത് നടത്തുന്ന tool calls ഉം കാണുന്നു. പ്രഖ്യാപിച്ച client name ഒരു declaration ആണ്, verification അല്ല.

മനസ്സിലാക്കേണ്ട രണ്ട് പരിധികൾ

മറ്റൊരു tab അല്ലെങ്കിൽ device ൽ നിന്നുള്ള AI-generated text

ഒരു വ്യക്തി മറ്റൊരു tab-ൽ അല്ലെങ്കിൽ അവരുടെ phone-ൽ ഒരു chatbot-നോട് ചോദിച്ച് മറുപടി നിങ്ങളുടെ form-ൽ paste ചെയ്താൽ, സാധാരണ web traffic സാധാരണയായി അതിനെക്കുറിച്ച് ഒന്നും കാണിക്കില്ല. session human-directed ആയി തോന്നും, കാരണം അത് ഒരു human ആണ് നിയന്ത്രിച്ചത്.

സഹായം declared ചെയ്തപ്പോഴോ, അല്ലെങ്കിൽ അതിനെ യഥാർത്ഥത്തിൽ കാണാൻ കഴിയുന്ന ഒരു supported integration വഴി നിരീക്ഷിക്കപ്പെട്ടപ്പോഴോ മാത്രം Proof of Actor Human + AI റിപ്പോർട്ട് ചെയ്യുന്നു, ഉദാഹരണത്തിന് നിങ്ങളുടെ app-ന്റെ സ്വന്തം assistant feature.

ഒപ്പിട്ട bot request എന്താണ് തെളിയിക്കുന്നത്

പ്രസിദ്ധീകരിച്ച key-നെതിരെ സാധൂകരിക്കുന്ന ഒരു HTTP message signature, operator-ന്റെ domain പോലുള്ള ആ identifier-നോട് ബന്ധപ്പെട്ട key ഉപയോഗിച്ചാണ് അഭ്യർത്ഥന ഒപ്പുവച്ചതെന്ന് കാണിക്കുന്നു.

അഭ്യർത്ഥനയ്ക്ക് പിന്നിലുള്ള വ്യക്തിയുടെ യഥാർത്ഥ ലോക ഐഡന്റിറ്റി, ഒരു വ്യക്തി അതിന് അധികാരം ഏൽപ്പിച്ചിട്ടുണ്ടോ, അല്ലെങ്കിൽ പ്രവർത്തി സുരക്ഷിതമാണോ അനുമതിയുള്ളതാണോ എന്നത് ഇത് സ്ഥാപിക്കുന്നില്ല. ഈ മേഖലയിലെ standards, IETF Web Bot Auth work ഉൾപ്പെടെ, ഇപ്പോഴും Internet-Drafts ആണ്.

Default blocking ഇല്ല

Proof of Actor default ആയി ഒന്നും block ചെയ്യുകയോ reject ചെയ്യുകയോ challenge ചെയ്യുകയോ ചെയ്യുന്നില്ല. inferred actor ഫലത്തെ മാത്രം അടിസ്ഥാനമാക്കി block ചെയ്യുകയോ reject ചെയ്യുകയോ ചെയ്യുന്നതിനെ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നില്ല, പ്രത്യേകിച്ച് തൊഴിൽ, credit, financial services, education, അല്ലെങ്കിൽ essential services-ലേക്കുള്ള പ്രവേശനം പോലുള്ള ആളുകളെ ബാധിക്കുന്ന നിർണ്ണായക തീരുമാനങ്ങൾ അതിന്റെ അടിസ്ഥാനത്തിൽ എടുക്കുന്നതിനെ.

Enforcement നിങ്ങളുടെ application-ൽ നടക്കുന്നു, നിങ്ങളുടെ ടീം തിരഞ്ഞെടുക്കുകയും സ്ഥിരീകരിക്കുകയും ചെയ്യുന്ന policies-ന്റെ കീഴിൽ, Unknown-ത്തിനും timeouts-ത്തിനും explicit fallbacks സഹിതം.

Unknown ഉം abstention ഉം

evidence വിശ്വസനീയമായ ഒരു നിർണ്ണയത്തെ പിന്തുണയ്ക്കുന്നില്ലെങ്കിൽ, ഫലം Unknown ആണ്. Unknown ഒരിക്കലും Human ആയി മാറ്റുകയില്ല, അതിനർത്ഥം സംശയാസ്പദം എന്നതുമല്ല. അത് ദൃശ്യമാക്കി വയ്ക്കുന്നത് നിങ്ങളുടെ coverage എവിടെയാണ് അവസാനിക്കുന്നത് എന്ന് കാണിക്കുന്നു, എന്തെങ്കിലും enforce ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങൾക്ക് ആവശ്യമുള്ള വിവരമാണത്.

സ്വകാര്യതയും ഭരണനടപടികളും സംബന്ധിച്ച സിദ്ധാന്തങ്ങൾ

  • ഉദ്ദേശ്യ പരിധി

    Evidence application owner-ന് interactions വിശദീകരിക്കുന്നു. അത് cross-site profiles നിർമ്മിക്കാൻ ഉപയോഗിക്കുന്നില്ല.

  • കുറഞ്ഞ ശേഖരണം

    ഓരോ integration-വും അതിന്റെ context-ന് ആവശ്യമായതു മാത്രം ശേഖരിക്കുന്നു. Sensitive telemetry-യ്ക്ക് explicit opt-in ആവശ്യമാണ്.

  • ടെനന്റ് വേർതിരിവ്

    ഒരു customer-ന്റെ evidence മറ്റൊരു customer-ക്ക് ഒരിക്കലും ദൃശ്യമല്ല.

  • ക്രമീകരിക്കാവുന്ന retention

    ഓരോ founding team-നോടും onboarding സമയത്ത് retention സംബന്ധിച്ച് ധാരണയാകുന്നു.

  • ഉപഭോക്താവ് നിയന്ത്രിക്കുന്ന പ്രവേശനം

    നിങ്ങളുടെ ടീമിലെ ആര്‍ക്ക് തെളിവുകളും ഫലങ്ങളും കാണാമെന്ന് നിങ്ങൾ തീരുമാനിക്കുന്നു.

  • identity checks ഇല്ല

    biometric collection ഇല്ല, identity verification ഇല്ല - ഇവ Proof of Actor-ന്റെ ഭാഗമല്ല.

ഓരോ ടീമുമായും അംഗീകരിച്ചു

Retention കാലാവധികൾ, data fields, processors എന്നിവ onboarding സമയത്ത് ധാരണയാകുകയും ഓരോ founding team-നും രേഖപ്പെടുത്തുകയും ചെയ്യുന്നു.

പ്രകടനവും രീതിശാസ്ത്രവും

coverage, unknown rate, false positives, calibration എന്നിവ ഓരോ supported context ലും founding teams നോടൊപ്പം, അവർക്ക് ഇതിനകം അറിയുന്ന outcomes നെ അടിസ്ഥാനമാക്കി അളക്കുന്നു. ഓരോ context ഉം പക്വമാകുമ്പോൾ methodology ഉം results ഉം ഇവിടെ പ്രസിദ്ധീകരിക്കും.

Early Access-ിന് അപേക്ഷിക്കുകഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു

privacy അല്ലെങ്കിൽ security സംബന്ധിച്ച് ചോദ്യങ്ങളുണ്ടോ? [email protected]

സുരക്ഷയും ഉത്തരവാദിത്വമുള്ള വെളിപ്പെടുത്തലും