arXiv:2605.15281v1 [cs.CR] 14 May 2026
Autonomous Intelligent Agents for Natural-Language-Driven Web Execution with Integrated Security Assurance Vinil Pasupuleti
Siva Rama Krishna Varma Bayyavarapu
Shrey Tyagi
International Business Machines (IBM) South Carolina, United States IEEE Senior Member
Docusign Indiana, United States IEEE Senior Member
Salesforce Inc North Carolina, United States Independent Researcher
Abstract—Modern web test suites rot. A UI refactor breaks locators, a timing change causes race conditions, and within weeks developers abandon the suite entirely. This paper presents an AIdriven autonomous testing framework that addresses these failure modes through five integrated strategies—navigation reliability, context-aware selector generation, post-generation validation, smart wait injection, and failure learning—implemented over a containerised worker architecture that decouples orchestration from long-running browser execution. Evaluated across four production applications and 176 scenarios, the framework improves script generation success from 55% to 93%, achieves an 8× reduction in navigation failures, eliminates 80% of timing-related race conditions, and reduces test creation time by 75% compared to manual Selenium authoring. The framework extends naturally to security validation: testers describe attack scenarios in plain English—“try accessing another user’s invoice”—which the agent converts to OWASP Top 10-aligned browser probes, detecting 85% of authentication bypass vulnerabilities and 95% of input validation flaws with false positive rates below 12%. Natural-language-driven security testing of this kind represents, to our knowledge, a novel contribution to the field. Index Terms—AI test generation; serverless architecture; web automation; security testing; large language models; natural language processing; autonomous testing
I. I NTRODUCTION Selenium test suites have a tendency to rot. A UI refactor breaks locators, an animation change causes timing failures, and within weeks the team spends more time maintaining tests than shipping features. We started this work after watching a 200-test suite become effectively useless—developers simply stopped running it, having lost confidence in the results. LLMs seemed like an obvious solution [17]. Describe tests in plain English, let the model handle selectors. The initial experiments were not encouraging: roughly 55% success. Navigation links were ambiguous. Wait conditions were missing. Element IDs were hallucinated. The “impressive demo” consistently failed when pointed at real applications. This paper documents what we did about it. Through iteration—considerably more than we had anticipated—we developed five strategies that pushed success to 93%. An unanticipated benefit: the same reasoning handles security
testing. Testers write attack descriptions in plain English— “try accessing another user’s invoice”—and the agent executes them as browser-based probes. Contributions: (1) five-strategy enhancement pipeline addressing navigation, selectors, validation, waits, and failure learning; (2) containerized worker architecture decoupling orchestration from browser execution; (3) natural language security testing mapped to OWASP Top 10; (4) evaluation across four production applications showing 8x navigation improvement and 75% time savings. Positioning relative to prior work: Autonomous web agents following the ReAct paradigm [16] and benchmarked on environments such as WebArena [20] optimise for openended task completion; they do not generate replayable, version-controlled test scripts, track coverage across test suites, or produce structured security reports—distinct requirements that shape our architecture. Self-healing locator systems [10] repair broken selectors reactively after a failure occurs; our framework reduces the frequency of such failures proactively through Strategy 2’s context-enriched selector generation, and Strategy 5’s failure-log analysis provides a feedforward signal that complements the reactive repair these systems offer. II. L ITERATURE R EVIEW A. Traditional Test Automation Record-playback tools such as Selenium IDE reduce initial authoring effort but generate brittle selectors that break with UI changes [6]. Hammoudi et al. [7] analyzed test maintenance logs and found that 74% of effort stems from locator updates—a finding consistent with our own experience. Robust locator strategies [2] improve resilience but still require human intervention when structural changes occur. Behaviordriven frameworks [8] separate test logic from implementation details, yet testers must still author explicit step definitions— the gap our work addresses. B. AI-Assisted Testing Machine learning approaches to test automation include visual testing for layout regression [9], self-healing locators that adapt to UI changes [10], and reinforcement learning
for exploratory test generation [11]. LLM-based code generation [1], [14] has shown promise, though published studies report success rates between 30% and 60% for complex generation tasks [13]. Chain-of-thought prompting [19] and self-debugging techniques [12] improve reliability through iterative refinement, an approach we adopt in Strategy 3. To our knowledge, no prior work enables natural language-driven security testing.
Generation Input
Scrape
Enhancement 55%
LLM
S1
S2
S3
S4
S5 93%
Agent
Browser
Results
Execution
Fig. 2. Data Flow Pipeline: Generation (55%) → Enhancement S1-S5 → Execution (93%).
C. Security Testing Automation Tools like OWASP ZAP [3] and state-aware vulnerability scanners [5] are powerful but require expertise to configure and interpret [4]. Black-box vulnerability testing [15] typically operates at the HTTP layer, missing client-side issues that manifest only in browser context. Browser-based security probes triggered by natural language descriptions—our approach—appears to be novel. III. S YSTEM A RCHITECTURE The system comprises five components: AI Test Generator, Five-Strategy Pipeline, Security Validation Module, Autonomous Agent, and Containerized Worker Infrastructure. Figure 1 illustrates how these components are arranged in a layered stack, with each layer described in the subsections below. UI Layer (Frontend Framework)
Backend Orchestration (Database + API Layer)
AI Decision Engine (Vision-Enabled LLM)
Browser Automation (Headless Browser Engine)
Security Validation (Access Control/Audit/Sandboxing)
Fig. 1. Multi-layer System Architecture showing UI, Backend Orchestration, AI Decision Engine, Browser Automation, and Security Validation components.
The workflow proceeds in three phases: (1) Generation— user provides plain-text steps, system scrapes target URL, LLM generates candidate script (55–65% baseline); (2) Enhancement—five strategies progressively improve reliability to 90–95%; (3) Execution—container workers launch headless browsers with semantic analysis at each step. Figure 2 traces a test instruction through all three phases, annotating the success rate entering and exiting the enhancement pipeline. IV. F IVE -S TRATEGY F RAMEWORK A. Strategy 1: Navigation Reliability (Highest Impact) React Router and similar SPA frameworks often render multiple links to the same path. Click-based navigation using
a[href=’/contact’] is ambiguous when the page contains several matching elements. We convert navigation clicks to direct URL access. The conversion process iterates through each step in the generated script. When a click action targets a navigation link (identified by anchor tags with href attributes), the system extracts the target path from the selector, constructs the full URL by combining it with the base URL, and replaces the click action with a direct navigate action. The original selector is preserved in metadata for debugging purposes. This transformation eliminates ambiguity when multiple matching elements exist on the page. This change had outsized impact relative to its simplicity. Navigation failures dropped from 40% to 5%—a result that surprised us, given how straightforward the fix appears in retrospect. B. Strategy 2: Selector Specificity After implementing Strategy 1, “element not found” errors still accounted for 30% of failures. Diagnosing the cause took longer than expected: LLMs tend to generate minimal selectors. A bare button.submit matches multiple elements on pages with several forms. The fix, once we understood the problem, was straightforward. We enriched the HTML scraper to include parent context—section headings, form labels, ARIA landmarks— and prepend this context when the initial selector proves ambiguous. Failures dropped from 30% to approximately 10%. C. Strategy 3: Validation After Generation Not every generated script deserves browser execution time. The question was how to identify problematic scripts before launching a container. We added a static analysis gate scoring each script from 0 to 100, checking for anti-patterns: clicking invisible elements, filling readonly fields, navigating to routes not present in the scraped DOM. Scripts scoring above 90 proceed to execution. Below 60 triggers regeneration with additional context. This gate catches approximately 85% of scripts that would otherwise fail during execution. D. Strategy 4: Smart Wait Injection LLMs consistently underestimate web latency. Generated scripts often click-then-assert without accounting for animations, API responses, or lazy loading. Our post-processor injects waits based on heuristics that, admittedly, we developed
through trial and error: wait after navigation, pause after clicks that might trigger route changes, delay assertions following form submissions. The approach is imperfect—we occasionally over-wait—but timing failures dropped from 25% to 5%. E. Strategy 5: Failure Learning Failed executions write structured records to a validation failures table: step number, selector attempted, error message, page state. We have logged 1,247 failures to date and ran cluster analysis to identify patterns. Three unanticipated anti-patterns emerged. We should be honest: this strategy has not moved aggregate success metrics yet. Its value is seeding the feedback loop for continuous improvement—value that will compound over time but is difficult to quantify in a single evaluation. V. C ONTAINERIZED W ORKER A RCHITECTURE Serverless platforms impose strict limits (AWS Lambda: 15min, Edge Functions: 90-120s). Long-running test sessions (5-30 minutes) require a different approach. Key Insight: Separate job orchestration (fast, stateless) from job execution (long-running, stateful) using a databasebacked job queue. The job creation process receives a request containing the session identifier, target URL, and user instructions. The serverless function inserts a new record into the jobs table with these parameters along with a pending status and creation timestamp. It immediately returns a success response with the job identifier, allowing the client to poll for status updates. This pattern enables sub-second response times while offloading long-running execution to container workers. Container workers poll the database, claim jobs atomically, and execute with no time limits. Heartbeat mechanism (every 30s) enables stuck job recovery. Table I compares completion rates across all three architectural approaches evaluated. TABLE I A RCHITECTURE P ERFORMANCE C OMPARISON Architecture Pure Serverless Self-Resuming Edge Container Workers
Completion
Complexity
12% 67% 99%
Low High Medium
VI. AUTONOMOUS AGENT Figure 3 depicts the agent’s internal architecture; the perceive-reason-act loop at the Agentic Execution layer drives every step of test execution. The autonomous agent employs transformer-based LLMs [18] to understand page semantics and make intelligent action decisions. It combines DOM-based analysis (tags, attributes, ARIA labels, text content) with visionbased analysis (screenshots, layout, icons) for multimodal perception.
Goal-Based Mode: High-level objectives decompose into sub-goals automatically (average 4.7 sub-goals per main goal). The agent re-plans from current state upon unexpected page changes. Error Recovery: Element not found triggers wait-and-retry (3 attempts, exponential backoff); failed actions try alternative selectors; self-recovery succeeds for 67% of failed steps. VII. S ECURITY T ESTING E XTENSION A. Democratizing Security Testing Adversarial Risks in Autonomous Execution. A known risk in LLM-driven browser agents is adversarial prompt injection: malicious content embedded in web pages—crafted error messages, hidden DOM text, or injected <meta> descriptions—could attempt to redirect agent reasoning or override instructions. Our sandboxed container execution and schema-based input validation (Table II) partially mitigate this risk by preventing injected content from escaping the browser environment. However, a principled defense against adversarial page content targeting the LLM reasoning layer itself is not yet implemented; addressing this through instruction-hierarchy techniques or adversarial prompt detection is an important direction for future work. The same LLM reasoning powering functional tests probes security boundaries—if framed correctly. Traditional tools like OWASP ZAP demand specialized expertise: configuring scan policies, interpreting cryptic output, manually verifying findings. Most teams lack dedicated security engineers, so these tools gather dust. Our framework takes a different approach. Testers describe attack scenarios in plain English: “log in as User A, then try viewing User B’s invoice” or “submit the form without the CSRF token.” The agent translates descriptions into browser actions, executes in a sandboxed container, and reports whether attacks succeeded. No security expertise required. B. OWASP Top 10 Alignment Threat Model. Our security validation assumes three attacker personas observable at the browser layer: (1) an authenticated user attempting horizontal privilege escalation (accessing another user’s resources without authorisation); (2) an unauthenticated actor probing routes that should require login; and (3) a form submitter injecting malicious payloads into client-visible input fields. We explicitly scope detection to behaviors observable via HTTP response codes, DOM state changes, redirect behavior, and client-side error messages. Server-side vulnerabilities that produce no browservisible signal—such as unvalidated deserialization, server-side request forgery, or cryptographic weaknesses—fall outside our detection capability and are acknowledged as a limitation in Section VIII-A. Figure 4 summarises the full defense-in-depth stack applied during security validation; each layer is discussed in the paragraphs below. We mapped natural language attack patterns to OWASP 2021 categories amenable to browser-based validation. For
UI Layer Page Analysis
Natural Language: “Navigate to login...”
DOM Extraction
AI Engine Agentic Exec
Screenshot
Vision-Enabled LLM
Reason
Perceive
Act
Browser Automation (Isolated)
Browser
Fig. 3. Agentic AI Architecture: UI receives natural language, Page Analysis extracts DOM and screenshots, Vision-Enabled LLM performs multimodal analysis, Agentic Execution runs Perceive-Reason-Act loop, Browser executes in isolated containers.
TABLE II S ECURITY T ESTING : D ETECTION R ATES AND G UARDRAIL E FFECTIVENESS Vuln. Class
Det.
FP
Guardrail
Block
Rate
Auth Bypass Session Access Ctrl Input Valid.
85% 90% 78% 95%
8% 5% 12% 3%
Schema Valid. HTML Sanitize RLS Scope Rate Limit
847 234 156 89
100% 100% 100% 97.8%
A01 (Broken Access Control), the revealing test is simple: log in as one user, grab a resource ID from another’s profile, fetch it directly. For A03 (Injection), our schema validator blocks six dangerous patterns before data reaches the browser— <script> tags, javascript: URIs, event handlers. A04 (Insecure Design) testing: attempt protected routes without authentication, flag anything returning content instead of redirects. Session testing (A07) validates token expiration, logout invalidation, session fixation resistance. User Input + External Data
Defense-in-Depth
Schema-Based Input Validation HTML Sanitization Layer Isolated Browser Container Database Row-Level Security Complete Audit Trail Fig. 4. Defense-in-Depth Security Architecture: Input Validation, HTML Sanitization, Isolated Container Execution, Database RLS, and Complete Audit Trail.
The AI agent identified: missing authentication checks on 3/15 endpoints (20% failure rate), session fixation vulnerability in legacy auth flow, and IDOR vulnerability in user profile
TABLE III C UMULATIVE S TRATEGY I MPACT ( N =176, 95% CI) Strategy
Success
95% CI
p-value
Baseline +Navigation +Selectors +Validation +Smart Waits
55% 72% 81% 84% 93%
[47.5, 62.3] [65.0, 78.3] [74.7, 86.3] [78.1, 88.8] [88.4, 96.2]
— <0.001 <0.01 0.18 <0.001
access. Validation Methodology. The detection rates in Table II were established as follows. Each of the four test applications contained a set of known vulnerabilities identified through prior manual audit by the authors (totalling 47 vulnerability instances across all OWASP categories tested). Agent-flagged findings were cross-verified through manual reproduction: a finding was counted as a true positive only if the exploit could be independently confirmed by a second author, and as a false positive if human review determined the flagged behavior to be benign or non-exploitable. The 3–12% false positive rates indicate that human review remains a necessary step before acting on agent findings—an expected cost of heuristic browser-layer detection. VIII. E XPERIMENTAL R ESULTS Testing across 4 applications following web agent evaluation methodology [20] (E-commerce SPA, SaaS dashboard, CMS, Banking portal) with 176 total scenarios. Table III reports cumulative success rates as each strategy is added; Table IV presents isolated per-strategy contributions from the ablation study. Note: Validation p=0.18 indicates marginal independent contribution; value compounds with other strategies. Combined improvement: 55% → 93% (+69% relative). Success Metric Definition. We define a test as successful if at least 80% of its scripted steps complete correctly, on the basis that partial automation still meaningfully reduces manual effort compared to no automation. Under the stricter criterion of 100% step completion, the combined pipeline achieves 71%
TABLE IV A BLATION S TUDY: I SOLATED S TRATEGY C ONTRIBUTIONS Strategy Navigation (S1) Selectors (S2) Validation (S3) Smart Waits (S4) Learning (S5)
manipulating LLM reasoning—is a known risk without a fully principled mitigation in the current implementation.
Isolated ∆
Interaction Effect
B. Threats to Validity
+17.0% +12.1% +5.2% +14.8% +0.0%*
Independent Partial S1 overlap Requires S1 context Independent Seeds future runs
We should be transparent about what this evaluation does not cover. Our four test applications—while diverse in technology stack (React SPAs, server-rendered dashboards, hybrid architectures)—represent a narrow slice of the web. Legacy applications with non-standard DOM structures, table-based layouts, or custom JavaScript frameworks defeated us more often than the aggregate numbers suggest. The 93% success rate also depends on definition. We counted 80%+ step completion as success, reasoning that partial automation still provides value over no automation. Under stricter criteria—100% step completion—our numbers would drop to approximately 71%. CI timing introduced variance we could not fully control. The same test suite showed 15% fluctuation between runs on identical code, primarily due to network latency and container cold-start timing. We report averages across five runs, but individual executions will vary.
TABLE V FAILURE T YPE R EDUCTION Failure Type
Before
After
Reduction
Navigation Element not found Timing/race Incorrect action
40% 30% 25% 20%
5% 10% 5% 8%
8x 3x 5x 2.5x
success—a figure we report transparently and discuss further in Section VIII-A (Threats to Validity). *Strategy 5 improves future runs, not immediate metrics. Failure Analysis (7%): Dynamic content via WebSocket (42% of failures)—agent cannot predict async arrivals. Complex multi-step workflows with 8+ steps and modal resets (35%). Shadow DOM boundaries (23%)—workarounds exist but weren’t implemented. Table V summarises failure type reductions achieved by the combined pipeline. Development Time: Our system averages 6.1 min at 93% success (6.6 min effective) vs. Manual Selenium at 23.5 min/95% (24.7 min effective)—75% reduction. Autonomous Agent: 92% goal completion (78/85 complex goals); average 4.7 sub-goals per main goal; 67% self-recovery from errors; 89% element identification accuracy.
C. Deployment & Scalability LLM API costs $0.03–$0.15/test. Container workers (1.2GB each) scale linearly—10 workers process 450 tests/hour at 92% success. Five-second polling introduces negligible latency; 30s heartbeat enables crash recovery. For enterprise: 2–4 vCPU, 4GB RAM per worker, auto-scale on queue depth (˜$0.10/hour active). Reproducibility: Supplementary materials include configurations, sample apps, and evaluation scripts. Docker-based deployment; validated against multiple LLM providers. D. Comparison with Related Work
IX. C ONCLUSION A. Limitations Several boundaries of the current system merit explicit acknowledgement. First, LLM dependency introduces nontrivial cost ($0.03–$0.15 per test) and latency (2–5 seconds per generation step), both scaling linearly with test volume; teams with large suites or budget constraints should weigh these costs. Second, complex scenarios—multi-step workflows with eight or more steps, modal-heavy flows, and virtual-scrolling interfaces—achieve only 78–85% success; the agent’s inability to predict asynchronous state changes is the primary driver. Third, Shadow DOM boundaries and iFrame-embedded content have limited support, accounting for 23% of remaining failures. Fourth, the security validation scope is restricted to browser-observable behaviors (HTTP response codes, DOM changes, redirects); server-side vulnerabilities producing no client-visible signal are undetectable by this approach. Fifth, generalization is uncertain: our four test applications represent modern SPA and hybrid architectures; legacy systems with non-standard DOM structures or tablebased layouts may yield substantially lower success rates. Finally, adversarial prompt injection—malicious page content
Traditional automation—Selenium, Cypress, Playwright— demands explicit selectors. When UI changes, selectors break. Our approach sidesteps brittleness by teaching the LLM page semantics: “click the primary action button in the checkout form” instead of #submit-btn. The perceive-reason-act loop [16] enables self-recovery (67% success) from errors that would fail deterministic scripts outright. Self-healing locator systems [10] are the closest prior approach: they detect broken selectors at runtime and repair them reactively. Our framework is complementary—Strategy 2’s context-enriched selector generation reduces the frequency of failures that would trigger self-healing, while Strategy 5’s failure-log clustering provides a feedforward signal analogous to what self-healing systems use reactively. Autonomous web agents following the ReAct paradigm [16] and evaluated on open-ended benchmarks such as WebArena [20] optimise for goal completion in unconstrained environments; they do not produce replayable, version-controlled test scripts, expose a CI-integrable pass/fail contract, or generate structured security reports. These are distinct engineering goals that motivate our architecture choices—particularly the containerised worker model and the five-strategy enhancement pipeline—which
would add unnecessary overhead in a purely task-completion setting but are essential for reliable, reproducible test automation. We set out to reduce end-to-end testing friction. The fivestrategy pipeline pushed script generation from 55% to 93%— not through improvements in LLM capability but by systematically cataloguing failure modes through trial and error. Natural language security testing opened penetration testing to nonspecialists, though the 3–12% false positive rates mean human review remains necessary. The 75% time reduction across experiments is encouraging, but we are cautious about generalizing. Our test applications were relatively modern—teams maintaining legacy jQuery applications may see different results. Limitations remain: complex multi-step workflows, Shadow DOM boundaries, and LLM costs that scale linearly with test volume. For teams drowning in test maintenance debt, this work offers a practical path: let AI handle selector tedium while humans focus on test strategy and edge case identification. F UTURE W ORK Visual intelligence through OCR and layout analysis represents a promising extension, enabling the agent to interpret icons, charts, and non-semantic UI elements. A learning system with fine-tuned models on domain-specific applications could further improve generation success. Mobile testing via Appium would extend coverage to native applications. API contract validation would complement browser-based testing by verifying backend consistency. Finally, deeper CI/CD integration would enable automated test suite maintenance as applications evolve. Accessibility validation aligned with WCAG 2.1 guidelines represents a natural extension of the security testing paradigm. The agent could verify keyboard navigation paths, screen reader compatibility, and color contrast compliance through the same natural language interface—testers would describe expected accessibility behaviors rather than manually auditing each component. Cross-browser compatibility testing through parallel execution across browser engines (Chromium, Firefox, WebKit) would address a persistent pain point, with the agent automatically detecting rendering inconsistencies and browserspecific failures. Multimodal test generation combining visual mockups with natural language descriptions could enable testers to sketch expected layouts and describe interactions simultaneously, reducing the gap between design specifications and executable tests. Integration with formal verification techniques may provide mathematical guarantees about test coverage completeness. Finally, collaborative learning across organizations— where anonymized failure patterns and recovery strategies are shared—could accelerate the self-improvement cycle while preserving proprietary application details. A complementary direction lies in policy-compliant agent orchestration [21], which enforces hard regulatory constraints (SOX, HIPAA, GDPR) at the multi-agent coordination layer. While our framework detects policy violations reactively
through browser-observable probes, integrating upstream policy projection at the orchestration layer could eliminate whole classes of violations before execution begins—a natural evolution for enterprise DevSecOps deployments. ACKNOWLEDGMENTS We thank the beta testers who ran early versions against production applications and provided invaluable feedback on failure modes. The open-source browser automation community laid the foundation this work builds upon. The authors acknowledge the use of AI-assisted tools for language editing. All technical contributions, experiments, and conclusions are those of the authors. R EFERENCES [1] M. Chen et al., “Evaluating Large Language Models Trained on Code,” arXiv:2107.03374, 2021. [2] M. Leotta et al., “Reducing Web Test Cases Aging by Means of Robust XPath Locators,” IEEE ISSRE, 2014. [3] OWASP Foundation, “OWASP Testing Guide v4.2,” 2023. [4] M. Zalewski, “The Tangled Web: A Guide to Securing Modern Web Applications,” No Starch Press, 2011. [5] A. Doupé et al., “Enemy of the State: A State-Aware Black-Box Web Vulnerability Scanner,” Proc. USENIX Security, 2012. [6] M. Leotta et al., “PESTO: A Tool for Migrating DOM-based to Visual Web Tests,” Proc. ACM SIGSOFT FSE, 2016. [7] M. Hammoudi et al., “Why Do Record/Replay Tests of Web Applications Break?” Proc. ICST, 2016. [8] J. F. Smart, “BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle,” Manning, 2014. [9] S. Mahajan et al., “WebEvo: Automatic Evolution of Web Applications,” Proc. ESEC/FSE, 2021. [10] F. Ricca et al., “AI-based Self-Healing Web Test Automation,” Proc. ICSME, 2021. [11] Y. Zheng et al., “Wuji: Automatic Online Combat Game Testing Using Evolutionary Deep Reinforcement Learning,” Proc. ASE, 2019. [12] M. Chen et al., “Teaching Large Language Models to Self-Debug,” arXiv:2304.05128, 2023. [13] C. Lemieux et al., “CodaMosa: Escaping Coverage Plateaus in Test Generation with Pre-trained Large Language Models,” Proc. ICSE, 2023. [14] M. Schäfer et al., “An Empirical Evaluation of Using Large Language Models for Automated Unit Test Generation,” IEEE TSE, 2023. [15] J. Bau et al., “State of the Art: Automated Black-Box Web Application Vulnerability Testing,” Proc. IEEE S&P, 2010. [16] S. Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models,” Proc. ICLR, 2023. [17] T. Brown et al., “Language Models are Few-Shot Learners,” Proc. NeurIPS, 2020. [18] A. Vaswani et al., “Attention Is All You Need,” Proc. NeurIPS, 2017. [19] J. Wei et al., “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models,” Proc. NeurIPS, 2022. [20] S. Zhou et al., “WebArena: A Realistic Web Environment for Building Autonomous Agents,” arXiv:2307.13854, 2023. [21] V. Pasupuleti et al., “Safe and Policy-Compliant Multi-Agent Orchestration for Enterprise AI,” arXiv:2604.17240, 2026.