ஒப்பீடு

Proof of Actor vs API bot protection: keys பணம் செலுத்துபவர் யார் என்பதை சொல்கின்றன, actor context செயலில் இருப்பவர் யார் என்பதை சொல்கிறது

API gateways, WAF bot rules, API keys மற்றும் rate limits உங்கள் API-யை கிடைக்கக்கூடியதாகவும் கணக்குப்படுத்தக்கூடியதாகவும் வைத்திருக்கின்றன. ஆனால் ஒரு request app-இல் இருக்கும் ஒரு மனிதரிடமிருந்து வந்ததா, ஒரு assistant-உடன் பணிபுரியும் மனிதரிடமிருந்து வந்ததா, அல்லது ஒரு autonomous agent-இடமிருந்து வந்ததா என்பதை அவை சொல்ல உருவாக்கப்படவில்லை. API களுக்கான bot management Proof of Actor-உடன் எப்படி ஒப்பிடப்படுகிறது, மற்றும் இரண்டும் எப்படி ஒன்றாக பொருந்துகின்றன என்பதைக் கீழே பார்க்கலாம்.

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

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

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

API களுக்கான bot management உங்கள் endpoint-களை பாதுகாக்கிறது: gateways keys-ஐ authenticate செய்கின்றன, WAF bot rules தவறான traffic-ஐ வடிகட்டுகின்றன, rate limits அளவை கட்டுப்படுத்துகின்றன. Proof of Actor வேறு ஒரு அடுக்கை சேர்க்கிறது, உங்கள் API-க்கு ஒவ்வொரு caller-ம் Human, Human + AI, Agent அல்லது Unknown என எது என்பதை, அதற்குப் பின்னுள்ள evidence உடன் சொல்கிறது, இதனால் உங்கள் code ஒவ்வொன்றுக்கும் சரியான முறையில் சேவை செய்ய முடியும். பெரும்பாலான teams இரண்டையும் இயக்குகின்றன.

API களுக்கு முன்பு ஒரு எளிய traffic model இருந்தது. ஒரு developer பதிவு செய்தார், ஒரு key பெற்றார், ஒரு integration எழுதினார், அதன் பிறகு அந்த integration ஒரு schedule-ப்படி அல்லது ஒரு user ஏதோ ஒன்றை click செய்தபோது உங்கள் endpoint-களை அழைத்தது. API களுக்கான bot management அந்த model-ஐ அடிப்படையாகக் கொண்டு வளர்ந்தது: key-ஐ authenticate செய்யவும், volume-ஐ கட்டுப்படுத்தவும், வெளிப்படையாக தவறான traffic-ஐ வடிகட்டவும், மேலும் அனைவருக்கும் service கிடைக்கக்கூடியதாக வைத்திருக்கவும்.

அந்த model இன்னும் பொருந்துகிறது, அதற்காக உருவாக்கப்பட்ட tools இன்னும் முக்கியமானவையே. மாற்றம் ஏற்பட்டது calls-க்கு பின்னால் யார் இருக்கிறார்கள் என்பதில்தான். இப்போது அதே API key மூலம் உங்கள் customer-ன் app-ஐ பயன்படுத்தும் ஒரு மனிதரிடமிருந்து, ஒரு AI assistant-ஐ வைத்து வேலை செய்யச் சொன்ன ஒரு மனிதரிடமிருந்து, மற்றும் இரவு முழுவதும் பல படிகள் கொண்ட task-ஐ இயக்கும் ஒரு autonomous agent-இடமிருந்து requests வரலாம். உங்கள் தற்போதைய controls ஒரு key-யையும் ஒரு request rate-ஐயும் மட்டுமே பார்க்கின்றன. ஆனால் உங்கள் product, support மற்றும் policy முடிவுகளுக்கு பெரும்பாலும் இன்னும் அதிகமான தகவல் தேவைப்படுகிறது.

Proof of Actor அந்த இடைவெளியை நிரப்புகிறது. ஒவ்வொரு request-இலும் யார் அல்லது எது செயல்படுகிறது என்பதை உங்கள் API-க்கு தெரிவித்து, evidence-ஐ குறிப்பிடுகிறது, பின்னர் முடிவை உங்கள் code-இல் விட்டுவிடுகிறது. இந்த page, API bot protection-ன் முக்கிய அடுக்குகளுடன் இதை ஒப்பிட்டு, ஒவ்வொன்றும் எங்கு பொருந்துகிறது என்பதை நீங்கள் பார்க்க உதவுகிறது.

சுருக்கமான பதிப்பு

	API bot protection	Proof of Actor
முக்கிய கேள்வி	இந்த request அனுமதிக்கப்பட்டதா, authenticated ஆனதா, மற்றும் வரம்பிற்குள் உள்ளதா?	யார் அல்லது எது செயற்படுகிறது, மேலும் evidence என்ன?
வழக்கமான அடுக்குகள்	API gateway, WAF bot rules, API keys, rate limits	உங்கள் API அல்லது MCP server-க்குள் actor classification
அடையாளம் காண்பது	key-ஐ own செய்கிற account அல்லது integration	ஒவ்வொரு request-க்குப் பின்னுள்ள actor: Human, Human + AI, Agent அல்லது Unknown
வெளியீடு	Allow, reject, throttle; சில நேரங்களில் ஒரு bot score	ஒரு class plus a basis: verified, declared, inferred அல்லது unknown
தெளிவில்லாத traffic	பொதுவாக key செல்லுபடியாக இருந்தால் அனுமதிக்கப்படும், அல்லது ஒரு rule மூலம் மறுக்கப்படும்	Unknown, நீங்கள் route-க்கு ஏற்ப தேர்வு செய்யும் fallback உடன்
response-ஐ யார் தீர்மானிக்கிறார்	Gateway மற்றும் WAF configuration	உங்கள் application code
நிறுவியபின் இயல்புநிலை	Enforcement	Observation; நீங்கள் ஒரு policy சேர்க்கும் வரை எதுவும் மாறாது
எதில் சிறந்தது	Availability, abuse filtering, quotas, accountability	ஒவ்வொரு actor-க்கும் சரியான முறையில் சேவை செய்தல் மற்றும் API பயன்பாட்டை புரிந்துகொள்ளுதல்

கீழே உள்ள பகுதிகள் ஒவ்வொன்றையும் விளக்குகின்றன.

API bot protection நன்றாகச் செய்வது என்ன

ஒவ்வொரு layer-மும் என்ன வேலை செய்கிறது என்பதைத் தெளிவாகக் கூறுவது பயனுள்ளதாகும், ஏனெனில் Proof of Actor அவற்றை மாற்றுவதற்காக அல்ல, அனைத்துடனும் பக்கத்தில் அமர்வதற்காக வடிவமைக்கப்பட்டுள்ளது.

API gateways

A gateway என்பது உங்கள் API-க்கான front door. அது connections-ஐ terminate செய்கிறது, API keys அல்லது tokens-ஐ authenticate செய்கிறது, requests-ஐ சரியான service-க்கு route செய்கிறது, quotas-ஐ enforce செய்கிறது, மற்றும் billing மற்றும் analytics-க்காக usage-ஐ அடிக்கடி பதிவு செய்கிறது. அது "இந்த caller-க்கு உள்ளே வர அனுமதி உள்ளதா, எந்த door வழியாக?" என்ற கேள்விக்கு விரைவாகவும் ஒரே மாதிரியாகவும் ஒவ்வொரு endpoint-இலும் பதில் அளிக்கிறது.

WAF bot rules

Bot rules உடன் உள்ள web application firewall, அறியப்பட்ட attack patterns மற்றும் தவறான automation-ஐ traffic-இல் இருந்து ஆய்வு செய்கிறது. அது injection முயற்சிகளை வடிகட்டலாம், abuse history உள்ள sources-இலிருந்து வரும் traffic-ஐ block செய்யலாம், மேலும் scraping அல்லது credential attacks போலத் தோன்றும் requests-ஐ challenge செய்யலாம் அல்லது drop செய்யலாம். உங்கள் code-ஐ எட்டவே கூடாத traffic-க்கு இது மிகச் சிறந்த பாதுகாப்பு.

API keys and tokens

Keys மற்றும் tokens accountability-ஐ வழங்குகின்றன. ஒவ்வொரு request-மும் ஒரு account-க்கு map ஆகிறது, எனவே எந்த integration call செய்தது என்பதை நீங்கள் அறிவீர்கள், access-ஐ revoke செய்ய முடியும், மற்றும் usage-ஐ attribute செய்ய முடியும். Scoped tokens இதை மேலும் விரிவாக்கி caller என்ன செய்யலாம் என்பதை கட்டுப்படுத்துகின்றன.

Rate limits

Rate limits availability-ஐ பாதுகாக்கின்றன. ஒரு integration அனைவருக்கும் intended ஆக உள்ள capacity-ஐ முழுதும் பயன்படுத்துவதை அவை தடுக்கின்றன, மேலும் brute-force மற்றும் enumeration முயற்சிகளை மெதுவாக்குகின்றன. Per-key மற்றும் per-route limits என்பது நிலையான, பயனுள்ள control ஆகும்.

இந்த அடுக்குகள் ஒன்றாக protection மற்றும் accountability குறித்த கேள்விகளுக்கு மிகச் சிறப்பாக பதில் அளிக்கின்றன. அவற்றை வைத்திருங்கள்.

அவை பதிலளிக்க உருவாக்கப்படாத கேள்வி

அந்த layers எதுவும் authenticated request-க்கு பின்னால் எந்த வகையான actor இருக்கிறார் என்பதைச் சொல்ல உருவாக்கப்படவில்லை. ஒரு செல்லுபடியாகும் key எந்த account integration-ஐ own செய்கிறது என்பதைச் சொல்கிறது. அது இவற்றில் எதையும் சொல்லாது:

இந்த குறிப்பிட்ட call உங்கள் customer-ன் app-இல் ஒரு button-ஐத் தட்டிய ஒரு மனிதரிடமிருந்து வந்ததா என்பது,
ஒரு மனிதர் ஒரு AI assistant-ஐ அந்த action செய்யக் கேட்டாரா என்பது,
ஒரு autonomous agent நீண்ட task-இன் ஒரு படியாக அந்த call-ஐ செய்ததா என்பது,
அல்லது யாரும் உறுதியாக சொல்ல முடியாதா என்பது.

அந்த வேறுபாடு ஒவ்வொரு மாதமும் மேலும் முக்கியமாகிறது. CRM integration, scheduling tool அல்லது developer platform-ஐ சேவை செய்யும் ஒரு API, human-driven apps-ஐ சேவை செய்யும் அதே keys வழியாக agent traffic-ஐ அதிகமாகப் பெறுகிறது. நீங்கள் agents-க்கு ஒரு structured response அளிக்க, உயர்ந்த தாக்கம் கொண்ட writes-க்கு confirmation தேவைப்படுத்த, AI உதவியுடன் செய்யப்பட்ட submissions-ஐ label செய்ய, அல்லது உங்கள் API பயன்பாட்டில் எவ்வளவு agent-driven என்பதை simply measure செய்ய விரும்பினால், உங்களுக்கு actor context தேவை.

Proof of Actor ஒரு API-க்கு சேர்ப்பது என்ன

ஒவ்வொரு interaction-க்கும் Proof of Actor நான்கு class-களில் ஒன்றைத் தருகிறது:

Human: காணக்கூடிய signals மனிதர் வழிநடத்தும் interaction-ஐக் காட்டுகின்றன.
Human + AI: ஒரு person, declared ஆகவோ அல்லது ஆதரிக்கப்படும் integration மூலம் காணப்பட்ட AI உதவியுடன் interaction-ஐ வழிநடத்தினார்.
Agent: automated அல்லது agent-origin interaction.
Unknown: evidence நம்பகமான முடிவை ஆதரிக்கவில்லை.

ஒவ்வொரு result-மும் அதன் evidence basis-ஐக் குறிப்பிடுகிறது:

Verified: உதாரணமாக, published key-க்கு எதிராக சரிபார்க்கப்பட்ட ஒரு HTTP Message Signature (RFC 9421).
Declared: client அல்லது உங்கள் சொந்த application அதை அறிவித்தது.
Inferred: behavioral அல்லது contextual signals, inference எனத் தெளிவாகக் குறிக்கப்பட்டவை.
Unknown: நம்பகமான basis இல்லை.

API களுக்கு, verified basis குறிப்பாக பயனுள்ளது. தங்கள் requests-ஐ sign செய்யும் agents-ஐ அவர்களின் published keys-க்கு எதிராகச் சரிபார்க்க முடியும், மேலும் இதுவே IETF Web Bot Auth பணியின் பின்னணியாக உள்ளது. பின்னணிக்காக Web Bot Auth for product teams என்ற விளக்கத்தையும், செயல்படுத்தும் பக்கத்திற்காக verifying signed agent requests என்ற வழிகாட்டியையும் படிக்கவும்.

இங்கு ஒரு வரம்பு முக்கியமானது. செல்லுபடியாகும் signature எந்த key request-ஐ sign செய்தது என்பதை நிரூபிக்கிறது. ஆனால் அந்த agent அந்த action-ஐ செய்ய authorized என்பதை அது நிரூபிக்காது. Authorization உங்கள் API-யின் சொந்த access control-இலேயே இருக்க வேண்டும். agent authorization உள்ளீடு அந்த வேறுபாட்டை விளக்குகிறது.

Scores மற்றும் keys vs actor evidence

சில bot protection products ஒவ்வொரு request-க்கும் ஒரு score-ஐ இணைக்கின்றன. ஒரு block முடிவிற்கு score திறமையானது. ஆனால் API product முடிவுகளுக்கு அது குறைவான பயன் உடையது, ஏனெனில் ஒரு legitimate request மனிதரால் இயக்கப்பட்டதா அல்லது agent-ஆல் இயக்கப்பட்டதா என்பதை அது சொல்லாது, மேலும் verified facts-ஐ inference-இலிருந்து பிரிக்காது.

API keys-க்கு எதிர்மறையான வரம்பு உள்ளது. அவை ownership குறித்து துல்லியமானவை, actor குறித்து அமைதியாக இருக்கும். ஒரு customer-ன் key ஒரு மணி நேரத்திலேயே நான்கு class-களையும் எடுத்துச் செல்லலாம்.

Proof of Actor இந்த இரு வேறுபாடுகளையும் தெளிவாக வைத்திருக்கிறது. உங்கள் API key-இலிருந்து account-ஐ, Proof of Actor-இலிருந்து actor class-ஐ, மற்றும் அதை ஆதரிக்கும் basis-ஐப் பார்க்கிறது. ஒவ்வொரு layer-மும் தன்னால் சிறப்பாக பதிலளிக்கக்கூடிய கேள்விக்கு பதில் அளிக்கிறது.

ஒவ்வொன்றும் எங்கு இயங்குகிறது

Gateways மற்றும் WAFs உங்கள் network-ன் edge-இல் அல்லது உங்கள் services-க்கு முன்னால் இயங்குகின்றன. பாதுகாப்பு மற்றும் quotas-க்கான சரியான இடம் அதுவே.

Proof of Actor உங்கள் API logic இருக்கும் இடத்தில் இயங்குகிறது. Founding teams Node.js middleware, Next.js, நீங்கள் கட்டுப்படுத்தும் ஒரு edge layer, generic HTTP API, அல்லது ஒரு MCP server integration வழியாக இதை இணைக்கலாம். முழு பட்டியலுக்கு integrations-ஐப் பார்க்கவும். இது உங்கள் application-க்குள் இயங்குவதால், route, workflow, client தன்னை declare செய்ததா, signature verify ஆனதா போன்ற உங்கள் API அறிந்தவற்றைப் பயன்படுத்த முடியும்.

Routing முடிவுகள் உங்கள் code-இலேயே இருக்கும்

Proof of Actor இயல்பாக எதையும் block செய்யாது. அது observation mode-இல் தொடங்குகிறது, ஆகவே அதை நிறுவுவது உங்கள் API எப்படி respond செய்கிறது என்பதில் எதையும் மாற்றாது. endpoint-கள் வழியாக உங்கள் actor mix-ஐப் பார்க்கலாம், தனிப்பட்ட results-க்கான evidence-ஐ review செய்யலாம், மற்றும் உங்கள் Unknown rate-ஐக் கண்காணிக்கலாம்.

நீங்கள் தயாரானபோது, ஒவ்வொரு route-க்கும், actor class-க்கும், basis-க்கும் application-defined policies-ஐ எழுதுகிறீர்கள். பொதுவான outcomes:

Allow: request-ஐ சாதாரணமாகச் சேவை செய்யவும்.
Adapt: verified agent-க்கு structured அல்லது குறைக்கப்பட்ட response-ஐத் திருப்பவும்.
Challenge: கூடுதல் confirmation படியைத் தேவைப்படுத்தவும், உதாரணமாக உயர்ந்த தாக்கம் கொண்ட write-க்கு மனித ஒப்புதல்.
Review: action-ஐ ஒரு person சரிபார்க்க வரிசையில் வைக்கவும்.
Rate-limit: குறிப்பிட்ட route-இல் ஒரு குறிப்பிட்ட class மற்றும் basis-க்கு கடுமையான limit-ஐப் பயன்படுத்தவும்.

ஒரு policy-யை உண்மையான traffic-க்கு எதிராக preview செய்து, பிறகு enforce செய்யலாம், அதன்பின் route by route enforce செய்யலாம். rolling out actor-aware policies safely என்ற வழிகாட்டி செயல்முறையை உள்ளடக்கியது, மற்றும் protecting sensitive actions without blocking agents பொதுவான patterns-ஐக் காட்டுகிறது.

Unknown API callers-ஐக் கையாளுதல்

ஒவ்வொரு API-க்கும் நம்பிக்கையுடன் classify செய்ய முடியாத traffic கிடைக்கிறது. பாரம்பரிய controls-இல், செல்லுபடியாகும் key பொதுவாக request-ஐ உள்ளே அனுமதிக்கும், செல்லுபடியாகாத key அனுமதிக்காது. நடுவில் எதுவும் இல்லை.

Proof of Actor உங்களுக்கு explicit Unknown result-ஐ வழங்குகிறது, மேலும் route-க்கு ஏற்ப fallback-ஐத் தேர்வு செய்ய விடுகிறது. Read-only catalog endpoints திறந்தவையாகவே இருக்கலாம். Account changes உங்கள் தற்போதைய கடுமையான checks-ஐத் தொடர்ந்து வைத்திருக்கலாம். Bulk exports review-க்கு செல்லலாம். விவரங்களுக்கு handling Unknown traffic மற்றும் unknown automated traffic-ஐப் பார்க்கவும்.

அவை எப்படி ஒன்றாகச் செயல்படுகின்றன

மிக வலுவான API setup ஒவ்வொரு layer-ஐ அதன் சொந்த job-க்கு பயன்படுத்துகிறது:

Edge-இல், WAF தவறான மற்றும் malformed traffic-ஐ வடிகட்டுகிறது.
Gateway-இல், keys authenticate செய்யப்படுகின்றன, quotas enforce செய்யப்படுகின்றன, மற்றும் usage பதிவு செய்யப்படுகிறது.
API-க்குள், Proof of Actor கடந்து வரும் ஒவ்வொரு request-ஐ classify செய்து அதன் basis-ஐக் குறிப்பிடுகிறது.
உங்கள் handlers-இல், policies class மற்றும் basis-ஐப் பயன்படுத்தி response-ஐத் தேர்வு செய்கின்றன: human-driven call-க்கு சாதாரண handling, verified agent-க்கு structured response, agent-driven உயர்ந்த தாக்கம் கொண்ட write-க்கு confirmation step, Unknown-க்கு fallback.
Analytics-இல், உங்கள் team ஒவ்வொரு actor class-மும் எந்த endpoints மற்றும் workflows-ஐ பயன்படுத்துகிறது என்பதைக், gateway-இலிருந்து வரும் account data-உடன் சேர்த்து பார்க்கிறது.

இந்த stack-இல் எதுவும் மீளச்செய்யப்படவில்லை. Gateway account-ஐ அறிகிறது, WAF threat patterns-ஐ அறிகிறது, மற்றும் Proof of Actor actor-ஐ அறிகிறது.

எதில் எதை முதலில் கவனிக்க வேண்டும்

உங்கள் முக்கிய பிரச்சினைகள் abuse, availability, அல்லது unmetered usage ஆக இருந்தால் முதலில் API bot protection-ஐ கவனியுங்கள்: auth endpoints-க்கு எதிரான credential attacks, aggressive scraping, அல்லது பிறவற்றின் capacity-ஐ சுரண்டும் ஒரு integration.

உங்கள் முக்கிய கேள்விகள் உங்கள் callers குறித்து இருந்தால் Proof of Actor-ஐ கவனியுங்கள்: உங்கள் API traffic-இல் எவ்வளவு agent-driven, எந்த agents எந்த endpoints-ஐ call செய்கின்றன, மனிதர் இயக்கிய usage மற்றும் agent இயக்கிய usage எங்கு வேறுபடுகின்றன, மற்றும் எந்த routes-க்கு actor-aware policy தேவை. APIs use case மற்றும் AI agent identification for APIs மேலும் ஆழமாகக் கூறுகின்றன.

Production API-யை இயக்கும் பெரும்பாலான teams-க்கு இரண்டிற்குமான பதில்களும் தேவைப்படுகின்றன.

தொடங்குங்கள்

Proof of Actor private beta-வில் உள்ளது. தேர்ந்தெடுக்கப்பட்ட founding developer teams, ஒப்புக்கொள்ளப்பட்ட usage limits-க்குள், automatic billing இல்லாமல், 12 months வரை இலவச access பெற முடியும். early access-க்கு விண்ணப்பிக்கவும் மற்றும் நீங்கள் புரிந்துகொள்ள விரும்பும் API மற்றும் callers குறித்து எங்களுக்குத் தெரிவிக்கவும்.

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

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

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

Proof of Actor என் API gateway அல்லது WAF-ஐ மாற்றிவிடுமா?

இல்லை. உங்கள் gateway இன்னும் keys-ஐ authenticate செய்து quotas-ஐ enforce செய்கிறது, மேலும் உங்கள் WAF இன்னும் தவறான traffic-ஐ வடிகட்டுகிறது. Proof of Actor உங்கள் API-க்குள் இயங்கி, கடந்து வரும் requests-க்கு actor context-ஐ சேர்க்கிறது. உங்கள் தற்போதைய controls-ஐ வைத்திருக்கவும்.

ஒவ்வொரு caller-க்கும் API key இருந்தால், actor context ஏன் தேவை?

ஒரு API key அந்த integration-ஐ own செய்கிற account-ஐ அடையாளம் காட்டுகிறது. ஆனால் ஒரு குறிப்பிட்ட request உங்கள் customer-ன் app-இல் button-ஐ click செய்கிற ஒரு மனிதரால் இயக்கப்பட்டதா, AI assistant-ஐ பயன்படுத்திய ஒரு மனிதராலா, அல்லது ஒரு task-ஐ இயக்கும் autonomous agent-ஆலா என்பதைக் அது சொல்லாது. Proof of Actor இதை, அதன் basis-உடன், தெரிவிக்கிறது.

என் API-க்கு எந்த agent call செய்கிறது என்பதை Proof of Actor verify செய்யுமா?

ஒரு client அதன் requests-ஐ HTTP Message Signatures (RFC 9421) மூலம் sign செய்து, அதன் key-ஐ publish செய்தால், Proof of Actor signature-ஐ சரிபார்த்து verified basis-ஐ தெரிவிக்கிறது. செல்லுபடியாகும் signature எந்த key request-ஐ sign செய்தது என்பதை நிரூபிக்கிறது. ஆனால் அந்த agent அந்த action-ஐ செய்ய authorized என்பதை அது நிரூபிக்காது, ஆகவே authorization உங்கள் code-இலேயே இருக்கும்.

Proof of Actor என் API traffic-ஐ rate-limit செய்யத் தொடங்குமா அல்லது block செய்யுமா?

இல்லை. அது observation mode-இல் தொடங்குகிறது, default-ஆக எதையும் block செய்யாது. ஒரு policy-யில், route ஒன்றுக்கு, actor class ஒன்றுக்கு, basis ஒன்றுக்கு rate-limit என்பது நீங்கள் தேர்ந்தெடுக்கக்கூடிய outcome-களில் ஒன்றாகும், மேலும் enforcement உங்கள் சொந்த code-இல் இருக்கும்.

ஒரு API-க்கு Proof of Actor-ஐ எப்படி சேர்ப்பது?

Founding teams Node.js middleware, Next.js, ஒரு edge integration அல்லது generic HTTP API-யைப் பயன்படுத்தலாம். MCP servers-க்கு தங்களுக்கான integration உள்ளது. விவரங்களுக்கு integrations page-ஐப் பார்க்கவும்.

நான் classifie செய்ய முடியாத callers-க்கு என்ன நடக்கும்?

அவர்கள் Unknown என தெரிவிக்கப்படுவார்கள், இது ஒரு first-class result. ஒவ்வொரு route-க்கும் நீங்கள் fallback-ஐத் தேர்வு செய்கிறீர்கள், உதாரணமாக read-only endpoints-இல் allow செய்து, எழுதும் endpoints-இல் உங்கள் கடுமையான checks-ஐ வைத்திருங்கள்.

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

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

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

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