--- title: 'VeriGrey: Greybox Security Validation' url: https://www.emergentmind.com/topics/verigrey type: topic --- # VeriGrey: Greybox Security Validation Searching arXiv for the cited VeriGrey paper and closely related graybox security-testing work. {"query":"id:2603.17639 OR ti:\"VeriGrey: Greybox Agent Validation\"","max_results":5,"sort_by":"submittedDate","sort_order":"descending"} {"query":"2603.17639","max_results":10} {"query":"2005.03322","max_results":10} VeriGrey denotes a grey-box security-validation paradigm in which test generation is driven by runtime behavioral signals rather than by purely black-box input/output observation. In current literature, the term most directly identifies the framework presented in "VeriGrey: Greybox Agent Validation," which targets LLM agents that autonomously plan and invoke external tools [2603.17639]. The term has also been used for a graybox web-security analyzer implemented as a ZAP plugin cooperating with a modified MariaDB, which upgrades a blackbox scanner with database traffic interception, input injection and tracking, and context-aware output analysis to detect stored and context-sensitive XSS [2005.03322]. Across both usages, the common principle is to expose internal-but-lightweight execution structure—tool-invocation sequences in agent systems, or database fetch and rendering contexts in web applications—to improve the discovery of vulnerabilities that conventional black-box methods systematically miss. ## 1. Scope, nomenclature, and unifying idea The two principal uses of the name apply to distinct security domains but share a common methodological commitment to gray-box feedback. In the agent setting, VeriGrey instruments tool invocations and treats newly observed tools, transitions, and full sequences as coverage. In the web-security setting, the analyzer instruments the database protocol boundary and reasons about the path from stored values to browser contexts. | Usage | Domain | Feedback signal | |---|---|---| | VeriGrey: Greybox Agent Validation | LLM agents with external tools | Tool names, arguments, transitions, full sequences | | Graybox XSS analyzer | Web applications with SQL back ends | Database fetch metadata and rendering context | This shared structure is significant because both target systems exhibit behaviors that are difficult to expose through surface-level prompt mutation or HTTP replay alone. In both cases, the gray-box signal is not a full white-box model of internals; it is a lightweight execution signature that improves exploration without requiring model internals in the agent case or web-application source instrumentation in the XSS case. ## 2. Agentic-AI validation problem and security model In its primary usage, VeriGrey is a grey-box validation framework for LLM agents that autonomously plan and invoke external tools [2603.17639]. The motivating observation is that LLM agents differ from single-shot LLMs in that they act over time, reason, and call tools such as shell, web, calendar, email, and MCP servers. This autonomy introduces several security risks: indirect prompt injection, malicious skill discovery, unsafe tool usage, and unexpected emergent behaviors. Indirect prompt injection arises when adversarial instructions embedded in external resources such as web pages, emails, MCP tools, or skill marketplaces are ingested and acted on. Malicious skill discovery concerns marketplace skills whose instructions or side effects can cause autonomous installation and execution. Unsafe tool usage includes invocation of dangerous tools such as unrestricted shell or `web_fetch` for exfiltration. Unexpected emergent behaviors arise when complex tool/LLM interactions produce rare sequences that bypass guardrails. The framework is motivated by the insufficiency of black-box red-teaming for agents. The stated reasons are that feedback is sparse, agent behavior is mediated by tool choices and their sequencing rather than surface text alone, and many dangerous behaviors are infrequent and require exploring rare tool sequences and transitions. VeriGrey therefore uses the actual sequence of tool invocations and their arguments as grey-box feedback, improving exploration and focusing mutation effort on inputs that lead the agent into previously unseen or risky behaviors. A central design choice is mutational prompt injection with context linking. Rather than generating generic adversarial text, VeriGrey mutates seeds so that the injection task is framed as a necessary step of completing the agent functionality. This suggests that the framework is not merely searching for prompt fragments that override the policy; it is attempting to preserve plausibility with respect to the user task, thereby increasing the chance that an agent planner will route execution into dangerous tools. ## 3. Formalization and coverage-guided search The agent is formalized as a tuple $$ A = (\Sigma, T, \pi, E), $$ where $\Sigma$ is the state space, $T = \{\tau_1,\dots,\tau_m\}$ is the set of tools, $\pi$ is the LLM-driven planner/executor, and $E$ is the environment in which tools produce outputs [2603.17639]. Given a user task $u$ and an injected prompt $p$, an execution yields a tool invocation sequence $$ s = (z_1, z_2, \dots, z_n), $$ with $$ z_i = (\mathrm{name}(\tau), \mathrm{args}(\tau), \mathrm{meta}). $$ VeriGrey maintains coverage over tool-level behaviors at three granularities: tool coverage, transition coverage, and sequence coverage. It defines $$ T_s = \{\mathrm{name}(z_i) : z_i \in s\}, $$ and $$ E_s = \{(\mathrm{name}(z_i), \mathrm{name}(z_j)) : i < j \text{ and adjacent or selected definition of transition}\}. $$ Let the previously seen sets be $T_{\text{seen}}$, $E_{\text{seen}}$, and $S_{\text{seen}}$. The feedback indicators are $$ I_{\text{tool}}(s)=1 \text{ if } T_s \setminus T_{\text{seen}} \neq \varnothing \text{ else } 0, $$ $$ I_{\text{edge}}(s)=1 \text{ if } E_s \setminus E_{\text{seen}} \neq \varnothing \text{ else } 0, $$ $$ I_{\text{seq}}(s)=1 \text{ if } s \notin S_{\text{seen}} \text{ else } 0. $$ The mutation energy is $$ e(s) = I_{\text{tool}}(s) + I_{\text{edge}}(s) + I_{\text{seq}}(s), $$ and seeds are considered interesting if $$ C(s)=I_{\text{tool}}(s)+I_{\text{edge}}(s)+I_{\text{seq}}(s) > 0. $$ The paper also gives a generic fitness form, $$ F(s)=\alpha I_{\text{tool}}(s)+\beta I_{\text{edge}}(s)+\gamma I_{\text{seq}}(s), $$ but uses integer increments per satisfied metric with $\alpha=\beta=\gamma=1$. The vulnerability predicate is defined over injection tasks $I$ and their oracles $O_T$: $$ V(s)=1 \text{ if } \exists T \in I \text{ s.t. } O_T(A,s)=\mathrm{true}, \text{ else } 0. $$ The mutation operator is an LLM-guided operator $$ p' = M(p; \theta, u, s) $$ subject to a linking constraint $$ \mathcal{L}(p', T, u)=1. $$ Operationally, the mutator is instructed to infer the user intent from $u$, craft a scenario where performing $T$ is presented as a prerequisite or diagnostic step needed to complete $u$, and incorporate tool hints gleaned from $s$, such as using `read_file` before `web_fetch`. The search loop is evolutionary and coverage-guided: instrument tool calls, construct initial prompts, execute with prompt injection, update coverage and vulnerability databases, mutate with context linking, and select seeds that yielded new coverage. Convergence is discussed informally rather than as a proof; the paper states that grey-box guidance accelerates discovery of rare sequences and that removing feedback substantially reduces performance, especially on hard tasks requiring longer sequences. ## 4. Evaluation, ablations, defenses, and case studies On the AgentDojo benchmark, the evaluation uses 97 user tasks, an average of 8.7 injection tasks per environment, a 100-execution budget per testing campaign, and two methods across three LLMs, yielding 582 campaigns [2603.17639]. The principal metric is Injection Task Success Rate (ITSR), defined as the number of injection tasks completed at least once divided by the total injection tasks. | Model | Baseline ITSR | VeriGrey ITSR | |---|---:|---:| | GPT-4.1 | 37.7% | 70.7% | | Gemini-2.5-Flash | 36.8% | 47.4% | | Qwen-3 235B | 67.6% | 81.7% | For GPT-4.1, the paper reports a gain of +33.0 percentage points. By suite, GPT-4.1 improves from 16.1% to 48.2% on Workspace, from 40.7% to 87.1% on Travel, from 34.7% to 68.1% on Banking, and from 78.1% to 100% on Slack. By difficulty, the same backend improves from 55.2% to 88.1% on Easy, from 7.6% to 30.1% on Medium, and from 11.3% to 43.3% on Hard. The ablation study isolates the two core mechanisms. Full VeriGrey reaches 70.7% ITSR. Removing feedback yields 59.6%, with the most pronounced drop on hard tasks, where performance falls from 43.3% to 21.6%. Removing context bridging yields 44.0%, with large drops across all difficulties, including Easy from 88.1% to 60.2%. The empirical implication is direct: both tool-sequence feedback and context-bridging mutation are critical to the reported efficacy. The defense study evaluates ITSR alongside User Task Success Rate (UTSR) on a 31-user-task subset. Without defense, UTSR is 85.0 and VeriGrey ITSR is 69.7 versus 41.2 for the baseline. Under prompt sandwiching, UTSR is 86.5 and VeriGrey ITSR is 65.2 versus 17.4. Under data delimiter defenses, UTSR is 81.0 and VeriGrey ITSR is 67.6 versus 36.4. Prompt injection detection with BERT reduces UTSR to 50.4 and lowers VeriGrey ITSR to 21.6 versus 5.2, which the paper characterizes as significant usability degradation with high false positives. Tool filtering with whitelisted tools yields UTSR 81.7 and VeriGrey ITSR 17.4 versus 12.8, and is identified as the most effective overall defense among those studied with modest usability impact. The real-world case studies extend the benchmark findings. On Gemini CLI, using ten injection tasks in a single-use Docker container and a user task adapted from SWE-bench (`django-14500`) with "run security scan" added to trigger an MCP tool, VeriGrey reaches 90% ITSR (9/10) versus 60% (6/10) for the baseline. It succeeds on hard tasks involving sending bash history, extracting SSH keys, and adding a malicious alias to `~/.bashrc`. On Task 6, a cron-based payload, neither method achieves full success, although VeriGrey induces partial malicious behavior by downloading and running code without achieving persistent cron installation. Under a tool-filter defense on Gemini CLI, VeriGrey falls to 50% ITSR and the baseline to 30%, while bug-patch generation remains acceptable. On OpenClaw, the study examines supply-chain skill vulnerabilities using 10 selected malicious or suspect skills from a larger set flagged by KOI, Snyk, and Cisco. With a 20-run budget per skill, original skills succeed at 1/10 across all three backends, while VeriGrey-mutated skills reach 10/10 on Kimi-K2.5, 9/10 on Opus-4.6, and 8/10 on GPT-5.2. The derived tactics include framing a malicious install as a "natural step" in `SKILL.md`, emphasizing autonomy with instructions such as "No manual intervention needed," and fabricating realistic usage examples that make malicious packages appear integral to the skill’s function. ## 5. Threat model, limitations, and role in agent assurance The agent-validation framework addresses single-session attacks via indirect prompt injection from external resources, tool misuse leading to data exfiltration or unsafe code execution, privacy leakage, and supply-chain skill attacks based on malicious `SKILL.md` instructions or scripts [2603.17639]. It is explicitly out of scope for persistent multi-session memory poisoning and long-term agent state attacks, although related work is noted. It also does not provide formal guarantees or proofs; VeriGrey is presented as a dynamic validation tool. The operational assumptions are concrete. Agent frameworks must expose or be instrumentable to wrap tool invocations through decorators or hooks. The verifier must be able to inject prompts via known endpoints such as tool outputs or environment resources. Oracles must exist to judge injection-task success, logging must be permitted, and the agent must have permission to call dangerous tools unless tool filters block them. The limitations are similarly explicit. Efficacy depends on LLM backend characteristics and varies by model, although the reported results remain consistently better than baseline. Not all vulnerability classes are addressed, including complex multi-agent collusion and covert channels. Developer effort is required to instrument tool-call sites, though the paper describes this effort as typically minimal in common frameworks and MCP environments. Overhead and time-to-discovery are not quantified, and cost depends on agent tool frequency and LLM usage. Within an assurance workflow, VeriGrey is positioned as a recurring validator. Recommended integration includes CI/CD execution against agent updates and tool or skill changes, maintenance of a corpus of discovered adversarial prompts and sequences, prioritization of tests that extend tool and transition coverage, collection of reproducible evidence in the form of prompts, sequences, and tool arguments, and iterative derivation of defense updates such as tool filters and policy rules. A common misconception is that grey-box validation is equivalent to white-box verification; the paper instead places VeriGrey between black-box red-teaming and white-box analysis, using runtime feedback to capture emergent behavior without requiring model internals or heavy instrumentation. ## 6. Database–scanner cooperative analysis for stored and context-sensitive XSS A second usage of the term denotes a graybox XSS analyzer whose prototype is "a ZAP plugin cooperating with a modified MariaDB"; the original paper itself describes the system as "our graybox XSS analyzer" rather than assigning a product name [2005.03322]. Its objective is to close the gap left by conventional blackbox scanners, which systematically test only reflected, context-insensitive XSS and often miss reflected context-sensitive, stored context-insensitive, and stored context-sensitive flaws. The motivating distinctions are reflected versus stored XSS and context-sensitive versus context-insensitive rendering. Stored XSS involves longer and more complex dataflow because attacker input is saved, typically in a database, and later rendered in some other response. Context-sensitive XSS arises because sanitization must match the browser context of rendering: HTML text, JavaScript strings, CSS, URIs, and HTML attributes each require different handling. The paper’s exemplary mismatch uses `htmlentities` before placing a value inside a single-quoted JavaScript string embedded in a double-quoted HTML attribute; after browser decoding, quotes reappear inside the JavaScript string and break out of the intended context. The analyzer’s architecture is centered on database traffic interception at the DB–webapp boundary. In request recording mode, the database works normally but reports fetched strings as table, column, and value triples. In response injection mode, it replaces selected fetched string values with scanner-provided payloads. The interception point is the MariaDB `COM_QUERY` path where string types such as `MYSQL_TYPE_VARCHAR`, `VAR_STRING`, and `STRING` are inserted into `ResultSet` packets. From the application’s perspective, this is nearly blackbox, because the web application itself is not instrumented. Payload tracking is designed to survive transformations. The canonical payload template is `abcdef