మీరు ఈరోజు ఉపయోగిస్తున్న ప్రతి సాఫ్ట్వేర్ ఒకే ఒక ఊహ (assumption) ఆధారంగా నిర్మించబడింది. స్క్రీన్ ముందు వేళ్లతో ఉన్న ఒక వ్యక్తి కూర్చుని ఉంటాడని దీని అర్థం. బటన్లు ఉద్దేశాన్ని (intent) సూచిస్తాయి. విజార్డ్స్ (Wizards) సంక్లిష్టతను నిర్వహిస్తాయి. ఫారమ్లు మానవ ఆలోచనకు ఒక రూపాన్ని ఇస్తాయి. ఇటీవలి వరకు కేవలం మనుషులు మాత్రమే క్లిక్ చేసేవారు కాబట్టి, ఈ ఆర్కిటెక్చర్ దశాబ్దాలుగా ప్రొడక్ట్ డిజైన్ను శాసిస్తోంది.
ఆ ఊహ ఇప్పుడు చెడిపోయింది. AI ఏజెంట్లు ఇంటర్ఫేస్లను చదవవు. అవి ఉపయోగకరమైన టూల్టిప్స్ (tooltips) లేదా కన్ఫర్మేషన్ డైలాగ్ల వల్ల ప్రయోజనం పొందవు. ఒక స్వయంప్రతిపత్తి కలిగిన వ్యవస్థ (autonomous system) వినియోగదారుడి తరపున పనిచేయాల్సి వచ్చినప్పుడు, గ్రాఫికల్ అంశాలు (chrome) అడ్డుగా మారుతాయి. దీని ఫలితంగా, ప్రొడక్ట్లు ఎలా నిర్మించబడ్డాయి మరియు ఆధునిక కాలర్ల (callers) ప్రవర్తన ఎలా ఉంది అనే అంశాల మధ్య వ్యత్యాసం పెరుగుతోంది.
క్లిక్ పారాడైమ్
సాంప్రదాయ సాఫ్ట్వేర్ ఒక విజువల్ కాంట్రాక్ట్పై ఆధారపడి ఉంటుంది. ఒక మనిషి బటన్ను చూసి, దాని లేబుల్ను అర్థం చేసుకుని, దానిని నొక్కాలా వద్దా అని నిర్ణయించుకుంటాడు. వర్క్ఫ్లోలలో కావాలనే కొన్ని అడ్డంకులు (friction) ఉంచుతారు. మనుషులు తప్పులు చేసే అవకాశం ఉన్నందున మరియు వారికి రక్షణ కవచాలు (guardrails) అవసరమైనందున మల్టీ-స్టెప్ విజార్డ్స్ ఉంటాయి. ఫ్రీఫామ్ టెక్స్ట్ వల్ల గందరగోళం ఏర్పడకుండా ఉండటానికి డ్రాప్డౌన్లు మరియు రేడియో బటన్లు ఇన్పుట్ను పరిమితం చేస్తాయి.
ఆపరేటర్ ఒక మనిషి అయినప్పుడు ఇది బాగా పనిచేస్తుంది. కానీ ఆపరేటర్ ఒక ఏజెంట్ అయినప్పుడు ఇది విఫలమవుతుంది. సబ్స్క్రిప్షన్ను రద్దు చేయడానికి లేదా రికార్డును సవరించడానికి మెషీన్కు ఐదు దశల విజార్డ్ అవసరం లేదు. దానికి ఏ ఆపరేషన్లు అందుబాటులో ఉన్నాయనే స్పష్టమైన వివరణ మరియు వాటిని నిర్వహించడానికి అనుమతి ఉందో లేదో తెలిపే ఖచ్చితమైన సమాధానం కావాలి. టీమ్లు దీనిని విస్మరించినప్పుడు, వారు సాధారణంగా రెండు షార్ట్కట్లను ఎంచుకుంటారు.
మొదటిది, వారు ఏజెంట్కు ఒక API కీని అందిస్తారు. రెండవది, ఉన్న యూజర్ ఇంటర్ఫేస్ను ఒక చాట్బాట్ లోపల ఉంచి, ఇంటిగ్రేషన్ పూర్తయిందని భావిస్తారు. ఈ రెండు పద్ధతులు అసలు సమస్యను పరిష్కరించవు.
API కీ "ఈ రిక్వెస్ట్ నమ్మదగిన మూలం నుండి వచ్చిందా?" అనే ప్రశ్నకు సమాధానం ఇస్తుంది. కానీ "ఈ నిర్దిష్ట కాలర్ ఈ నిర్దిష్ట రికార్డును చదవగలడా?" అనే ముఖ్యమైన ప్రశ్నకు అది ఎప్పటికీ సమాధానం చెప్పదు. కీ అనేది ఒక స్కెలిటన్ కీ (skeleton key) వంటిది. అది ఒకసారి ఇస్తే, సాధారణంగా అన్ని వనరులు మరియు సందర్భాలలో విస్తృతమైన యాక్సెస్ను అందిస్తుంది. మీ సిస్టమ్లోని వ్యక్తిగత చర్యలను నియంత్రించే పాలసీ గురించి దానికి ఏమీ తెలియదు.
ఒక GUIని చాట్బాట్లో ఉంచడం ఇంకా ప్రమాదకరమైనది. ఇంటర్ఫేస్లో ఉన్న ప్రతి మానవ-కేంద్రీకృత ఊహను ఏజెంట్ కూడా స్వీకరిస్తుంది. అది స్వయంప్రతిపత్తి కలిగిన లాజిక్ కోసం కాకుండా, కేవలం చూడటానికి రూపొందించిన మోడల్స్ మరియు ఫారమ్ల ద్వారా క్లిక్లను అనుకరిస్తుంది (simulates). చాట్బాట్ గ్రాఫికల్ అంశాలను విజయవంతంగా నావిగేట్ చేయవచ్చు, కానీ అది అవగాహన లేకుండా చేస్తుంది. ఇది కేవలం ఒక "ఆటోమేషన్ థియేటర్" మాత్రమే. లోపల, ఏది అనుమతించబడింది అనే దాని గురించి మెషీన్-రీడబుల్ కాంట్రాక్ట్ ఇంకా ఏదీ ఉండదు.
ఏజెంట్లకు కావాల్సింది ముందు తలుపుకు మరో కీ కాదు. వాటికి గేట్లు (gates) కావాలి.
గేట్లు నిజంగా ఏమి చేస్తాయి
గేట్ అనేది ఒక నియంత్రిత ఎగ్జిక్యూషన్ లేయర్ (governed execution layer). ఒక క్రెడెన్షియల్ను నమ్మి, కాలర్ సరిగ్గా ప్రవర్తిస్తాడని ఆశించే బదులు, గేట్లు ఉన్న వ్యవస్థ ప్రతి రిక్వెస్ట్ను ప్రకటించిన నియమాలతో పోల్చి అంచనా వేస్తుంది. ఈ నియమాలు ఏ ఇంటర్ఫేస్తో సంబంధం లేకుండా స్వతంత్రంగా ఉంటాయి.
ఒక సరైన గేట్ నాలుగు అంశాలను నిర్వచిస్తుంది. ప్రొడక్ట్లో ఏ చర్యలు ఉన్నాయో అది ప్రకటిస్తుంది. ఏ పరిస్థితుల్లో ఎవరు వాటిని పిలవవచ్చో (invoke) తెలియజేస్తుంది. సైడ్ ఎఫెక్ట్స్ (side effects) కలిగించే ముందు కాలర్ ఎప్పుడు ఆగి స్పష్టమైన అనుమతి కోరాలి అనే దానిని నిర్దేశిస్తుంది. మరియు సిస్టమ్ ప్రతి నిర్ణయాన్ని ఒక నిర్మాణాత్మకమైన, క్వెరీ చేయగల (queriable) లాగ్లో నమోదు చేసేలా చేస్తుంది.
ఇది సాంప్రదాయ యాక్సెస్ కంట్రోల్ కంటే ప్రాథమికంగా భిన్నమైనది. రోల్-బేస్డ్ (Role-based) వ్యవస్థలు తరచుగా తలుపు వద్ద "మీరు అడ్మిన్ ఆ?" అని అడిగి, ఆపై మిమ్మల్ని భవనమంతా తిరగనిస్తాయి. గేట్లు ప్రతి మలుపు వద్ద "మీరు ఇప్పుడు ఈ నిర్దిష్ట స్విచ్ను ఆన్ చేయడానికి అనుమతి కలిగి ఉన్నారా?" అని అడుగుతాయి. ఇక్కడ ప్రవర్తన కంటే గుర్తింపు (identity) ద్వితీయ ప్రాధాన్యతగా మారుతుంది. పాలసీ అనేది చర్యతో పాటు ప్రయాణిస్తుంది.
దీనిని స్పష్టంగా అర్థం చేసుకోవడానికి, ఒక కస్టమర్కు రీఫండ్ చేయాల్సిన ఏజెంట్ను ఊహించుకోండి. కీ-బేస్డ్ విధానంలో, ఎండ్పాయింట్ అందుబాటులో ఉంటే, కీ ఉన్న ఎవరైనా రీఫండ్ను ప్రాసెస్ చేయవచ్చు. కానీ గేట్-బేస్డ్ విధానం అందుబాటులో ఉన్న చర్యల జాబితాను (manifest) తనిఖీ చేస్తుంది, నిర్దిష్ట కస్టమర్ రికార్డుతో పోలి ఏజెంట్ అనుమతిని ధృవీకరిస్తుంది, ఆర్థిక సైడ్ ఎఫెక్ట్ కోసం వినియోగదారుడి నుండి స్పష్టమైన అనుమతిని కోరుతుంది మరియు మొత్తం ప్రక్రియను ఆడిట్ లాగ్లో నమోదు చేస్తుంది. గేట్ కేవలం గుర్తింపును మాత్రమే కాకుండా, పాలసీని అమలు చేస్తుంది.
దీనిని Whistler పై పరీక్షించడం
మేము ఈ మోడల్ను Whistler పై అమలు చేశాము. మనుషులు మరియు మెషీన్ల కోసం విడివిడి పైప్లైన్లను నిర్మించే బదులు, మేము ఒకే పాలసీ లేయర్ను రాసి, దానిపై రెండు వేర్వేరు కాలర్లను పరీక్షించాము.
ఒక కాలర్ ఎంబెడెడ్ Shell ఉపయోగిస్తున్న మనిషి. మరొకరు మా టీమ్ వెలుపల అభివృద్ధి చేయబడిన థర్డ్-పార్టీ ఏజెంట్. రెండూ ఒకే మానిఫెస్ట్కు కనెక్ట్ అయ్యాయి. రెండూ ప్రతి దశలోనూ ఒకే రకమైన పర్మిషన్ చెక్లను ఎదుర్కొన్నాయి. డేటాను సవరించడం లేదా బాహ్య ఈవెంట్ను ట్రిగ్గర్ చేయడం వంటి సైడ్ ఎఫెక్ట్స్ ఉన్న చర్యను ఏ కాలర్ చేసినా, సిస్టమ్ స్పష్టమైన అనుమతిని కోరింది. ప్రతి రిక్వెస్ట్, అనుమతి మరియు తిరస్కరణ ఒకే రకమైన నిర్మాణాత్మక ఆడిట్ ట్రైల్ను రూపొందించాయి.
Neither caller used a master API key. There was no backdoor, no elevated credential that bypassed the policy. The human did not receive looser restrictions because they had a password and a browser. The agent did not face arbitrary blocks because it lacked a human fingerprint. The gate evaluated the action, the context, and the rules. That was the entire transaction.
The result was a system where adding a new caller, human or machine, required no refactoring of access logic. You updated the policy. The gate enforced it.
ఉత్పత్తి ప్రశ్నను పునరాలోచించడం
మీ బృందం ప్రస్తుతం మనుషులు రూపొందించిన ఉత్పత్తికి AI ఏజెంట్లను ఎలా జోడించాలో ఆలోచిస్తుంటే, మీరు బహుశా తప్పు ప్రశ్నతో ప్రారంభిస్తున్నారు. బృందాలు సహజంగానే ఒక APIని ఎక్స్పోజ్ చేయాలా వద్దా అని అడుగుతాయి. దానికి బదులుగా, ప్రతి కాల్ చేసేవారికి నియంత్రిత ఎగ్జిక్యూషన్ లేయర్ (governed execution layer) ఉందా లేదా అని వారు అడగాలి.
గేట్ లేని API కేవలం ఒక వెడల్పాటి తలుపు మాత్రమే. మీ అంతర్గత పాలసీలు కేవలం విజార్డ్ లాజిక్, ఫారమ్ వాలిడేషన్ మరియు మనుషులు చదవగలిగే హెల్ప్ టెక్స్ట్ లో మాత్రమే ఉంటే, మీరు ప్రచురించే ఏ ఎండ్పాయింట్ కూడా స్వయంప్రతిపత్తి కలిగిన (autonomous) కాల్ చేసేవారికి సురక్షితంగా ఉండదు. ఏజెంట్ ఒక కీ ద్వారా అతిగా నమ్మకాన్ని పొందుతుంది లేదా చాట్బాట్ రాపర్ ద్వారా బలహీనమైన పప్పెట్రీ (brittle puppetry) చేస్తుంది.
మొదట గేట్లను నిర్మించడం అంటే మీ ఉత్పత్తిలోని ప్రతి అర్థవంతమైన చర్యను ఒక డిక్లేర్డ్ ఆపరేషన్గా జాబితా చేయడం. అంటే పర్మిషన్ చెక్ను యూజర్ ఇంటర్ఫేస్ నుండి వేరు చేయడం, తద్వారా షెల్ యూజర్ మరియు బాహ్య ఏజెంట్ ఇద్దరూ ఒకే రకమైన రన్టైమ్ ఎన్ఫోర్స్మెంట్ను ఎదుర్కొంటారు. అంటే డేటాసెట్ను ఏజెంట్ తుడిచివేయడానికి ముందే, విధ్వంసకర చర్యల (destructive operations) కోసం కన్సెంట్ హుక్స్ను (consent hooks) చేర్చడం. మరియు కాల్ చేసే వ్యక్తి కార్బన్ (మనిషి) లేదా సిలికాన్ (యంత్రం) అనే తేడా లేకుండా సెక్యూరిటీ మరియు కంప్లయన్స్ టీమ్లు తనిఖీ చేయగలిగే ఆడిట్ ట్రైల్స్ను రూపొందించడం.
దీనికి నిజమైన ఆర్కిటెక్చరల్ మార్పు అవసరం. హ్యూమన్-సెంట్రిక్ డిజైన్ లాజిక్ను సానుభూతి మరియు ఘర్షణతో (empathy and friction) చుట్టి ఉంచుతుంది. ఏజెంట్-రెడీ డిజైన్ స్పష్టమైన, మెషిన్-రీడబుల్ కాంట్రాక్టుల ద్వారా లాజిక్ను బయటపెడుతుంది. ఇంటర్ఫేస్ అనేది పాలసీగా ఉండటం ఆగిపోతుంది. మేనిఫెస్ట్ (manifest) పాలసీగా మారుతుంది.
ఈ మార్పు మనుషులను భర్తీ చేయడం గురించి కాదు. మీ సాఫ్ట్వేర్కు ఇప్పుడు ఒకటి కంటే ఎక్కువ రకాల కాల్ చేసేవారు ఉన్నారని గుర్తించడం గురించి. ప్రతి ఒక్కరూ ఒకే విధమైన కఠినత్వాన్ని (rigor) పొందడానికి అర్హులు.
అసలైన సారాంశం
క్లిక్ కోసం డిజైన్ చేయడం ఆపండి. నియమం (rule) కోసం డిజైన్ చేయడం ప్రారంభించండి. మీ వ్యవస్థ ప్రతి కాల్ చేసేవారిని డిక్లేర్డ్ యాక్షన్స్, కాంటెక్స్చువల్ పర్మిషన్స్, కన్సెంట్ చెక్స్ మరియు షేర్డ్ ఆడిట్ ట్రైల్స్ ద్వారా నియంత్రించగలిగితే, అవతలి వైపు ఎవరు లేదా ఏది ఉన్నా పర్వాలేదు. మనిషి అయినా లేదా ఏజెంట్ అయినా, వారందరూ ఒకే గేట్ను ఎదుర్కొంటారు. మొదట గేట్ను నిర్మించండి. API కేవలం ఒక తలుపు మాత్రమే. పాలసీ మాత్రమే గదిని సురక్షితంగా ఉంచుతుంది.