ధృవీకరించబడిన ఆటోమేషన్

ధృవీకరించబడిన ఆటోమేటెడ్ అభ్యర్థనలను గుర్తించండి

ఒక ఆటోమేటెడ్ క్లయింట్ తన అభ్యర్థనలపై సంతకం చేసినప్పుడు, మీ అప్లికేషన్ ఆ సంతకాన్ని తనిఖీ చేసి కాలర్‌ను దానికి అనుగుణంగా నిర్వహించగలదు. Proof of Actor ఆ తనిఖీని స్పష్టమైన, రూట్ చేయగల ఫలితంగా మారుస్తుంది.

తొందరగా యాక్సెస్ పొందండి ఇది ఎలా పనిచేస్తుందో అన్వేషించండి

రచన Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

అన్ని ఆటోమేటెడ్ traffic ఒకేలా ఉండదు

ఆటోమేటెడ్ క్లయింట్లు ప్రతి నిమిషం మీ applicationకు చేరుకుంటాయి: search crawlers, monitoring tools, ఒక user కోసం pagesను fetch చేసే partner integrations, AI assistants, మరియు tasksను పూర్తి చేసే autonomous agents. సంవత్సరాలుగా, చాలా applications వాటిని వేరు గుర్తించగలిగిన ఏకైక మార్గం user-agent header మాత్రమే, దీన్ని ఏ client అయినా ఏ విలువకైనా set చేయగల ఒక string.

దీని వల్ల application teams ఒక చిక్కులో పడతాయి. అన్ని automationను అనుమానంతో చూస్తే, మీ customers ఆధారపడే legitimate agents అనుభవం దెబ్బతింటుంది. headerను నమ్మితే, ఎవరైనా తాము ప్రసిద్ధ crawler అని చెప్పుకునే అవకాశం కలుగుతుంది.

ధృవీకరించబడిన ఆటోమేటెడ్ అభ్యర్థనలు ఈ సమీకరణాన్ని మార్చుతాయి. ఒక ఆటోమేటెడ్ క్లయింట్ తాను ప్రచురించిన keyతో తన అభ్యర్థనలపై సంతకం చేసినప్పుడు, మీ application ఆ సంతకాన్ని తనిఖీ చేసి, cryptographic గా, ఏ client ఆ అభ్యర్థనపై సంతకం చేసిందో తెలుసుకోగలదు. Proof of Actor ఆ తనిఖీని మీ code route చేయగల ఒకే, సుసంగత actor resultలో భాగంగా చేస్తుంది. ఆ తనిఖీ ఏమి స్థాపిస్తుంది, ఏమి స్థాపించదు అన్నదాన్ని దగ్గరగా చూడాలంటే signed AI agent requests prove ఏమి చదవండి.

request signing ఎలా పనిచేస్తుంది

ఆటోమేటెడ్ traffic కోసం ఉద్భవిస్తున్న విధానం HTTP message signaturesను ఉపయోగిస్తుంది, ఇవి RFC 9421లో ప్రమాణీకరించబడ్డాయి, ఇది ఒక HTTP message భాగాలపై signaturesను ఎలా సృష్టించాలి, encode చేయాలి మరియు verify చేయాలో నిర్వచిస్తుంది. client private keyతో ప్రతి requestలోని ఎంచుకున్న భాగాలపై సంతకం చేసి, headersలో signature మరియు దాని parametersను చేర్చుతుంది. ఇది తన నియంత్రణలో ఉన్న identifierకు, సాధారణంగా దాని domainకు, అనుసంధానించిన స్థానంలో corresponding public keyను ప్రచురిస్తుంది.

అభ్యర్థన వచ్చినప్పుడు, receiver ప్రచురిత keyను fetch చేస్తుంది లేదా lookup చేస్తుంది, signed contentను తిరిగి నిర్మిస్తుంది, మరియు signatureను తనిఖీ చేస్తుంది. అది validate అయితే, ఆ request ఆ keyను కలిగి ఉన్నవారు సంతకం చేసినదని అర్థం. ఆటోమేటెడ్ trafficపై signingకు సంబంధించిన పని IETF Web Bot Auth working groupలో కొనసాగుతోంది, దీని charter crawlers మరియు end users తరపున పనిచేసే AI agents వంటి ఆటోమేటెడ్ clientsను cryptographically authenticate చేయడాన్ని కవర్ చేస్తుంది; Web Bot Auth glossary entry దానిని సంక్షిప్తంగా వివరిస్తుంది. signed AI agent requests prove ఏమి అనే blog post ధృవీకరించబడిన requestను మొదటి నుంచి చివరి వరకు చూపిస్తుంది, మరియు APIs use case verification మొదట ఎక్కడ విలువ ఇస్తుందో చూపిస్తుంది.

verifying signed agent requests గైడ్ timestamps, replay windows, మరియు key cachingను కలుపుకుని mechanicsను వివరంగా కవర్ చేస్తుంది.

ధృవీకరించబడిన సంతకం ఏమి నిరూపిస్తుంది, ఏమి నిరూపించదు

ధృవీకరించబడిన ఆటోమేటెడ్ అభ్యర్థనలను బాగా నిర్వహించడంలో ఈ తేడా అత్యంత ముఖ్యమైన భాగం.

ఒక valid signature నిరూపిస్తుంది: ఆ request ప్రచురిత identifierకు అనుసంధానించిన keyతో సంతకం చేయబడిందని. key operator యొక్క domainకు చెందితే, ఆ request ఆ operator యొక్క keyను కలిగి ఉన్న client నుండి వచ్చింది.

ఒక valid signature నిరూపించదు:

agentకు ఎవరు సూచన ఇచ్చారు, లేదా ఈ చర్యను చేయమని ఏదైనా వ్యక్తి కోరాడా లేదా;
ఒక వ్యక్తి agentకు authorityను అప్పగించాడా లేదా;
operator వెనుక ఉన్న నిజ జీవిత legal identity;
కోరిన చర్య మీ applicationలో సురక్షితమా లేదా అనుమతించబడిందా లేదా.

ఇవి వేరే ప్రశ్నలు. మీ application వాటిని తన స్వంత credentials, authorization model, మరియు policyతో సమాధానం ఇస్తుంది. Proof of Actor వీటిని ఉద్దేశపూర్వకంగా వేరు ఉంచుతుంది, మరియు Detection & Limitations పేజీ ప్రతి evidence రకం ఏమి స్థాపించగలదో ఖచ్చితంగా వివరిస్తుంది.

Proof of Actor ధృవీకరించబడిన ఆటోమేటెడ్ అభ్యర్థనలను ఎలా నిర్వహిస్తుంది

Detect

మీ integration, ఏ signature headers అయినా సహా, request contextను Proof of Actorకు పంపుతుంది. Signaturesను ప్రచురిత keysతో పోల్చి తనిఖీ చేస్తారు. validate అయిన requests ధృవీకరించబడిన ఆధారంతో నమోదు అవుతాయి. తాము మాత్రమే పేరు చెప్పుకునే clients ప్రకటించినగా నమోదు అవుతాయి. ప్రవర్తనా patterns ఊహించినగా నమోదు అవుతాయి. తగిన సమాచారం లేకపోతే, ఫలితం Unknown. cryptographic check ఉత్తీర్ణం కాకపోతే ఏదీ ధృవీకరించబడినదిగా మారదు.

Understand

మీ applicationను ఏ verified operators పిలుస్తున్నారు, వారు ఏ routesను ఉపయోగిస్తున్నారు, ఎంత తరచుగా, మరియు అది ప్రకటించిన మరియు Unknown automationతో ఎలా పోలుస్తుందో చూడండి. ప్రతి ఫలితంలోని evidence summaryలో ఏ key మరియు identifier పాల్గొన్నాయో తెలియజేయబడుతుంది, కాబట్టి మీ team ఏ requestనైనా త్వరగా పరిశీలించగలదు.

Route

మీ policiesలో ఆధారాన్ని ఉపయోగించండి. సాధారణ patternsలో ఇవి ఉన్నాయి:

చదవడానికి మాత్రమే ఉన్న routesలో, ఉదాహరణకు API లేదా page యొక్క Markdown versionలో, verified agentsకు structured response ఇవ్వండి.
గుర్తించిన verified operators కోసం rate limitsను పెంచండి, అయితే ప్రకటించిన clientsకు standard limitsను ఉంచండి.
signature ఏమి చెప్పినా, ప్రతి write routeలో మీ existing authorizationను కొనసాగించండి.
ప్రతి routeలో unsigned మరియు Unknown callers కోసం స్పష్టమైన fallbackను నిర్వచించండి.

మీ policies నిర్ణయిస్తాయి; Proof of Actor evidenceను అందిస్తుంది.

user-agent header ఎందుకు సరిపోదు

User-agent strings declarations మాత్రమే. ఏ client అయినా ఏ valueనైనా పంపగలదు, మరియు user-agent spoofingకి ఎలాంటి నైపుణ్యం అవసరం లేదు. అందుకే crawler operators తమ స్వంత checksను ప్రచురిస్తారు: Google verifying Googlebot కోసం reverse మరియు forward DNS lookups మరియు ప్రచురిత IP rangesను డాక్యుమెంట్ చేస్తుంది, Bing verifying Bingbot కోసం ఒక DNS checkను డాక్యుమెంట్ చేస్తుంది, మరియు OpenAI దాని ప్రతి crawlers and user agents కోసం IP range filesను ప్రచురిస్తుంది. Proof of Actor ఒక user-agent claimను ప్రకటించిన evidenceగా పరిగణిస్తుంది, verificationగా ఎప్పుడూ కాదు. అంటే చెల్లుబాటు అయ్యే signature లేకుండా తాను ప్రసిద్ధ crawler అని చెప్పుకునే client ప్రకటించిన లేదా ఊహించిన ఆధారంతో నివేదించబడుతుంది, మరియు మీ policy దాన్ని తన identityను నిరూపించిన clientతో భిన్నంగా పరిగణించగలదు.

ఇదే verified automated requestsను విలువైనదిగా 만드는 విషయం: వాటి headerను కాపీ చేసే ప్రతివారికీ కాదు, దాన్ని సంపాదించిన clientsకు trustను విస్తరించడానికి నమ్మదగిన మార్గాన్ని ఇవి ఇస్తాయి.

identity evidence, credentials, మరియు authorization

ఆటోమేటెడ్ clientsకు సేవలందించే ఏ applicationలోనైనా మూడు layers కలిసి పనిచేస్తాయి:

Identity evidence: ఈ requestపై ఏ client సంతకం చేసింది? ధృవీకరించబడిన signature దీనికి సమాధానం ఇస్తుంది.
Credentials: ఏ account బాధ్యత వహిస్తోంది? మీ API key, token, లేదా session దీనికి సమాధానం ఇస్తుంది.
Authorization: ఈ caller ఇది చేయగలడా? మీ permission model దీనికి సమాధానం ఇస్తుంది.

Proof of Actor మొదటి layerను బలపరచి దాన్ని కనిపించేలా చేస్తుంది. అది identity లేదా delegation credentialsను జారీ చేయదు, మరియు మీ authorizationను భర్తీ చేయదు. layersను వేరు ఉంచడమే తక్కువ-ప్రమాద routesలో verified agentsకు ఉదారంగా ఉండటానికి, మరియు అధిక ప్రభావం ఉన్న వాటిలో జాగ్రత్తగా ఉండటానికి అవకాశం ఇస్తుంది.

ఇది ఎక్కడ సరిపోతుంది

Proof of Actor మీ gateway, authentication, మరియు rate limitingతో పాటు పనిచేస్తుంది. Integrations server-side middlewareగా, edgeలో, మీ MCP serverలో, లేదా generic HTTP integration ద్వారా నడుస్తాయి, ప్రతి founding teamతో చేతికి అందే విధంగా అందించబడతాయి. మీ traffic ఎక్కువగా APIs మరియు tools అయితే, APIs మరియు MCP Servers use cases అత్యంత ముఖ్యమైన patternsను చూపిస్తాయి.

observation modeలో ప్రారంభించండి

ప్రతి integration observation modeలో ప్రారంభమవుతుంది. మీ application ఎలా స్పందిస్తుందో మార్చకుండా results నమోదు అవుతాయి, కాబట్టి మీ ఆటోమేటెడ్ trafficలో ఎంత భాగం ధృవీకరించబడిందో, ఏ operators sign చేస్తున్నారో, మరియు Unknown rate ఎక్కడ ఎక్కువగా ఉందో చూడగలరు. policies తరువాత, route by route, evidence వాటిని మద్దతు ఇచ్చినప్పుడు వస్తాయి. How It Works పూర్తి flowను చూపిస్తుంది.

verificationను నమ్మదగినదిగా 만드는 ప్రాయోగిక వివరాలు

Signature checking చుట్టూ ఉన్న వివరాలంతే మంచిది. కొన్ని practices ధృవీకరించబడిన ఆటోమేటెడ్ requestsను productionలో నమ్మదగినవిగా చేస్తాయి.

తాజాదనాన్ని తనిఖీ చేయండి

RFC 9421 created మరియు expires signature parametersను నిర్వచిస్తుంది, మరియు signed requests సాధారణంగా వాటిని కలిగి ఉంటాయి. captured requestను తర్వాత replay చేయలేకుండా ఉండేందుకు, తక్కువ window వెలుపల ఉన్న signaturesను తిరస్కరించండి.

keysను సమంజసంగా cache చేయండి

ప్రతి requestలో operator యొక్క ప్రచురిత keysను fetch చేయడం latencyను పెంచుతుంది. వాటిని తగిన కాలం పాటు cache చేసి, తెలియని key identifierతో signature విఫలమైనప్పుడు refresh చేయండి, తద్వారా key rotation తప్పుడు failuresకు దారి తీస్తుంది.

requestలో సరైన భాగాలపై సంతకం చేయండి

కేవలం timestampను మాత్రమే కవర్ చేసే signature చాలా తక్కువను నిరూపిస్తుంది. signed componentsలో method, path, మరియు host ఉన్నాయో లేదో తనిఖీ చేయండి, తద్వారా signature మీ application నిజంగా స్వీకరించిన requestకు bind అవుతుంది.

evidenceను నమోదు చేయండి

ప్రతి verified requestతో key identifier, ప్రచురిత identifier, మరియు resultను ఉంచండి. ఏదైనా అసాధారణం జరిగితే, మీ team ఏ client ఏమి, ఎప్పుడు సంతకం చేసిందో ఖచ్చితంగా చూడగలదు.

Proof of Actor ఇవి Detect stepలో భాగంగా నిర్వహిస్తుంది మరియు మీ policies చదవగల ఆధారంగా ఫలితాన్ని నివేదిస్తుంది, తద్వారా మీ application code సులభంగా ఉంటుంది.

founding developer programలో చేరండి

Proof of Actor private betaలో ఉంది. ఎంపికైన founding development teams అంగీకరించిన usage limits లోపల, మా engineers నుండి ప్రత్యక్ష integration supportతో, 12 నెలల వరకు ఉచిత accessను పొందగలవు.

ఆటోమేటెడ్ clients మీ applicationకు వస్తున్నాయి, మరియు verified onesను భిన్నంగా నిర్వహించాలని మీరు అనుకుంటే, early access కోసం దరఖాస్తు చేయండి. మీ application గురించి మరియు మీరు చూస్తున్న ఆటోమేటెడ్ callers గురించి చెప్పండి, మేము Proof of Actor ఎలా సరిపోతుందో చూపిస్తాము.

మూలాలు

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

డెవలపర్ల కోసం

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: result వెనుక ఉన్న signals, అందువల్ల మీ team ఎందుకు అని చూడగలదు.

observation mode లో ప్రారంభించండి: results ను మీ logs పక్కనే నమోదు చేయండి మరియు మీరు ఒక policy ఎంచుకునే వరకు ఏమీ మార్చవద్దు. Node.js integration guide ను చదవండి

తరచుగా అడిగే ప్రశ్నలు

ధృవీకరించబడిన ఆటోమేటెడ్ అభ్యర్థన అంటే ఏమిటి?

ఇది తెలిసిన identifier, ఉదాహరణకు operator యొక్క domain, కోసం ప్రచురించబడిన కీకి తన క్రిప్టోగ్రాఫిక్ సంతకం ధృవీకరించబడే ఆటోమేటెడ్ క్లయింట్ నుండి వచ్చిన అభ్యర్థన. ఇది ఏ క్లయింట్ ఆ అభ్యర్థనపై సంతకం చేసిందో చూపిస్తుంది.

ధృవీకరించబడిన సంతకం అంటే agent కు authorization ఉందని అర్థమా?

లేదు. సంతకం ఒక అభ్యర్థనను ఒక కీ మరియు దాని ప్రచురిత identifierతో అనుసంధానిస్తుంది. ఆ క్లయింట్ ఒక చర్యను చేయగలదా లేదా అనేది మీ అప్లికేషన్ తీసుకునే వేరు authorization నిర్ణయం.

తమ అభ్యర్థనలపై సంతకం చేయని ఆటోమేటెడ్ క్లయింట్ల గురించి ఏమిటి?

Proof of Actor అందుబాటులో ఉన్న చోట ప్రకటించిన మరియు ఊహించిన ఆధారాలను ఉపయోగించి వాటిని కూడా వర్గీకరిస్తుంది, అలాగే ఆధారం తగినంత బలంగా లేనప్పుడు Unknownని నివేదిస్తుంది. ప్రతి ఫలితం తన ఆధారాన్ని పేర్కొంటుంది.

user-agent string ఒక క్లయింట్‌ను ధృవీకరించగలదా?

లేదు. user-agent stringsను సులభంగా అనుకరించవచ్చు, కాబట్టి అవి verification కాదు, ఒక declaration గా మాత్రమే పరిగణించబడతాయి. క్రిప్టోగ్రాఫిక్ సంతకాలే ఒక అభ్యర్థనను verifiable గా చేస్తాయి.

నేను ఎలా ప్రారంభించాలి?

ముందస్తు ప్రవేశం కోసం దరఖాస్తు చేయండి. Founding teams observation modeలో ప్రారంభిస్తాయి, మరియు ఎంపికైన teams అంగీకరించిన usage limits లోపల 12 నెలల వరకు ఉచితంగా పొందగలవు.

మీ app ను ఎవరు ఉపయోగిస్తున్నారో తెలుసుకోండి.

founding developers యొక్క చిన్న group కోసం private beta.

తొందరగా యాక్సెస్ పొందండి ధరలను చూడండి

ముందుగా మాట్లాడాలనుకుంటున్నారా? foundersతో మాట్లాడండి