ब्राउज़र एजेंट को अपना पूरा Google खाता सौंपना क्यों खतरनाक है
TuBrief 편집팀
2026년 9월 12일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Cursor या GrokBot जैसे ब्राउज़र एजेंट अकेले काम करने वाले डेवलपर्स के लिए एक आकर्षक विकल्प हैं। वे बाहरी डैशबोर्ड की जाँच या प्रतिस्पर्धी निगरानी जैसे कामों को खुद-ब-खुद संभाल लेते हैं, जिन्हें बार-बार क्लिक करना थकाऊ होता है।
समस्या तब पैदा होती है जब इस टूल को होस्ट मशीन के ब्राउज़र सत्र से सीधे जोड़ा जाता है। अविश्वसनीय वेब पेजों को स्क्रैप करते समय यदि अप्रत्यक्ष प्रॉम्प्ट इंजेक्शन (Indirect Prompt Injection) का शिकार होना पड़े, तो लोकल स्टोरेज में बचे हुए सत्र कुकी और प्रमाणीकरण टोकन सीधे बाहरी सर्वर पर लीक हो जाते हैं। इसके अलावा, यदि एजेंट को DOM तत्व नहीं मिलता है और वह एक ही अनुरोध को अंतहीन रूप से दोहराना शुरू कर देता है, तो सुबह उठने पर आपको सैकड़ों डॉलर का API बिल मिल सकता है।
यह उम्मीद करना छोड़ देना चाहिए कि नेचुरल लैंग्वेज प्रॉम्प्ट अपने आप अपवादों को संभाल लेगा। रनटाइम को शारीरिक रूप से अलग रखना (physically isolate करना) और पैसे व समय की बर्बादी रोकने के लिए सुरक्षा उपाय करना कहीं अधिक सुरक्षित है।
एजेंट द्वारा उपयोग की जाने वाली ब्राउज़र प्रोफ़ाइल को आपके काम के माहौल से पूरी तरह से अलग किया जाना चाहिए। Chromium संस्करण 136 से, डिफ़ॉल्ट उपयोगकर्ता डेटा निर्देशिका (--user-data-dir) के लिए रिमोट डिबगिंग कनेक्शन अवरुद्ध कर दिए गए हैं, जिससे अलगाव के मानक और सख्त हो गए हैं।
ऑपरेटिंग सिस्टम की डिफ़ॉल्ट क्रेडेंशियल सबसिस्टम को बंद किया जाना चाहिए और ब्राउज़र को एक स्वतंत्र निर्देशिका के साथ लॉन्च किया जाना चाहिए।
`bash
google-chrome
--user-data-dir="/opt/grokbot/isolated_profiles/worker_01"
--profile-directory="AgentContext"
--disable-save-password-bubble
--disable-fill-on-account-select
--credentials_enable_service=false
--no-first-run
--no-default-browser-check
`
खाता अनुमतियों की भी समीक्षा की जानी चाहिए। Google Admin Console (admin.google.com) में सुरक्षा > एक्सेस और डेटा नियंत्रण > Google सत्र नियंत्रण पर जाएं। एक एजेंट-विशिष्ट सहायक संगठन इकाई (Agent-Sandboxed-OU) बनाएं, और वेब सत्र की अवधि को डिफ़ॉल्ट 14 दिनों से घटाकर 24 घंटे (1,440 मिनट) करके सहेजें।
भुगतान डैशबोर्ड की जाँच करते समय, पूर्ण व्यवस्थापक विशेषाधिकारों वाली गुप्त कुंजी (sk_live_...) का उपयोग करना खतरनाक है। केवल Charges: Read, Subscriptions: Read अनुमतियों वाली एक प्रतिबंधित कुंजी (rk_live_...) को अलग से निकाल कर पास किया जाना चाहिए।
| एकीकृत सेवा | अनुमत अधिकार | निषिद्ध अधिकार | इंजेक्शन विधि | अवरुद्ध जोखिम |
|---|---|---|---|---|
| Stripe | Charges: Read, Subscriptions: Read | Charges: Write, Payouts: Read/Write | rk_live_... (पर्यावरण चर) |
अनधिकृत रिफंड और सेटलमेंट खाता परिवर्तन |
| Google Workspace | gmail.readonly, drive.metadata.readonly | gmail.send, gmail.modify | Scoped OAuth 2.0 Access Token | फ़िशिंग मेल भेजना और फ़ाइल छेड़छाड़ |
| Vercel / AWS | Read-only Monitoring, Logs View | Deployments, Secrets Edit | Scoped Token / IAM Role | ऑपरेटिंग इंस्टेंस को मनमाने ढंग से समाप्त करना |
एक बार सेटिंग्स पूरी हो जाने पर, एजेंट को Stripe सेटलमेंट अकाउंट प्रबंधन पते ([https://dashboard.stripe.com/settings/payouts](https://dashboard.stripe.com/settings/payouts)) पर जाने के लिए कहें। यदि ब्राउज़र स्क्रीन पर पुनः प्रमाणीकरण विंडो दिखाई देती है या HTTP 403 त्रुटि आती है, तो अलगाव सही ढंग से सेट है।
यदि ब्राउज़र एजेंट को एक भी बटन नहीं मिलता है, तो वह प्रॉम्प्ट को थोड़ा बदलकर पिंग-पोंग लूप में चला जाता है। 128k टोकन संदर्भ के साथ दर्जनों बार पुनः प्रयास करने पर टोकन की लागत तेजी से बढ़ जाती है। प्रॉम्प्ट में सिर्फ यह लिख देना कि "विफलता पर रुक जाओ" पर्याप्त नहीं है। मॉडल अक्सर उस निर्देश को नजरअंदाज कर देते हैं।
कोड स्तर पर प्रक्रिया को जबरन समाप्त करने के लिए एक सर्किट ब्रेकर लगाया जाना चाहिए। सबसे पहले, ऑर्केस्ट्रेशल कॉन्फ़िगरेशन फ़ाइल (.cursorrules या GrokBot पर्यावरण सेटिंग्स) में पुनः प्रयास की सीमा निर्धारित करें।
`text
AGENT ORCHESTRATION CONSTRAINTS
Execution Thresholds:
MAX_RETRIES_PER_TASK = 2
PER_STEP_TIMEOUT_SECONDS = 300
DAILY_TOKEN_BUDGET_HARD_CAP_USD = 5.00
Deterministic Termination Rules:
समान DOM चयनकर्ता विफलता लगातार 2 बार दर्ज होने पर प्रक्रिया को तुरंत समाप्त कर दिया जाता है।
शब्दावली बदलकर तीसरी बार प्रयास नहीं किया जाता है।
यदि एकल सत्र की लागत $5.00 तक पहुँच जाती है, तो सभी कार्यों को तुरंत रोक दिया जाता है और एग्जिट कोड लौटा दिया जाता है।
`
पायथन स्क्रिप्ट के साथ लगातार विफलताओं की निगरानी करें, और सीमा पूरी होने पर टेलीग्राम पर लॉग भेजकर प्रक्रिया को तुरंत समाप्त करें।
`python
import os
import sys
import logging
import requests
TELEGRAM_BOT_TOKEN = os.getenv("TELEGRAM_BOT_TOKEN")
TELEGRAM_CHAT_ID = os.getenv("TELEGRAM_CHAT_ID")
class AgentCircuitBreaker:
def init(self, max_consecutive_failures=2):
self.consecutive_failures = 0
self.max_failures = max_consecutive_failures
def record_failure(self, task_name: str, error_trace: str, current_url: str):
self.consecutive_failures += 1
logging.warning(f"Task '{task_name}' failed ({self.consecutive_failures}/{self.max_failures})")
if self.consecutive_failures >= self.max_failures:
self.trigger_kill_switch(task_name, error_trace, current_url)
def record_success(self):
self.consecutive_failures = 0
def trigger_kill_switch(self, task_name: str, error_trace: str, current_url: str):
message = (
f"[CIRCUIT BREAKER TRIGGERED]\n"
f"Task: {task_name}\n"
f"URL: {current_url}\n"
f"Cause: Consecutive Failures >= {self.max_failures}\n"
f"Trace: {error_trace[:400]}"
)
api_url = f"https://api.telegram.org/bot{TELEGRAM_BOT_TOKEN}/sendMessage"
payload = {"chat_id": TELEGRAM_CHAT_ID, "text": message}
try:
requests.post(api_url, json=payload, timeout=5.0)
except Exception as e:
logging.error(f"Failed to post webhook: {e}")
sys.exit(1)
`
प्रत्येक एजेंट इंस्टेंस के लिए परीक्षण किए जाने वाले मदों की संख्या अधिकतम 50 तक सीमित करें। 50 आइटम पूरे होने पर, ब्राउज़र संदर्भ (context.close()) को पूरी तरह से हटा दें और एक नया लॉन्च करें। बैच कार्यों के बीच लगभग 60 सेकंड का विश्राम अंतराल छोड़ने से Stripe के प्रति सेकंड अनुरोध सीमा (25 req/sec) के कारण खाते को लॉक होने से बचाने में मदद मिलती है।
ऑपरेशन की पुष्टि करने के लिए, एक ऐसा परीक्षण कार्य भेजें जिसमें किसी ऐसे DOM चयनकर्ता (#phantom-settlement-modal) पर क्लिक करने के लिए कहा गया हो जो मौजूद नहीं है। यदि 1 पुनਰ्प्रयास (कुल 2 प्रयास) के बाद यह तुरंत रुक जाता है और टेलीग्राम सूचना आ जाती है, तो दैनिक खर्च $5 के भीतर सीमित रहता है।
React या Next.js के साथ बनाए गए डैशबोर्ड HTML लोड होने के बाद भी JavaScript बंडल को अनपैक और हाइड्रेट करते हैं। यदि कोई एजेंट केवल window.onload इवेंट को देखकर सीधे प्रवेश करता है, तो वह स्केलेटन लोडर को वास्तविक डेटा मानकर त्रुटियाँ उत्पन्न करता है। हालाँकि, आँख बंद करके time.sleep(5) सेट करना बहुत समय बर्बाद करता है।
एक स्पष्ट एंकर तत्व सेट किया जाना चाहिए और पोलिंग फ़ंक्शन को निष्पादित किया जाना चाहिए।
`python
import logging
from playwright.sync_api import Page, TimeoutError
def wait_for_dashboard_hydration(
page: Page,
anchor_selector: str,
max_attempts: int = 3,
interval_ms: int = 3000
) -> bool:
for attempt in range(1, max_attempts + 1):
try:
page.wait_for_selector(anchor_selector, state="visible", timeout=interval_ms)
if not page.locator(".dashboard-skeleton-loader").is_visible():
return True
except TimeoutError:
logging.info(f"Hydration waiting: Attempt {attempt}/{max_attempts}")
return False
`
एक्सेसिबिलिटी ट्री के माध्यम से लक्ष्य नोड का पाठ (Total Volume: $12,450.00) निकाला जाता है, और कार्ड UI के भीतर की संख्याओं के साथ मिलान करने के लिए वर्तमान स्क्रीन कैप्चर को मल्टीमॉडल मॉडल को传递 (पास) किया जाता है। यदि दोनों मान भिन्न हैं, तो यह माना जाता है कि रेंडरिंग अभी तक पूरी नहीं हुई है और 3 सेकंड के बाद दोबारा जाँच की जाती है।
आप Chrome DevTools Protocol (CDP) के साथ एक वर्चुअल नेटवर्क विलंब वातावरण बनाकर इस तर्क का परीक्षण कर सकते हैं।
`python
cdp_session = page.context.new_cdp_session(page)
cdp_session.send("Network.emulateNetworkConditions", {
"offline": False,
"latency": 500,
"downloadThroughput": 400 * 1024 / 8,
"uploadThroughput": 400 * 1024 / 8
})
`
आप यह सत्यापित कर सकते हैं कि क्या एजेंट RTT 500ms और डाउनलोड 400kbps के विलंब के तहत भी समय से पहले विफलता नहीं दिखाता है, बल्कि 3 बार (कुल 9 सेकंड) प्रतीक्षा करता है और डेटा को पूरी तरह से स्क्रैप करता है।
जब कोई एजेंट रात भर काम करने के बाद रुक जाता है, तो हज़ारों पंक्तियों के टेक्स्ट लॉग को खंगालने से ज़्यादा थकाऊ कुछ नहीं है। यदि आप निगरानी को ठीक करने में हर हफ़्ते तीन या चार घंटे बर्बाद करते हैं, तो स्वचालन का उद्देश्य ही खत्म हो जाता है।
हर बार जब कोई उप-एजेंट कोई कार्रवाई समाप्त करता है, तो इसे केवल तीन चीज़ों—timestamp, url, और action—को शामिल करके एकल-पंक्ति JSONL फ़ाइल के रूप में सहेजना सुनिश्चित करें।
`json
{"timestamp": "2026-03-31T08:15:02Z", "url": "https://dashboard.stripe.com/payments", "action": "CLICK", "target": "button[data-testid='filter']", "status": "SUCCESS"}
{"timestamp": "2026-03-31T08:15:05Z", "url": "https://dashboard.stripe.com/payments", "action": "WAIT_FOR", "target": "div[data-testid='metrics-card']", "status": "RETRY_1", "error": "Timeout 3000ms"}
{"timestamp": "2026-03-31T08:15:08Z", "url": "https://dashboard.stripe.com/payments", "action": "EXTRACT_TEXT", "target": "div[data-testid='metrics-card']", "status": "FAIL", "screenshot_path": "artifacts/errors/metrics_fail.png"}
`
जब कार्य समाप्त हो जाता है, तो लीड बॉट केवल FAIL टैग वाले आइटम का चयन करता है और एक मार्कडाउन सारांश (daily_failure_digest.md) निकालता है।
`markdown
Total Jobs: 50 | Succeeded: 48 | Failed: 2 | Total Token Cost: $0.84
`
कार्यालय पहुँचकर डाइजेस्ट खोलना और विफलताओं की संख्या की जाँच करना 1 मिनट, स्क्रीनशॉट खोलना और बदले हुए चयनकर्ता की पुष्टि करना 1 मिनट, और संशोधन अनुमोदन चेकबॉक्स पर क्लिक करना 1 मिनट का काम है। हर सुबह लॉग के साथ संघर्ष करने की कोई आवश्यकता नहीं है।
ब्राउज़र एजेंट अंततः असंरचित वातावरण से निपटने का एक साधन हैं। जहाँ आधिकारिक API अच्छी तरह से उपलब्ध हैं, वहाँ ब्राउज़र एजेंट को तैनात करने का कोई कारण नहीं है।
| वर्गीकरण | साझा क्लाउड ब्राउज़र | पृथක (Isolated) स्टेटलेस कंटेनर | आधिकारिक REST API |
|---|---|---|---|
| प्रारंभिक सेटअप | प्रॉम्प्ट इनपुट के साथ सीधे संचालित होता है | Docker इमेज और नेटवर्क आइसोलेशन की आवश्यकता है | समापन बिंदु (Endpoint) प्रमाणीकरण और मैपिंग की आवश्यकता है |
| सुरक्षा अलगाव स्तर | Chromium प्रोफ़ाइल और सत्र नीति आवश्यक | कार्य पूरा होने पर कंटेनर नष्ट हो जाता है | ब्राउज़र कुकी चोरी का कोई जोखिम नहीं |
| निष्पादन लागत | विजन रीजनिंग और DOM सीरियलाइज़ेशन के कारण उच्च | होस्टिंग लागत और LLM अनुमान लागत उत्पन्न होती है | केवल JSON पार्सिंग के माध्यम से गुजरता है, इसलिए बहुत कम |
| UI परिवर्तन लचीलापन | दृश्य जानकारी के आधार पर बाईपास किया जा सकता है | चयनकर्ता संशोधन कोड परिनियोजन (deployment) की आवश्यकता है | UI परिवर्तनों से बिल्कुल भी प्रभावित नहीं होता |
| उपयुक्त कार्य | बिना API के बाहरी डैशबोर्ड की जाँच करना | बड़े पैमाने पर वेब स्क्रैपिंग | Stripe भुगतान पुष्टिकरण, डेटाबेस परिवर्तन |
भुगतान या खाता परिवर्तन से जुड़े कार्यों के लिए जहाँ पैसे का लेन-देन होता है, आधिकारिक API का उपयोग करना सुरक्षित है। दूसरी ओर, उन क्षेत्रों में जहाँ मानवीय हस्तक्षेप की आवश्यकता होती है, जैसे कि पार्टनर एडमिन की जाँच करना या स्क्रीन मॉनिटरिंग जो API प्रदान नहीं करते हैं, ब्राउज़र एजेंट अच्छी तरह से काम करते हैं। भौतिक ब्राउज़र आइसोलेशन और सर्किट ब्रेकर लगाकर, आप रात भर एजेंट को चलाने पर भी मानसिक शांति पा सकते हैं।