మీ APIకి కీ తెలుసు. actor తెలియదు.
ప్రతి API అభ్యర్థన దానికి ఎవరు చెల్లిస్తున్నారో కొంత ఆధారంతో వస్తుంది: ఒక API key, ఒక OAuth token, ఒక session. ఆ ఆధారం ఒక ప్రశ్నకు బాగా సమాధానం ఇస్తుంది. కాల్కు బాధ్యత వహిస్తున్న ఖాతా ఏదో చెబుతుంది. కానీ ప్రస్తుతం ఆ కాల్ను నిజంగా చేస్తున్నది ఏమిటో చెప్పదు.
ఒకే API keyను టెర్మినల్లో పరీక్షిస్తున్న developer, షెడ్యూల్ ప్రకారం నడుస్తున్న backend job, AI assistant ద్వారా పని చేస్తున్న వ్యక్తి, మరియు task పూర్తి చేయమని కీ ఇచ్చిన autonomous agent ఉపయోగించగలరు. ఇవి చాలా భిన్నమైన actors. వాటికి వేర్వేరు rhythms, వేర్వేరు failure modes, వేర్వేరు risk profiles ఉంటాయి. అందరినీ ఒకే విధంగా చూడటం వల్ల, మీ customers ఆధారపడే legitimate automationను మీరు అతిగా పరిమితం చేస్తారు, లేదా unattended agent చేత నడిపించకూడని మీ API భాగాలను తక్కువగా రక్షిస్తారు.
APIల కోసం AI agent identification ఆ అంతరాన్ని మూసివేస్తుంది. కీ నుంచే అన్నింటినీ ఊహించడంకు బదులు, ప్రతి అభ్యర్థన వెనుక ఉన్న actor వర్గీకరణను, దానికి మద్దతిచ్చే ఆధారంతో పాటు పొందుతారు. అదే Proof of Actor అందించడానికి రూపొందించబడింది, మరియు APIs use case API బృందాలు దాన్ని route వారీగా ఎలా ఉపయోగిస్తారో చూపుతుంది.
ఇప్పుడు API బృందాలకు actor context ఎందుకు అవసరం
APIలకు ఆటోమేటెడ్ ట్రాఫిక్ కొత్తది కాదు. scripts, integrations మరియు crawlers ఎప్పటినుంచో దృశ్యంలో భాగమే. మారింది automation రకం. AI agents డాక్యుమెంటేషన్ చదవగలరు, callsను వరుసగా కలపగలరు, సృజనాత్మకంగా retry చేయగలరు, మరియు ప్రతి దశను చూస్తూ ఉండని వ్యక్తుల తరఫున పని చేయగలరు. వాటిలో చాలా ఉపయోగకరమైనవి, స్వాగతించదగినవి. కొన్ని సరిగా నిర్మించబడలేదు. కొన్ని శత్రుత్వపూరితమైనవి.
actor context లేకుండా, API బృందాలు సాధారణంగా కఠినమైన సాధనాల వైపు వెళ్తాయి:
- ప్రతి keyకి rate limits, ఇవి మంచి agentsను, చెడు agentsను సమానంగా మందగిస్తాయి.
- user-agent నియమాలు, ఇవి client header మార్చగానే పనిచేయడం ఆగిపోతాయి.
- వ్యాప్తమైన blocks, ఇవి legit automationను మీ web app నుంచే scrape చేయ도록 నెట్టేస్తాయి.
actor context మీకు ఖచ్చితంగా స్పందించే అవకాశాన్ని ఇస్తుంది. మీరు గుర్తించే operator నుంచి వచ్చిన signed agentకు చదవడానికి మాత్రమే ఉన్న routesపై ఎక్కువ limit ఇవ్వవచ్చు. write routeను తాకుతున్న unknown callerను బలమైన credential కోసం అడగవచ్చు. AI assistant ఉపయోగిస్తున్న మనిషికి సాధారణ అనుభవం కొనసాగించవచ్చు. agentsను ఆపడం లక్ష్యం కాదు. ప్రతి రకమైన callerకు సరైన మార్గం ఇవ్వడమే లక్ష్యం. signed request మీకు ఏమి చెబుతుంది, ఏమి చెప్పదు అన్నది తెలుసుకోవడానికి what signed AI agent requests prove చదవండి.
Proof of Actorలో AI agent identification ఎలా పనిచేస్తుంది
Proof of Actor ప్రతి అభ్యర్థనకూ అదే evidence-first flowను అనుసరిస్తుంది. పూర్తి walkthroughను How It Worksలో చదవవచ్చు; ఇక్కడ API బృందాల కోసం చిన్న రూపం.
1. మీ integration నుంచి signals
మీ integration ఆ సందర్భంలో అందుబాటులో ఉన్న signalsను Proof of Actorకు ఇస్తుంది. API కోసం, సాధారణంగా headers మరియు protocol వివరాల వంటి request context, client అందించే cryptographic request signatures, మరియు client తన గురించి చేసే declarations ఇందులో ఉంటాయి. ప్రతి signal అది ఎక్కడి నుంచి వచ్చిందో లేబుల్ చేస్తారు.
2. ఆధారంతో classification
signalsను తనిఖీ చేసి కలిపి నాలుగు public classesలో ఒకటిగా మారుస్తారు:
- Human: కనిపించే signals మానవ-నిర్దేశిత పరస్పర చర్యను సూచిస్తాయి.
- Human + AI: AI సహాయం ప్రకటించబడింది లేదా దాన్ని గమనించగల integration ద్వారా గుర్తించబడింది.
- Agent: ఆటోమేటెడ్ లేదా agent-origin ట్రాఫిక్, ధృవీకరించదగిన identity లేదా జాగ్రత్తగా పరిమితమైన inferenceతో మద్దతు పొందింది.
- Unknown: evidence నమ్మదగిన నిర్ణయాన్ని మద్దతు ఇవ్వదు.
ప్రతి ఫలితంతో పాటు దాని basis కూడా వస్తుంది: verified, declared, inferred లేదా unknown. API బృందాలు ఎక్కువగా విలువ చేసే భాగం ఇదే. HTTP message signature, RFC 9421లో నిర్వచించబడినట్లుగా, ప్రచురిత keyతో ధృవీకరించబడితే ఫలితం verifiedగా నివేదించబడుతుంది. తాను agent అని మాత్రమే చెప్పుకునే client declaredగా నివేదించబడుతుంది. ఆటోమేటెడ్గా కనిపించే pattern inferredగా నివేదించబడుతుంది. ఫలితం cryptographyపై ఆధారపడిందా లేదా heuristicపై ఆధారపడిందా అని మీరు ఎప్పుడూ అనుమానించాల్సిన అవసరం లేదు. evidence basis సమాధానంలో భాగం.
3. మీ code చర్య తీసుకోగల ఫలితం
ఫలితం class, basis మరియు చదవగల evidence summaryతో మీ applicationకు తిరిగి వస్తుంది. దానితో ఏమి చేయాలో మీ code నిర్ణయిస్తుంది. observation modeలో, మీరు దాన్ని కేవలం నమోదు చేస్తారు. సిద్ధమైనప్పుడు, దానిపై route చేస్తారు.
మీ బృందానికి లభించేవి: Detect, Understand, Route
Proof of Actor మూడు సామర్థ్యాలతో ఉన్న ఒకే product.
Detect
మీ API చూడగల actor signalsను సేకరించి, verified assertionsను behavioural inferences నుండి వేరు చేయండి. signed agent requests, declared clients, automation signals మరియు Unknown ఫలితాలు అన్నీ వేరుగా ఉంచబడతాయి, కాబట్టి ఏదీ నిశ్శబ్దంగా ఒకే scoreలో కలిసిపోదు.
Understand
ఏ actors ఏ routesను పిలుస్తున్నాయో, అది కాలక్రమేణా ఎలా మారుతోందో, ప్రతి classification వెనుక ఏ evidence ఉందో చూడండి. unknown rate కనిపించేలా ఉంటుంది, కాబట్టి మీ coverage ఎక్కడ ముగుస్తుందో, ఎక్కడ బలమైన signal ఉపయోగపడుతుందో మీకు స్పష్టంగా తెలుస్తుంది.
Route
ప్రతి route మరియు ప్రతి risk tier కోసం policies రాయండి: allow, adapt, challenge, review లేదా rate-limit. read-only endpointsపై verified agentsకు నిర్మితమైన, ఉదారమైన మార్గాన్ని ఉంచండి. అధిక ప్రభావం ఉన్న operationsపై బలమైన credentials అడగండి. Unknown మరియు timeouts కోసం స్పష్టమైన fallbackను నిర్వచించండి, తద్వారా ఏం జరిగినా మీ API అంచనాత్మకంగా ప్రవర్తిస్తుంది. ఆ routeలో పొరపాటు ఖర్చు ఎంత అన్నదాన్ని బట్టి, ప్రతి policy ఎలా విఫలమవ్వాలో మీరు నిర్ణయిస్తారు: open లేదా closed.
identity evidence, credentials మరియు authorization మూడు వేర్వేరు విషయాలు
agent-aware API designలో అత్యంత సాధారణ తప్పు మూడు వేర్వేరు ప్రశ్నలను ఒకటిగా కలపడం. Proof of Actor వాటిని వేరు ఉంచుతుంది, మీ design కూడా అలాగే ఉండాలి.
- identity evidence: ఏ రకమైన actor పిలుస్తోంది, దాన్ని ఏమి నిరూపిస్తుంది? ఇదే AI agent identification అందిస్తుంది. ఒక verified signature, requestను ఒక key మరియు దాని ప్రచురిత operator identifierతో అనుసంధానిస్తుంది. IETF Web Bot Auth working group ఆటోమేటెడ్ clients కోసం ఈ రకమైన cryptographic authenticationను standardize చేయడానికి charter చేయబడింది, మరియు దాని scope end user కాదు, agentని authenticate చేయడాన్ని కవర్ చేస్తుంది.
- credentials: ఈ callకు బాధ్యత వహించే ఖాతా ఏది? ఇది మీరు జారీ చేసి నిర్వహించే మీ API key, token లేదా session.
- authorization: ఈ callerకి ఈ నిర్దిష్ట పని చేయడానికి అనుమతి ఉందా? ఇది మీ permission model.
verified agent ఆటోమేటిక్గా authorized agent కాదు. valid signature, ఒక person agentకు authority అప్పగించాడని రుజువు చేయదు, మరియు కోరిన చర్య సురక్షితమని కూడా చెప్పదు. Proof of Actor మొదటి ప్రశ్నకు నమ్మదగిన context ఇస్తుంది, రెండవ మరియు మూడవ ప్రశ్నలను అవి ఉండాల్సిన చోటే ఉంచుతుంది: మీ applicationలో. agent authorization గురించి, మరియు evidence ఏమి స్థాపించగలదు ఏమి స్థాపించలేదో తెలుసుకోవడానికి Detection & Limitations చదవండి.
Unknown ఒక feature, failure కాదు
Request signing ఐచ్ఛికం, మరియు unsigned client తనను తాను ఏ విధంగా కావాలంటే అలా వర్ణించుకోవచ్చు. ప్రతి అభ్యర్థనను Human లేదా Agentగా బలవంతంగా మార్చే system, కొన్నిసార్లు నిశ్చయంగా తప్పుగా ఉంటుంది, మరియు ఎప్పుడు తప్పో మీకు తెలియదు.
Evidence నిర్ణయాన్ని మద్దతు ఇవ్వనప్పుడు Proof of Actor Unknownను నివేదిస్తుంది. Unknownను ఎప్పుడూ Humanగా మార్చరు, defaultగా maliciousగా కూడా పరిగణించరు. మీ policy ప్రతి route కోసం Unknown అర్థం ఏమిటో నిర్వచిస్తుంది: public readsపై అనుమతించండి, account changesపై మీ existing checks కొనసాగించండి, stakes ఎక్కువ ఉన్న చోట reviewకి queue చేయండి. Unknown కనిపించేలా ఉంచడమే మీ ఇతర classifications నమ్మదగినవిగా మారే కారణం. handling unknown trafficపై guide దీని కోసం ఎలా design చేయాలో చూపుతుంది.
మీ stackలో AI agent identification ఎక్కడ సరిపోతుంది
Proof of Actor మీ existing gateway, authentication మరియు rate limitingతో పాటు పనిచేస్తుంది. వాటిలో దేనినీ భర్తీ చేయదు. సాధారణ placements ఇవి:
- Server-side middleware, మీ route handlers ముందు, కాబట్టి business logic నడిచే ముందు ప్రతి అభ్యర్థనను పరిశీలిస్తారు.
- At the edge, కాబట్టి అభ్యర్థనలు originకి చేరేముందే signalsను evaluate చేస్తారు.
- సాధారణ HTTP integration, కాబట్టి ఏ stack అయినా request context పంపి, basisతో కూడిన ఫలితాన్ని పొందగలదు.
Onboarding సమయంలో founding teamతో hands-onగా integrations అందిస్తారు, కాబట్టి మార్గం మీ architectureకి సరిపోతుంది, వ్యతిరేకంగా కాదు. developer hub ప్రస్తుతం అందుబాటులో ఉన్న integration pathsను చూపుతుంది. మీరు agents కోసం tools నడిపితే, MCP Servers use case tool calls కోసం నిర్దిష్ట patternsను కవర్ చేస్తుంది.
observation modeలో ప్రారంభించండి
Proof of Actorని ఇన్స్టాల్ చేయడం వల్ల మీ API స్పందించే తీరు మారదు. ఫలితాలు నమోదు చేయబడతాయి, కాబట్టి మీ బృందం వాటిని మీకు ఇప్పటికే తెలిసిన outcomesతో పోల్చవచ్చు, agents నిజంగా ఎక్కడికి వెళ్తున్నాయో చూడవచ్చు, ప్రతి routeపై unknown rateని కొలవవచ్చు, మరియు తప్పుగా కనిపించే ఏ classificationనైనా సమీక్షించవచ్చు. ఆ తర్వాతే, evidence మద్దతు ఇస్తే, route వారీగా policyని ప్రారంభిస్తారు.
ఇలా చేయడం వల్ల మీ customersకు ఆశ్చర్యం కలగకుండా, లేదా వారు ఆధారపడే integrations చెడిపోకుండా AI agent identificationను roll out చేయవచ్చు. rolling out actor-aware policies safelyపై guide దశల వారీగా sequenceను వివరిస్తుంది.
founding developer programలో చేరండి
Proof of Actor, founding development teams చిన్న సమూహంతో private betaలో ఉంది. ఎంపికైన బృందాలకు onboarding సమయంలో అంగీకరించిన usage limitsలో 12 నెలల వరకు ఉచిత access, మా engineers నుండి ప్రత్యక్ష integration support, మరియు మేము తర్వాత ఏమి నిర్మించాలో నిజమైన ప్రభావం లభించవచ్చు.
మీరు ఒక APIని నిర్వహిస్తూ అది నిజంగా ఎవరు పిలుస్తున్నారో తెలుసుకోవాలనుకుంటే, apply for early access. మీ API గురించి, మీకు అత్యంత ముఖ్యమైన routes గురించి, మరియు actor contextతో మీరు భిన్నంగా తీసుకునే నిర్ణయాల గురించి మాకు చెప్పండి. Proof of Actor మీకు ఎలా సరిపోతుందో మేము చెబుతాము.
మూలాలు
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.