AI முகவர் அடையாளம்

APIகளுக்கான AI முகவர் அடையாளம்

உங்கள் API ஏற்கனவே எந்த key ஒரு request செய்தது என்பதை அறியும். Proof of Actor அதற்குப் பின்னால் இருந்த actor எந்த வகை என்பதையும், அதற்கான ஆதாரம் என்ன என்பதையும் சொல்கிறது, மேலும் அடுத்து என்ன நடக்க வேண்டும் என்பதை உங்கள் code தீர்மானிக்க அனுமதிக்கிறது.

முன்கூட்டிய அணுகலைப் பெறுக எப்படி செயல்படுகிறது என்பதை ஆராய்க

ஆசிரியர் Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

குறுகிய பதில்

ஒரு API key உங்களுக்கு எந்த account அழைக்கிறது என்பதை சொல்கிறது, ஆனால் request-க்கு பின்னால் எந்த வகை client இருக்கிறது என்பதை சொல்வதில்லை. Proof of Actor, request signatures மற்றும் client declarations இருக்கும் இடங்களில் அவற்றைப் பயன்படுத்தி, ஒவ்வொரு API request-க்கும் actor context-ஐ சேர்க்கிறது, அதனால் நீங்கள் actor class மற்றும் route அடிப்படையில் limits மற்றும் policies-ஐ அமைக்கலாம்.

உங்கள் API key-ஐ அறியும். actor-ஐ அறியாது.

ஒவ்வொரு API request-மும் அதற்குப் பணம் செலுத்துவது யார் என்பதற்கான சில ஆதாரங்களுடன் வருகிறது: ஒரு API key, ஒரு OAuth token, ஒரு session. அந்த ஆதாரம் ஒரு கேள்விக்கு நன்றாக பதில் அளிக்கிறது. அந்த call-க்கு எந்த account பொறுப்பானது என்பதை அது சொல்கிறது. ஆனால் இப்போது உண்மையில் அந்த call-ஐ என்ன செய்கிறது என்பதை அது சொல்வதில்லை.

ஒரே API key-ஐ terminal-இல் சோதனை செய்யும் developer, அட்டவணைப்படி இயங்கும் backend job, ஒரு AI assistant மூலம் செயல்படும் நபர், மற்றும் ஒரு task-ஐ முடிக்க key-ஐ பெற்ற autonomous agent ஆகியோர் பயன்படுத்த முடியும். அவை எல்லாம் மிகவும் வேறுபட்ட actors. அவர்களுக்கு வேறுபட்ட வேகங்கள், வேறுபட்ட failure modes, மற்றும் வேறுபட்ட risk profiles உள்ளன. அவை அனைத்தையும் ஒரே விதமாக நடத்துவதால், உங்கள் customer-கள் நம்பும் legitimate automation-ஐ நீங்கள் மிகையாக கட்டுப்படுத்தலாம், அல்லது unattended agent-இனால் இயக்கப்படக்கூடாத உங்கள் API பகுதிகளை நீங்கள் போதுமான அளவு பாதுகாக்காமல் விடலாம்.

APIகளுக்கான AI முகவர் அடையாளம் அந்த இடைவெளியை மூடுகிறது. key-இலிருந்து எல்லாவற்றையும் ஊகிப்பதற்குப் பதிலாக, ஒவ்வொரு request-க்கும் பின்னால் இருக்கும் actor-இன் வகைப்பாட்டை, அதை ஆதரிக்கும் ஆதாரத்துடன் சேர்த்து பெறுகிறீர்கள். இதையே Proof of Actor வழங்க உருவாக்கப்பட்டுள்ளது, மேலும் APIs use case API teams அதை route by route எப்படி பயன்படுத்துகின்றன என்பதை காட்டுகிறது.

இப்போது API teams-க்கு actor context ஏன் தேவை

APIகளுக்கான automated traffic புதியது அல்ல. scripts, integrations, மற்றும் crawlers எப்போதும் இதன் ஒரு பகுதியாக இருந்துள்ளன. மாறியது automation-இன் வகை. AI agents documentation-ஐப் படிக்கவும், calls-ஐ ஒன்றுடன் ஒன்று இணைக்கவும், படைப்பாற்றலுடன் retry செய்யவும், மேலும் ஒவ்வொரு படியையும் கவனித்துக் கொண்டிராத மக்களின் சார்பாக செயல்படவும் முடியும். அவற்றில் பல பயனுள்ளவை, வரவேற்கத்தக்கவை. சில மோசமாக கட்டப்பட்டுள்ளன. சில hostiles.

actor context இல்லாமல், API teams பெரும்பாலும் கடுமையான கருவிகளுக்கு திரும்புகின்றன:

ஒரு key-க்கு rate limits, இது நல்ல agents-களையும் மோசமான agents-களையும் ஒரே அளவில் மந்தமாக்குகிறது.
User-agent விதிகள், இது client ஒரு header-ஐ மாற்றும் தருணத்திலேயே உடைந்து விடுகிறது.
முழுமையான blocks, இது legitimate automation-ஐ உங்கள் web app-இலிருந்து scrape செய்யத் தூண்டுகிறது.

actor context உங்களுக்கு துல்லியமாக பதிலளிக்க உதவுகிறது. நீங்கள் அடையாளம் காணும் operator-இலிருந்து வரும் signed agent-க்கு read routes-இல் அதிக limit கொடுக்கலாம். write route-ஐ தாக்கும் unknown caller-ஐ stronger credential கேட்டுக் கொள்ளலாம். AI assistant பயன்படுத்தும் மனிதர் இயல்பான அனுபவத்தைத் தொடரலாம். நோக்கம் agents-ஐ நிறுத்துவது அல்ல. ஒவ்வொரு வகை caller-க்கும் சரியான பாதையை வழங்குவதுதான். ஒரு signed request என்ன சொல்ல முடியும், என்ன சொல்ல முடியாது என்பதற்காக what signed AI agent requests prove-ஐப் படியுங்கள்.

Proof of Actor-இல் AI முகவர் அடையாளம் எப்படி செயல்படுகிறது

ஒவ்வொரு request-க்கும் Proof of Actor அதே evidence-first flow-ஐப் பின்பற்றுகிறது. முழு walkthrough-ஐ How It Works-இல் படிக்கலாம்; இங்கே API teams-க்கு சுருக்கமான பதிப்பு.

1. உங்கள் integration-இலிருந்து signals

உங்கள் integration, அந்த context-இல் கிடைக்கும் signals-ஐ Proof of Actor-க்கு அனுப்புகிறது. ஒரு API-க்கு, அதில் பொதுவாக headers மற்றும் protocol விவரங்கள் போன்ற request context, client வழங்கும் எந்த cryptographic request signatures, மற்றும் client தன்னைப் பற்றிக் கூறும் எந்த declarations ஆகியவை அடங்கும். ஒவ்வொரு signal-க்கும் அது எங்கிருந்து வந்தது என்பதைக் குறிப்பு இடப்படுகிறது.

2. ஒரு basis உடனான classification

அந்த signals சோதிக்கப்பட்டு, நான்கு public classes-இல் ஒன்றாக ஒன்றிணைக்கப்படுகின்றன:

Human: காணக்கூடிய signals மனிதர் இயக்கிய interaction-ஐ சுட்டிக்காட்டுகின்றன.
Human + AI: AI உதவி அறிவிக்கப்பட்டுள்ளது அல்லது அதைப் பார்க்க முடியும் ஒரு integration மூலம் கண்டறியப்பட்டுள்ளது.
Agent: தானியங்கி அல்லது agent-origin traffic, சரிபார்க்கக்கூடிய identity அல்லது கவனமாக வரையறுக்கப்பட்ட inference மூலம் ஆதரிக்கப்படுகிறது.
Unknown: ஆதாரம் நம்பகமான முடிவை ஆதரிக்கவில்லை.

ஒவ்வொரு முடிவும் அதன் basis-ஐயும் கொண்டுள்ளது: Verified, Declared, Inferred, அல்லது Unknown. API teams அதிகம் மதிப்பிடும் பகுதி இதுதான். வெளியிடப்பட்ட key-க்கு எதிராக செல்லுபடியாகும் உங்கள் HTTP message signature, RFC 9421-இல் வரையறுக்கப்பட்டபடி, verified என அறிக்கையிடப்படுகிறது. ஒரு client தன்னை agent என்று மட்டும் கூறினால், அது declared என அறிக்கையிடப்படுகிறது. தானியக்கமாகத் தோன்றும் ஒரு pattern inferred என அறிக்கையிடப்படுகிறது. ஒரு முடிவு cryptography-ஆல் தானா அல்லது heuristic-ஆல் தானா அமைந்துள்ளது என்று நீங்கள் ஒருபோதும் குழப்பமடைய வேண்டியதில்லை. evidence basis பதிலின் ஒரு பகுதியாகும்.

3. உங்கள் code செயல்படுத்தக்கூடிய ஒரு result

அந்த result class, basis, மற்றும் படிக்கக்கூடிய evidence summary உடன் உங்கள் application-க்கு திரும்ப வருகிறது. அதைப் பார்த்து என்ன செய்ய வேண்டும் என்பதை உங்கள் code முடிவு செய்கிறது. observation mode-இல், நீங்கள் அதை simply பதிவு செய்கிறீர்கள். நீங்கள் தயாரான பிறகு, அதைப் பொருத்து route செய்கிறீர்கள்.

உங்கள் team பெறுவது: Detect, Understand, Route

Proof of Actor என்பது மூன்று திறன்களைக் கொண்ட ஒரே product.

Detect

உங்கள் API காணக்கூடிய actor signals-ஐ சேகரித்து, verified assertions-ஐ behavioural inferences-இலிருந்து பிரிக்கவும். Signed agent requests, declared clients, automation signals, மற்றும் Unknown results அனைத்தும் தனித்தனியாக வைக்கப்படுகின்றன, அதனால் எதுவும் அமைதியாக ஒரே score-ஆக கலக்கப்படுவதில்லை.

Understand

எந்த actors எந்த routes-ஐ அழைக்கின்றன, அது காலப்போக்கில் எப்படி மாறுகிறது, மற்றும் ஒவ்வொரு classification-இன் பின்னால் எந்த ஆதாரம் இருக்கிறது என்பதைப் பாருங்கள். unknown rate தெரிந்தபடியே இருக்கும், இது உங்கள் coverage எங்கு முடிகிறது, மேலும் வலுவான signal எங்கு உதவும் என்பதைக் துல்லியமாகச் சொல்கிறது.

Route

ஒவ்வொரு route-க்கும் ஒவ்வொரு risk tier-க்கும் policies எழுதுங்கள்: allow, adapt, challenge, review, அல்லது rate-limit. read-only endpoints-இல் verified agents-க்கு structured, generous path-ஐ வைத்திருங்கள். high-impact operations-இல் stronger credentials கேளுங்கள். Unknown மற்றும் timeouts-க்கான ஒரு தெளிவான fallback-ஐ வரையறையுங்கள், அதனால் எதுவாக நடந்தாலும் உங்கள் API கணிக்கக்கூடிய முறையில் நடக்கும். அந்த route-இல் ஒரு தவறின் செலவைக் கருத்தில் கொண்டு, ஒவ்வொரு policy எப்படி fail ஆக வேண்டும், open ஆகவா அல்லது closed ஆகவா என்பதை நீங்கள் தீர்மானிக்கிறீர்கள்.

அடையாள ஆதாரம், credentials மற்றும் authorization மூன்றும் வேறுபட்டவை

agent-aware API வடிவமைப்பில் மிக பொதுவான தவறு, மூன்று தனித்த கேள்விகளை ஒன்றாக இணைப்பதே. Proof of Actor அவற்றைத் தனித்தனியாக வைத்திருக்கிறது, உங்கள் design-மும் அப்படியே இருக்க வேண்டும்.

Identity evidence: எந்த வகை actor அழைக்கிறது, அதைப் புரியவைக்கும் ஆதாரம் என்ன? இதைத்தான் AI முகவர் அடையாளம் வழங்குகிறது. ஒரு verified signature, ஒரு request-ஐ ஒரு key-க்கும் அதன் வெளியிடப்பட்ட operator identifier-க்கும் இணைக்கிறது. IETF Web Bot Auth working group automated clients-க்கான இந்த வகை cryptographic authentication-ஐ standardize செய்ய charter செய்யப்பட்டுள்ளது, மேலும் அதன் scope end user-ஐ விட agent-ஐ authenticate செய்வதைக் கொண்டுள்ளது.
Credentials: இந்த call-க்கு எந்த account பொறுப்பானது? இது நீங்கள் வெளியிட்டு நிர்வகிக்கும் உங்கள் API key, token, அல்லது session.
Authorization: இந்த caller இந்த குறிப்பிட்ட செயலைச் செய்ய அனுமதிக்கப்படுகிறதா? இது உங்கள் permission model.

ஒரு verified agent தானாகவே authorized agent அல்ல. செல்லுபடியாகும் signature, ஒரு நபர் agent-க்கு authority-ஐ delegation செய்தார் என்பதை நிரூபிப்பதில்லை, மேலும் கேட்ட செயல் பாதுகாப்பானது என்பதையும் அது உறுதிப்படுத்துவதில்லை. Proof of Actor முதல் கேள்விக்கான நம்பகமான context-ஐ உங்களுக்கு வழங்குகிறது, மேலும் இரண்டாவது மற்றும் மூன்றாவது கேள்விகளை அவை இருக்க வேண்டிய இடத்திலேயே விடுகிறது: உங்கள் application-இல். agent authorization-இல் மேலும் படியுங்கள், மேலும் Detection & Limitations-இல் ஆதாரம் என்ன நிறுவ முடியும், என்ன நிறுவ முடியாது என்பதையும் படியுங்கள்.

Unknown என்பது ஒரு feature, failure அல்ல

Request signing விருப்பத்திற்குரியது, மேலும் ஒரு unsigned client தன்னை விரும்பியபடி விவரிக்கலாம். ஒவ்வொரு request-ஐயும் Human அல்லது Agent ஆக கட்டாயப்படுத்தும் ஒரு system சில சமயங்களில் நம்பிக்கையுடன் தவறாக இருக்கும், மேலும் எப்போது என்பதை நீங்கள் அறியமாட்டீர்கள்.

ஆதாரம் ஒரு determination-ஐ ஆதரிக்காதபோது Proof of Actor Unknown-ஐ அறிக்கையிடுகிறது. Unknown ஒருபோதும் Human ஆக மாற்றப்படுவதில்லை, மேலும் default-ஆக malicious எனவும் கருதப்படுவதில்லை. ஒவ்வொரு route-க்கும் Unknown என்ன பொருள் என்பதைக் கொள்கை வரையறுக்கிறது: public reads-இல் அதை அனுமதிக்கவும், account changes-இல் உங்கள் ஏற்கனவே உள்ள checks-ஐ வைத்திருங்கள், stakes அதிகமாக உள்ள இடங்களில் review-க்காக queue செய்யவும். Unknown-ஐ தெளிவாக வைத்திருப்பதுதான் உங்கள் மற்ற classifications நம்பத்தகுந்தவையாக இருப்பதை உருவாக்குகிறது. handling unknown traffic பற்றிய guide அதற்காக வடிவமைப்பது எப்படி என்பதை காட்டுகிறது.

உங்கள் stack-இல் AI முகவர் அடையாளம் எங்கு பொருந்துகிறது

Proof of Actor உங்கள் ஏற்கனவே உள்ள gateway, authentication, மற்றும் rate limiting-க்கு அருகில் அமர்கிறது. அது அவற்றில் எதையும் மாற்றாது. பொதுவான placements இதில் அடங்கும்:

Server-side middleware உங்கள் route handlers-க்கு முன், அதனால் உங்கள் business logic இயங்குவதற்கு முன்பே ஒவ்வொரு request-உம் மதிப்பாய்வு செய்யப்படுகிறது.
At the edge, அதனால் requests உங்கள் origin-ஐ அடைவதற்கு முன் signals மதிப்பாய்வு செய்யப்படுகின்றன.
A generic HTTP integration, அதனால் எந்த stack-உம் request context-ஐ அனுப்பி basis உடன் ஒரு result-ஐப் பெற முடியும்.

ஒவ்வொரு founding team-க்கும் onboarding-இல், integrations hands-on ஆக வழங்கப்படுகின்றன, அதனால் பாதை உங்கள் architecture-க்கு பொருந்தும், மாறாக அல்ல. developer hub இன்றைக்கு கிடைக்கும் integration paths-ஐக் காட்டுகிறது. நீங்கள் agents-க்கான tools-ஐ இயக்கினால், MCP Servers use case tool calls-க்கான குறிப்பிட்ட patterns-ஐக் கொண்டுள்ளது.

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

Proof of Actor-ஐ நிறுவுவது உங்கள் API எப்படி பதிலளிக்கிறது என்பதை மாற்றாது. முடிவுகள் பதிவு செய்யப்படுகின்றன, அதனால் உங்கள் team அவற்றை நீங்கள் ஏற்கனவே அறிந்த outcomes-உடன் ஒப்பிடலாம், agents உண்மையில் எங்கு செல்கிறார்கள் என்பதைப் பார்க்கலாம், ஒவ்வொரு route-இலும் unknown rate-ஐ அளவிடலாம், மற்றும் தவறாகத் தோன்றும் எந்த classification-ஐயும் பரிசீலிக்கலாம். அதன் பிறகுதான் நீங்கள் evidence ஆதரிக்கும் இடங்களில் route by route policy-ஐ இயக்குகிறீர்கள்.

இதுவே உங்கள் customer-களை ஆச்சரியப்படுத்தாமலும், அவர்கள் நம்பும் integrations-ஐ உடைக்காமலும் AI முகவர் அடையாளத்தை rollout செய்வதற்கான வழி. rolling out actor-aware policies safely பற்றிய guide படிப்படியாக sequence-ஐ விளக்குகிறது.

founding developer program-இல் சேருங்கள்

Proof of Actor ஒரு சிறிய founding development teams குழுவுடன் private beta-வில் உள்ளது. தேர்ந்த teams onboarding-இல் ஒப்புக்கொள்ளப்பட்ட usage limits-க்குள் up to 12 months free access-ஐ, மேலும் எங்கள் engineers-இலிருந்து நேரடி integration support-ஐ, அடுத்ததாக நாம் என்ன உருவாக்குகிறோம் என்பதில் உண்மையான தாக்கத்தையும் பெறலாம்.

நீங்கள் ஒரு API-யை இயக்கி, அதைப் பற்றி யார் உண்மையில் அழைக்கிறார்கள் என்பதை அறிய விரும்பினால், apply for early access. உங்கள் API, நீங்கள் மிக முக்கியமாகக் கவலைப்படும் routes, மற்றும் actor context உடன் நீங்கள் வேறுபடச் செய்வீர்கள் என்ற decisions பற்றி எங்களிடம் சொல்லுங்கள். Proof of Actor எவ்வாறு பொருந்துகிறது என்பதை நாங்கள் சொல்வோம்.

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.

உருவாக்குநர்களுக்காக

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-ஐப் படிக்கவும்

அடிக்கடி கேட்கப்படும் கேள்விகள்

AI முகவர் அடையாளம், API key authentication-இலிருந்து எவ்வாறு வேறுபடுகிறது?

ஒரு API key ஒரு request-ஐ எந்த account அனுப்பியது என்பதை சொல்கிறது. AI முகவர் அடையாளம், request-க்கு பின்னால் எந்த வகை actor உள்ளது, மேலும் அந்த முடிவை எந்த ஆதாரம் ஆதரிக்கிறது என்பதை சொல்கிறது. உங்களுக்கு இரண்டும் தேவை, மேலும் அவை வேறுபட்ட கேள்விகளுக்கு பதில் அளிக்கின்றன.

என் API-யை அழைக்கும் ஒவ்வொரு AI முகவரையும் Proof of Actor அடையாளம் காண முடியுமா?

Proof of Actor அது காணும் ஒவ்வொரு request-ஐயும் Human, Human + AI, Agent, அல்லது Unknown என்று வகைப்படுத்துகிறது, மேலும் ஒவ்வொரு முடிவிற்கும் அடிப்படையை குறிப்பிடுகிறது. ஆதாரம் போதுமான வலுவாக இல்லாதபோது, முடிவு ஒரு ஊகமாக அல்லாமல் Unknown ஆக இருக்கும்.

ஒரு முகவரை அடையாளம் காண்பது, அது செயல்பட அனுமதிக்கப்பட்டது என்பதைக் குறிக்குமா?

இல்லை. அடையாளம் காண்பதும் அங்கீகாரமும் தனித்தனியானவை. Proof of Actor, அழைப்பாளரைப் பற்றிய context-ஐ உங்கள் application-க்கு வழங்குகிறது, மேலும் அந்த அழைப்பாளர் என்ன செய்யலாம் என்பதை உங்கள் சொந்த authorization விதிகள் தீர்மானிக்கின்றன.

Proof of Actor என் API-க்கு வரும் request-களைத் தடுக்குமா?

நீங்கள் அப்படிச் செய்ய வேண்டும் என்று முடிவு செய்யாவிட்டால் இல்லை. ஒவ்வொரு integration-மும் observation mode-இல் தொடங்குகிறது, மேலும் enforcement உங்கள் team எழுதிச் செயல்படுத்தும் policies மூலமாக மட்டுமே நடக்கும்.

எனக்கு access எப்படி கிடைக்கும்?

Proof of Actor private beta-வில் உள்ளது. ஆரம்ப அணுகலுக்கு விண்ணப்பியுங்கள், மேலும் தேர்ந்த founding developer teams, ஒப்புக்கொள்ளப்பட்ட usage limits-க்குள் up to 12 months free பெறலாம்.

உங்கள் app-ஐ யார் பயன்படுத்துகிறார்கள் என்பதை அறிந்துகொள்ளுங்கள்.

founding developers-இன் சிறிய குழுவுக்கான private beta.

முன்கூட்டிய அணுகலைப் பெறுக விலை விவரங்களை காண்க

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