പ്രധാന ഉള്ളടക്കത്തിലേക്ക് കടക്കുക
എങ്ങനെ പ്രവർത്തിക്കുന്നു

Proof of Actor എങ്ങനെ പ്രവർത്തിക്കുന്നു.

വരുന്ന interaction മുതൽ application തീരുമാനം വരെ evidence-first പാത.

Early Access-ിന് അപേക്ഷിക്കുകDetection & Limits കാണുക
policy · example-app.test
  • /api/v1/catalogenforceഏജന്റ്അനുവദിക്കുക · structured API
  • /support/ticketsenforceമനുഷ്യൻ + AIഅനുവദിക്കുക · AI-assisted ആയി ലേബൽ ചെയ്യുക
  • /account/*previewഅജ്ഞാതംനിലവിലുള്ള checks നിലനിർത്തുക
  • /api/v1/orderspreviewഏജന്റ്കൂടുതൽ ശക്തമായ credential ആവശ്യപ്പെടുക

interaction മുതൽ decision വരെ

  1. 01Application അഭ്യർത്ഥന അല്ലെങ്കിൽ സംഭവംഒരു page view, ഒരു API call, ഒരു MCP tool call അല്ലെങ്കിൽ ഒരു in-app action.
  2. 02പിന്തുണയുള്ള ഇന്റഗ്രേഷനിൽ നിന്നുള്ള സിഗ്നലുകൾആ context-ൽ ആ integration-ന് observe ചെയ്യാൻ കഴിയുന്നതു മാത്രം.
  3. 03തെളിവുകളുടെ നോർമലൈസേഷനും വർഗ്ഗീകരണവുംസിഗ്നലുകൾ പരിശോധിച്ച്, അടിസ്ഥാനപ്രകാരം ലേബൽ ചെയ്ത്, സംയോജിപ്പിക്കുന്നു.
  4. 04അടിസ്ഥാനവും അനിശ്ചിതത്വവും ഉള്ള ആക്ടർ ഫലംHuman, Human + AI, Agent അല്ലെങ്കിൽ Unknown, കൂടാതെ അത് ആധാരമാക്കുന്നതെന്തെന്ന്.
  5. 05Dashboard, analyticsനിങ്ങളുടെ ടീം review ചെയ്യുന്നതിനുള്ള trends, routes, തെളിവുകൾ.
  6. 06നിങ്ങളുടെ application's സ്വന്തം തീരുമാനംമാത്രം നിരീക്ഷിക്കുക, അല്ലെങ്കിൽ നിങ്ങൾ തിരഞ്ഞെടുത്ത policy പ്രയോഗിക്കുക.
ഡെവലപ്പർമാർക്കായി

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-ൽ ആരംഭിക്കുക: നിങ്ങളുടെ logs-ിന് ഒപ്പം results രേഖപ്പെടുത്തുക, നിങ്ങൾ ഒരു policy തിരഞ്ഞെടുക്കും വരെ ഒന്നും മാറ്റരുത്. Node.js integration guide വായിക്കുക

Observation mode ആണ് default

Proof of Actor ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ഏതെങ്കിലും request-നെ തടയുകയോ മാറ്റുകയോ ചെയ്യുന്നില്ല. ഫലങ്ങൾ രേഖപ്പെടുത്തപ്പെടുന്നു, അതുവഴി നിങ്ങളുടെ ടീം അവയെ യഥാർത്ഥ application ഫലങ്ങളുമായി താരതമ്യം ചെയ്യാനും, false positive-കൾ പരിശോധിക്കാനും, ഏതെങ്കിലും policy അനുയോജ്യമാണോ എന്ന് തീരുമാനിക്കാനും കഴിയും.

തെളിവുകളുടെ തരം

ലഭ്യമായ തെളിവ് integration-നും context-നും ആശ്രയിച്ചിരിക്കുന്നു. ഓരോ workflow-ത്തിനുമുള്ള checks onboarding സമയത്ത് ടീമുമായി ധാരണയിൽ എത്തുന്നു, signal internals private ആയി തുടരുന്നു, അതിനാൽ അവ അനുകരിക്കാൻ കൂടുതൽ ബുദ്ധിമുട്ടാണ്.

  • അഭ്യർത്ഥന സിഗ്നേച്ചറുകൾ

    തങ്ങളുടെ keys പ്രസിദ്ധീകരിക്കുന്ന automated clients ല്‍ നിന്നുള്ള cryptographic signatures.

  • പ്രഖ്യാപനങ്ങൾ

    സ്വയം agent എന്ന് പേര് നൽകുന്ന ഒരു client, അല്ലെങ്കിൽ നിങ്ങളുടെ app-ലുള്ള AI-assistance വെളിപ്പെടുത്തൽ.

  • ഇടപെടൽ സിഗ്നലുകൾ

    അംഗീകരിച്ച browser collector-ിൽ നിന്നുള്ള സിഗ്നലുകൾ, അത് പ്രവർത്തിക്കുന്ന പേജുകളിൽ.

  • അഭ്യർത്ഥനയുടെ പശ്ചാത്തലം

    Server-side integration-ിന് ലഭ്യമായ headers ഉം protocol details ഉം.

Agent identity authorization അല്ല

ഒരു automated client നിന്നുള്ള signed request, request ഒരു published identifier-നോട് ബന്ധപ്പെട്ട key ഉപയോഗിച്ച് signed ചെയ്തതാണെന്ന് കാണിക്കാം, ഉദാഹരണത്തിന് operator ന്റെ domain. അത് ഏത് client ആണ് അത് അയച്ചത് എന്നതിനെക്കുറിച്ചുള്ള ഉപകാരപ്രദമായ തെളിവാണ്.

ഏത് വ്യക്തിയാണ് agent-നെ നിർദേശിച്ചത്, ഒരു വ്യക്തി അതിന് permission ഏൽപ്പിച്ചിട്ടുണ്ടോ, അതിനു പിന്നിലെ നിയമപരമായ ഐഡന്റിറ്റി എന്താണ്, അല്ലെങ്കിൽ പ്രവർത്തി സുരക്ഷിതമാണോ എന്നത് ഇത് കാണിക്കുന്നില്ല. അവ നിങ്ങളുടെ application സ്വന്തം authentication, authorization, policy എന്നിവ ഉപയോഗിച്ച് മറുപടി നൽകുന്ന വേറിട്ട ചോദ്യങ്ങളാണ്.

വേറെ വേറെ മൂന്ന് ചോദ്യങ്ങൾ
  • ആരാണ് വിളിക്കുന്നത്?Proof of Actor: signature, declaration അല്ലെങ്കിൽ inference
  • ഏത് credential?നിങ്ങളുടെ API key, OAuth token അല്ലെങ്കിൽ session
  • അത് എന്ത് ചെയ്യാൻ സാധ്യതയുണ്ട്?നിങ്ങളുടെ authorization and policy

routing തീരുമാനങ്ങൾ എങ്ങനെ ചേരുന്നു

നിങ്ങളുടെ application Proof of Actor നെ വിളിക്കുന്നു, ഒരു result സ്വീകരിക്കുന്നു, അതിന്റെ സ്വന്തം rules പ്രയോഗിക്കുന്നു. ഓരോ route നും risk tier നും അനുസരിച്ച് integration fails open (request Proof of Actor ഇല്ലാത്ത പോലെ തന്നെ തുടരുന്നു) ആകണമോ fails closed (നിങ്ങളുടെ നിലവിലുള്ള കൂടുതൽ ശക്തമായ check പ്രയോഗിക്കുന്നു) ആകണമോ നിങ്ങൾ തിരഞ്ഞെടുക്കുന്നു.

  • API ടൈംഔട്ട്

    ഒരു ഫലം സമയത്ത് ലഭ്യമല്ലെങ്കിൽ, ആ route-ിനായി നിങ്ങൾ തിരഞ്ഞെടുത്ത fallback നിങ്ങളുടെ integration ഉപയോഗിക്കും. ഒരു timeout ഒരിക്കലും Human ഫലമാകില്ല.

  • telemetry ഇല്ല

    Browser collector പ്രവർത്തിച്ചില്ലെങ്കിൽ അല്ലെങ്കിൽ ഒരു signal ഇല്ലെങ്കിൽ, ഫലം അത് പ്രതിഫലിപ്പിക്കും. കാണാതായ തെളിവ് പറയാനാകുന്നതിനെ കുറയ്ക്കുന്നു; അത് സംശയകരമായി പരിഗണിക്കുന്നില്ല.

  • അജ്ഞാത വർഗ്ഗീകരണങ്ങൾ

    Unknown ഒരു സാധാരണ ഫലമാണ്. ഓരോ route-നുമായി Unknown എന്താണെന്ന് നിങ്ങളുടെ policy നിർവചിക്കുന്നു, ഉദാഹരണത്തിന്: public pages അനുവദിക്കുക, account changes-ൽ നിലവിലുള്ള checks തുടരുക.

  • പഴയ തെളിവ്

    Evidence-യ്ക്ക് ഒരു time ഉം scope ഉം ഉണ്ട്. ഒരു session-ന്റെ തുടക്കത്തിൽ ലഭിച്ച result, പുതിയ ഒരു check ഇല്ലാതെ പിന്നീട് കൂടുതൽ sensitive ആയ ഒരു action-ിന് വീണ്ടും ഉപയോഗിക്കരുത്.

ബീറ്റ integration workflow

  1. 01അപേക്ഷിക്കുകആപ്പിനെയും നിങ്ങൾ മനസ്സിലാക്കാൻ ആഗ്രഹിക്കുന്ന interaction-നെയും കുറിച്ച് പറയൂ.
  2. 02പരിധിintegration, routes, usage limits, data handling എന്നിവയിൽ ധാരണയാക്കുക.
  3. 03പര്യവേക്ഷണ മോഡിൽ ഇന്റഗ്രേറ്റ് ചെയ്യുകനിങ്ങളുടെ app പ്രതികരിക്കുന്ന രീതിയിൽ മാറ്റമില്ല.
  4. 04സാധൂകരിക്കുകനിങ്ങൾക്ക് അറിയാവുന്ന ground truth നോടു ഫലങ്ങൾ താരതമ്യം ചെയ്യുക: coverage, unknown rate, false positives, latency.
  5. 05തീരുമാനിക്കുകevidence അത് പിന്തുണയ്ക്കുന്നിടത്ത് മാത്രം ഒരു policy enable ചെയ്യുക.

founding teams നോടൊപ്പം ഞങ്ങൾ അളക്കുന്നത് എന്താണ്

പിന്തുണയ്ക്കുന്ന ഓരോ context ലും coverage, unknown rate, അറിയപ്പെടുന്ന ഫലങ്ങളോടുള്ള false positives, കൂടിയ latency എന്നിവ.

Observation mode-ൽ തുടങ്ങുക.

founding developer program ല് ചേരാൻ അപേക്ഷിക്കുക.

Early Access-ിന് അപേക്ഷിക്കുകDetection & Limits കാണുക

ആദ്യം സംസാരിക്കണമോ? സ്ഥാപകരുമായി സംസാരിക്കുക