முக்கிய உள்ளடக்கத்திற்கு தவிர்க்கவும்
இது எப்படி செயல்படுகிறது

Proof of Actor எப்படி செயல்படுகிறது.

உள்வரும் interaction இலிருந்து application decision வரை evidence-first பாதை.

policy · example-app.test
  • /api/v1/catalogenforceமுகவர்அனுமதி · structured API
  • /support/ticketsenforceமனிதர் + AIஅனுமதி · AI-assisted என label செய்யவும்
  • /account/*previewதெரியாததுஇருக்கும் checks-ஐ வைத்திருங்கள்
  • /api/v1/orderspreviewமுகவர்மேலும் வலுவான credential-ஐக் கோரவும்

interaction-இலிருந்து decision-க்கு

  1. 01Application request அல்லது eventஒரு பக்கக் காட்சி, ஒரு API call, ஒரு MCP tool call அல்லது ஒரு in-app செயல்.
  2. 02ஆதரிக்கப்படும் ஒருங்கிணைப்பிலிருந்து வரும் சிக்னல்கள்அந்த context-இல் அந்த integration காண முடிந்ததுமே.
  3. 03Evidence normalisation மற்றும் classificationசிக்னல்கள் சரிபார்க்கப்பட்டு, அடிப்படையின்படி குறிச்சொல்லிடப்பட்டு, ஒன்றிணைக்கப்படுகின்றன.
  4. 04basis மற்றும் uncertainty உடன் Actor முடிவுமனிதன், மனிதன் + AI, Agent அல்லது Unknown, மேலும் அது எதன் மீது அடிப்படையாக்கப்பட்டுள்ளது என்பதையும்.
  5. 05Dashboard மற்றும் analyticsஉங்கள் team review செய்ய trends, routes மற்றும் evidence.
  6. 06உங்கள் application-இன் சொந்த தீர்மானம்Observe only, அல்லது நீங்கள் தேர்ந்தெடுத்த 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
evidence எவ்வளவு வலுவானது: Verified, Declared, Inferred அல்லது Unknown.
evidence
முடிவுக்குப் பின்னுள்ள signals, அதனால் உங்கள் team ஏன் என்பதைப் பார்க்க முடியும்.

observation mode-இல் தொடங்கவும்: முடிவுகளை உங்கள் logs-க்கு அடுத்ததாக பதிவு செய்யவும், நீங்கள் ஒரு policy-ஐத் தேர்வு செய்யும் வரை எதையும் மாற்றாதீர்கள். Node.js integration guide-ஐப் படிக்கவும்

Observation mode தான் default

Proof of Actor-ஐ நிறுவுவது எந்த request-யையும் தடுக்கவோ மாற்றவோ செய்யாது. முடிவுகள் பதிவு செய்யப்படுகின்றன, அதனால் உங்கள் குழு அவற்றை உண்மையான பயன்பாட்டு முடிவுகளுடன் ஒப்பிட்டு, false positives-ஐ மதிப்பாய்வு செய்து, எந்த policy பொருத்தமானதா என்பதை தீர்மானிக்கலாம்.

ஆதாரத்தின் வகைகள்

கிடைக்கும் evidence, integration மற்றும் context ஐப் பொறுத்தது. ஒவ்வொரு workflow க்கான checks onboarding போது அணியுடன் ஒப்புக்கொள்ளப்படுகின்றன, மேலும் signal internals தனியாராகவே இருக்கும், அதனால் அவற்றை நகலெடுக்க கடினமாகும்.

  • கோரிக்கை கையொப்பங்கள்

    தங்களின் keys-ஐ வெளியிடும் தானியக்க clients-இருந்து வரும் cryptographic signatures.

  • பிரகடனங்கள்

    ஒரு கிளையன்ட் தன்னை Agent என்று பெயரிடுவது, அல்லது உங்கள் app-இல் உள்ள AI உதவி வெளிப்படுத்தல்.

  • இடைமுக சைகைகள்

    அனுமதிக்கப்பட்ட browser collector இலிருந்து, அது இயங்கும் பக்கங்களில் கிடைக்கும் சிக்னல்கள்.

  • கோரிக்கை சூழல்

    server-side integration-க்கு கிடைக்கும் headers மற்றும் protocol விவரங்கள்.

Agent identity என்பது authorization அல்ல

ஒரு தானியக்க கிளையன்டிலிருந்து வரும் signed request, அந்த request ஒரு வெளியிடப்பட்ட identifier-க்கு, உதாரணமாக operator-ன் domain-க்கு, தொடர்புடைய key-யுடன் கையொப்பமிடப்பட்டது என்பதை காட்ட முடியும். அது எந்த client அதை அனுப்பியது என்பதற்கான பயனுள்ள சான்றாகும்.

agent-ஐ யார் வழிநடத்தினார், ஒரு நபர் அதற்கு permission ஒப்படைத்தாரா, அதன் பின்னுள்ள சட்டபூர்வ அடையாளம் என்ன, அல்லது அந்த செயல் பாதுகாப்பானதா என்பதைக் இது காட்டாது. அவை தனித்த கேள்விகள்; அவற்றிற்கு உங்கள் application தனது சொந்த authentication, authorization மற்றும் policy மூலம் பதிலளிக்கிறது.

மூன்று தனித்த கேள்விகள்
  • யார் அழைக்கிறார்?Proof of Actor: signature, declaration அல்லது inference
  • எந்த credential?உங்கள் API key, OAuth token அல்லது session
  • அது என்ன செய்யக்கூடும்?உங்கள் authorization மற்றும் policy

routing decisions எவ்வாறு பொருந்துகின்றன

உங்கள் application Proof of Actor ஐ அழைத்து, ஒரு result ஐப் பெற்று, அதன் சொந்த rules ஐப் பயன்படுத்துகிறது. ஒவ்வொரு route மற்றும் risk tier க்கும், integration fails open ஆகுமா (request Proof of Actor இல்லாததைப் போலவே தொடரும்) அல்லது fails closed ஆகுமா (உங்கள் தற்போதைய வலுவான check செயல்படும்) என்பதை நீங்கள் தேர்வு செய்கிறீர்கள்.

  • API காலாவதி

    ஒரு result நேரத்தில் கிடைக்கவில்லை என்றால், உங்கள் integration அந்த route-க்கு நீங்கள் தேர்ந்தெடுத்த fallback-ஐ பயன்படுத்தும். timeout ஒருபோதும் மனிதன் முடிவாக மாறாது.

  • telemetry இல்லை

    browser collector இயங்கவில்லை அல்லது ஒரு signal இல்லை என்றால், result அதையே பிரதிபலிக்கும். காணாமல் போன evidence கூறக்கூடியவற்றை குறைக்கிறது; அது சந்தேகத்திற்குரியதாக கருதப்படாது.

  • அறியப்படாத வகைப்பாடுகள்

    Unknown என்பது ஒரு சாதாரண outcome. உங்கள் policy ஒவ்வொரு route-க்கும் Unknown என்றால் என்ன என்பதை வரையறுக்கிறது, உதாரணமாக: public pages-ஐ allow செய்யவும், account changes-க்கு existing checks-ஐ வைத்திருக்கவும்.

  • பழைய ஆதாரம்

    Evidence-க்கு ஒரு நேரமும் ஒரு scope-உம் உண்டு. session-இன் முன்பகுதியில் கிடைத்த result-ஐ, புதிய சரிபார்ப்பு இல்லாமல் பின்னர் வரும், அதிக முக்கியத்துவம் உள்ள action-க்கு மீண்டும் பயன்படுத்தக் கூடாது.

beta integration workflow

  1. 01விண்ணப்பிக்கவும்app பற்றியும், நீங்கள் புரிந்துகொள்ள விரும்பும் interaction பற்றியும் சொல்லுங்கள்.
  2. 02விரிவை நிர்ணயிக்கவும்integration, routes, usage limits மற்றும் data handling குறித்து ஒப்புக்கொள்ளுங்கள்.
  3. 03கவனிப்பு முறையில் இணைக்கவும்உங்கள் app எப்படி பதிலளிக்கிறது என்பதில் எந்த மாற்றமும் இல்லை.
  4. 04சரிபார்க்கவும்நீங்கள் அறிந்த ground truth-இன் அடிப்படையில் முடிவுகளை ஒப்பிடுங்கள்: coverage, unknown rate, false positives, latency.
  5. 05தீர்மானிக்கவும்சான்றுகள் அதனை ஆதரிக்கும் இடத்தில் மட்டுமே ஒரு policy-ஐ இயக்கவும்.

founding teams உடன் நாம் அளப்பவை

ஒவ்வொரு ஆதரிக்கப்பட்ட context-இலும் coverage, unknown rate, அறியப்பட்ட முடிவுகளுக்கு எதிரான false positives, மற்றும் கூடுதல் latency.

observation mode இல் தொடங்குங்கள்.

founding developer program இல் சேர விண்ணப்பிக்கவும்.

முதலில் பேச விரும்புகிறீர்களா? founders-உடன் பேசுங்கள்