ప్రతినియోగ అధికారం అంటే ఏమిటి
ప్రతినియోగ అధికారం అంటే ఒక వ్యక్తి (లేదా ఒక సంస్థ) ఒక AI agent కు తమ తరఫున పని చేయడానికి ఇచ్చే అనుమతి. ఒక assistant మీ calendar లో meeting book చేసినప్పుడు, మీ పేరుతో support ticket దాఖలు చేసినప్పుడు, లేదా supplier's portal నుండి invoice తీసుకున్నప్పుడు, అది మీ నుంచే వచ్చిన అధికారాన్ని వినియోగిస్తోంది.
మంచి ప్రతినియోగానికి మూడు లక్షణాలు ఉంటాయి: అది పరిమిత పరిధి గలది (agent కొన్ని పనులు మాత్రమే చేయగలదు, అన్నీ కాదు), కాల పరిమితిగలది (దాని గడువు ముగుస్తుంది లేదా రద్దు చేయవచ్చు) మరియు కేటాయించదగినది (అది స్వీకరించే application ఎవరి అధికారం వినియోగంలో ఉందో చెప్పగలగాలి).
apps కు ఇది ఎందుకు ముఖ్యమైనది
ఒక application దృష్టిలో, agent request మూడు వేర్వేరు ప్రశ్నలను లేవనెత్తుతుంది:
- ఇది ఏ client పంపింది? అది agent identity. signed requests దీన్ని నిర్ధారించగలవు (చూడండి HTTP Message Signatures).
- ఇది ఎవరి అధికారం కింద పని చేస్తోంది? అది delegation.
- ఈ చర్యకు ఆ అధికారం సరిపోతుందా? అది authorization, application యొక్క స్వంత policy నిర్ణయిస్తుంది.
ఒక well-known assistant operator నుండి వచ్చిన signed request మొదటి ప్రశ్నకు బాగా సమాధానం ఇస్తుంది. కానీ అది రెండో ప్రశ్న గురించి స్వయంగా ఏమీ చెప్పదు. ఆ assistant మీ users లో ఒకరి కోసం, మీ user కాని ఎవరో ఒకరి కోసం, లేదా పూర్తిగా తనంతట తానే పని చేస్తుండవచ్చు. client identity ని ఒక వ్యక్తి consent కు proof గా భావించడం agent-facing design లో అత్యంత సాధారణ తప్పుల్లో ఒకటి. చూడండి signed AI agent requests ఏమి నిరూపిస్తాయి, ఏమి నిరూపించవు.
ప్రతినియోగం సాధారణంగా ఎలా వ్యక్తమవుతుంది
- OAuth-style grants. వ్యక్తి మీ application లో sign in చేసి, OAuth 2.0 (RFC 6749) లో నిర్వచించినట్లుగా, పరిమిత scopes ఉన్న token ను ఒక agent కు ఇస్తారు. అప్పుడు మీ application కు ఆ token ఏ అధికారం కలిగి ఉందో ఖచ్చితంగా తెలుస్తుంది, మరియు ఆ grant ను రద్దు చేయవచ్చు (RFC 7009).
- ఖాతా-పరిధి API keys - ఒక user నిర్దిష్ట integration కోసం సృష్టించే keys, వీలైనంత సంకుచిత permissions తో.
- అధిక ప్రభావం ఉన్న చర్యల కోసం in-app నిర్ధారణలు, అక్కడ వ్యక్తి agent సిద్ధం చేసిన నిర్దిష్ట చర్యను ఆమోదిస్తారు.
- token స్థాయి delegation claims. OAuth 2.0 Token Exchange (RFC 8693) ఒక
act(actor) claim ను నిర్వచిస్తుంది, ఇది ఒక పక్షం మరొక పక్షం తరఫున పని చేస్తున్నదని నమోదు చేస్తుంది. requests లో agent delegation ను వ్యక్తపరచే కొత్త పని ఇంకా అభివృద్ధి దశలో ఉంది, కాబట్టి applications ఏ delegation claim అయినా తమ స్వంత records తో సరిపోల్చి ధృవీకరించాలి, కేవలం ముఖ విలువపై అంగీకరించకూడదు.
సాధారణ అపోహలు
- "agent verified అయితే, user దాన్ని ఆమోదించినట్టే." Verification client ను గుర్తిస్తుంది. Approval అయితే మీ application నమ్మే channel ద్వారా వ్యక్తి నుంచే రావాలి.
- "నా user's session ను agent ఉపయోగిస్తే సరిపోతుంది." అలా ఉండొచ్చు, కానీ session interactive human use కోసం జారీ చేయబడింది. అనేక applications automation కోసం ప్రత్యేకమైన, పరిమిత grant ను ఇష్టపడతాయి, అలా చేస్తే చర్యలు కేటాయించదగినవిగా మరియు రద్దు చేయదగినవిగా ఉంటాయి.
- "Delegation అన్నీ లేదా ఏమీ కాదు." అత్యంత భద్రమైన delegations సంకుచితంగా ఉంటాయి: విస్తృతంగా read access, నిర్దిష్ట చర్యలకే write access, మరియు తిరిగి మార్చలేని ఏదైనా కోసం confirmation.
Proof of Actor దీనితో ఎలా సంబంధం కలిగి ఉంటుంది
ఒక interaction agent-driven గా ఉందా లేదా AI-assisted గా ఉందా, మరియు ఏ ఆధారంపై ఉందా - verified, declared, inferred లేదా unknown - అనే విషయాన్ని Proof of Actor మీకు కనిపించేలా చేస్తుంది. ఆ context delegation ప్రశ్నలు ఎక్కడ ఉత్పన్నమవుతాయో చూపిస్తుంది, ఉదాహరణకు human account session లోపల పని చేస్తున్న autonomous agent. Proof of Actor delegation credentials ను జారీ చేయదు లేదా validate చేయదు, మరియు Agent result ఒక వ్యక్తి ఆ చర్యను ఆమోదించాడని ఎప్పుడూ సూచించదు. అది మీ application యొక్క స్వంత grants, scopes మరియు confirmations నిర్ణయిస్తాయి, మరియు Route మీరు నిజమైన traffic ను గమనించిన తర్వాత ప్రతి route కు సరైన policy ని వర్తింపజేయడానికి సహాయపడుతుంది. policy patterns కోసం, చూడండి humans మరియు AI agents కోసం app-level policies రూపకల్పన.
ఎvidence ఏమి స్థాపించగలదు, ఏమి స్థాపించలేదో చదవండి, లేదా ప్రారంభ ప్రాప్యత కోసం దరఖాస్తు చేయండి.
మూలాలు
- RFC 6749: The OAuth 2.0 Authorization Framework: resource owner నుండి client కు పరిమిత grants
- RFC 7009: OAuth 2.0 Token Revocation: delegated token ను రద్దు చేయడం
- RFC 8693: OAuth 2.0 Token Exchange: delegation కోసం
act(actor) claim