Dual Mode (QA & Security)
Ghost serves two different types of users — QA engineers who test applications for bugs and security researchers who test applications for vulnerabilities. Rather than building two separate tools, Ghost has a dual mode system: a single toggle in the command bar switches the entire application between QA Mode and Security Mode.
This isn’t just a cosmetic change. When you flip the mode, the layout restructures, the AI agent’s personality and knowledge transforms, the available tools change, and even the flow list shows different information. It’s like having two specialized apps in one.
Mode Switch
Section titled “Mode Switch”What this diagram shows: A single mode toggle (the shield icon in the command bar) controls which “personality” of Ghost is active. On the left, QA Mode configures the sidebar as a domain/app scope panel, gives the AI agent QA-focused tools (test generation, bug reports), and shows a standard traffic list. On the right, Security Mode replaces the sidebar with a findings panel showing vulnerability counts by severity, gives the agent security-focused tools (penetration testing, vulnerability analysis), and adds security-relevant columns to the flow list.
What Changes Between Modes
Section titled “What Changes Between Modes”Here’s a comprehensive breakdown of everything that transforms when you switch modes:
| Aspect | QA Mode | Security Mode |
|---|---|---|
| Left sidebar | Scope Panel with three navigators: domains (grouped by hostname with health indicators), apps (grouped by detected source application), and devices (connected mobile devices) | Findings Panel showing a severity summary (how many Critical, High, Medium, Low findings), type breakdown (what categories of issues were found), and a scrollable list of individual findings |
| Flow list columns | Standard columns: method (color-coded badge), status code, hostname, URL path, duration (ms), response size | Security-enhanced columns: same as QA plus a severity badge (if the flow has findings), auth type indicator (Bearer token, cookie, API key, etc.), findings count, and a TEST badge on flows generated by security testing |
| AI agent persona | QA-focused personality. The agent thinks about test coverage, regression detection, bug reproduction, and test code generation. It speaks in QA terminology. | Security-focused personality. The agent thinks like a penetration tester — vulnerability discovery, attack surface mapping, exploit development, and findings documentation. It follows OWASP methodology. |
| AI agent tools | Up to ~54 tools including test generation (Playwright, Cypress, Appium, k6, hey), bug report generation, regression detection, test scenarios, API documentation, mock server generation, session reporting, form testing, endpoint fuzzing, browser control, inspector tools, workspace file management, plan tools, and TestRail integration | Up to ~60 tools including HTTP request sending, request attacking with wordlists, 10 external scanners (Nuclei, Dalfox, ffuf, sqlmap, trufflehog, katana, semgrep, nmap, sslscan, hydra), 6 Frida tools (SSL/root bypass, tracing, injection), browser control, inspector tools, workspace tools, and plan tools. Note: analysis tasks like JWT decoding, auth pattern analysis, IDOR detection, and security header auditing are handled by the LLM directly from raw flow data rather than as dedicated tools. |
| System prompt | Guides the agent toward QA workflows: “analyze traffic for testing opportunities,” “generate regression tests,” “identify flaky behavior patterns” | Guides the agent toward security workflows: “follow penetration testing methodology,” “identify vulnerabilities by category,” “generate findings with severity ratings and remediation advice” |
| Accent color | Cyan — Ghost’s default accent, calm and professional | Red — signals the shifted context to security analysis, visually distinct so you always know which mode you’re in |
| Slide-over panels | Chat (AI agent), Addons (script engine), Extension (browser extension status), Rules (map rules), Breakpoints | Chat (AI agent), Attacker (Request Attacker tool), Frida (mobile runtime analysis), Security Tools (external scanner status), Scanner output |
| Flow visibility | Flows with source:security-test are hidden — QA engineers don’t need to see security probe traffic cluttering their test sessions | All flows visible, including security test flows. Security-generated flows show a “TEST” badge so you can distinguish real traffic from probes |
Security Sub-Modes
Section titled “Security Sub-Modes”Security mode adapts further based on whether you’re testing a web application or a mobile app:
Web Security Mode
Section titled “Web Security Mode”This is the default when no mobile device is connected to Ghost. The AI agent’s system prompt focuses on web application security:
- Browser extension tools are emphasized (for DOM interaction, form submission, page analysis)
- External scanners (Nuclei for vulnerability scanning, Dalfox for XSS testing, ffuf for fuzzing, etc.) are prioritized in tool selection
- The agent follows web-specific testing methodology: check CORS, CSP, cookie security, authentication flows, injection points, etc.
Mobile Security Mode
Section titled “Mobile Security Mode”This activates automatically when a mobile device is connected (iOS Simulator, Android emulator, or physical device). The agent’s system prompt adds mobile-specific directives:
- Frida tools become available — SSL pinning bypass, root/jailbreak detection bypass, function tracing, and custom script injection
- Inspector tools are added — element tree analysis, screenshot comparison, UI state inspection
- The agent considers mobile-specific attack vectors: insecure local storage, certificate pinning bypass, inter-app communication, deep link exploitation, etc.
The switch between web and mobile security is automatic — Ghost detects when a device connects or disconnects and adjusts accordingly.
Scan Modes — Controlling What the Agent Can Do
Section titled “Scan Modes — Controlling What the Agent Can Do”Security mode has three progressive levels that control how aggressive the AI agent’s testing can be. This is a safety mechanism — you decide how far the agent can go:
| Scan Mode | What the Agent Can Do | What It Can’t Do | When to Use |
|---|---|---|---|
| Passive | Analyze captured traffic only. Read requests and responses, identify patterns, flag potential vulnerabilities, generate reports. The agent never sends any network requests. | Cannot send HTTP requests, cannot run external scanners, cannot modify anything. Observation only. | Safe for production environments. Use this when you want security insights from existing traffic without any risk of affecting the target system. |
| Active-Safe | Everything in Passive, plus it can send read-only probes (GET requests) to test hypotheses. For example, it can check if a URL is accessible without authentication, or test if a different user’s data is returned for a different ID. | Cannot send requests that modify data (POST, PUT, DELETE). Cannot write to the target system. | Use when you want the agent to verify potential issues but don’t want it changing any data. Safe for most staging environments. |
| Active-Full | Everything in Active-Safe, plus it can send any HTTP method including POST, PUT, and DELETE. However, write operations require your explicit approval first. | Nothing — full capability. But the approval gate means you always have final say on write operations. | Use for thorough penetration testing in dedicated test environments. The agent will ask your permission before sending any request that could modify data. |
The Approval Gate
Section titled “The Approval Gate”In Active-Full mode, when the agent wants to send a request that could modify data (POST, PUT, PATCH, DELETE), it uses the request_approval tool. This creates an approval card in the chat that shows:
- The exact URL and HTTP method it wants to use
- The request headers and body it plans to send
- Why it wants to send this request (what vulnerability it’s testing)
You can Approve (the agent sends the request) or Deny (the agent skips this test and continues with the next step in its plan). This ensures you always have full control over what the agent does to the target system.
Agent Tool Registries
Section titled “Agent Tool Registries”Ghost maintains two completely separate tool registries — one for QA mode and one for Security mode. When you switch modes, the active registry changes, which means the AI agent has access to a completely different set of capabilities.
QA Tool Registry (up to ~54 tools)
Section titled “QA Tool Registry (up to ~54 tools)”The exact count depends on which optional integrations are active (extension connected, devices connected, TestRail configured). Here’s the full breakdown:
| Category | Tools | Purpose |
|---|---|---|
| Core traffic tools (15 base + 3 extension) | search_traffic, get_flow, get_flow_body, find_endpoints, get_traffic_stats, tag_flows, replay_request, list_sessions, list_journeys, annotate_flow, list_ws_messages, list_console_errors, list_navigations, list_storage_changes, analyze_requirements + (highlight_element, show_toast, annotate_element if extension connected) | Searching, reading, and annotating captured traffic. These are shared with security mode. |
| QA-specific tools (7) | generate_test, generate_bug_report, detect_regression, export_as, generate_api_docs, generate_mock_server, generate_test_scenarios | Generating test scripts (Playwright, Cypress, Appium, etc.), creating bug reports, detecting API regressions, exporting data, generating API documentation, mock servers from traffic, and test scenario outlines |
| Advanced QA tools (5) | generate_session_report, fuzz_endpoint, test_form, run_k6, run_hey | Session analysis reports, basic endpoint fuzzing, automated form testing, and load testing with k6 and hey |
| Plan tools (5) | create_plan, revise_plan, complete_step, think, present_options | Structured task planning — the agent creates a step-by-step plan and works through it methodically. think provides private reasoning, present_options presents interactive choices to the user. |
| Inspector tools (7, if device connected) | get_device_screen, get_element_tree, find_elements, get_element_selectors, correlate_element_traffic, tap_device, type_device | Mobile device inspection — screenshots, UI element trees, selector generation, traffic-UI correlation, and device input |
| Browser tools (6, if extension connected) | browser_read_page, browser_query_all, browser_click, browser_fill, browser_screenshot, browser_inject | Controlling the browser via the extension — reading page structure, querying DOM, clicking elements, filling forms, capturing screenshots, and injecting UI overlays |
| Workspace tools (3) | fs_write, fs_read, fs_list | Writing, reading, and listing files in the session workspace (test scripts, reports, artifacts) |
| Proxy injection (1, conditional) | proxy_inject_script | Injecting JavaScript into proxied HTML responses via interceptor |
| TestRail integration (4, if configured) | testrail_list_projects, testrail_get_cases, testrail_push_results, testrail_suggest_cases | TestRail integration — list projects, get test cases, push results, and AI-suggested test case matching |
Security Tool Registry (up to ~60 tools)
Section titled “Security Tool Registry (up to ~60 tools)”| Category | Tools | Purpose |
|---|---|---|
| Core traffic tools (15 base + 3 extension) | Same as QA | Shared foundation for traffic analysis |
| Security-specific tools (22) | list_findings, send_http_request, get_page_resources, request_approval, attack_request, list_wordlists, frida_check, frida_list_apps, frida_bypass_ssl, frida_root_bypass, frida_trace, frida_inject, run_nuclei, run_dalfox, run_ffuf, run_sqlmap, run_trufflehog, run_katana, run_semgrep, run_nmap, run_sslscan, run_hydra | Security analysis, request crafting, approval gates for write operations, mobile runtime manipulation (Frida), and 10 external security scanners. Note: analysis tasks like auth pattern analysis, JWT decoding, sensitive data detection, IDOR testing, security header auditing, and PoC generation were removed as tools — the LLM handles these directly from raw flow data without needing dedicated tooling. |
| Plan + Inspector + Browser + Workspace + Proxy Inject (22) | Same as QA (minus QA-specific and TestRail) | Shared planning (including think and present_options), device inspection, browser control, file management, and script injection |
Shared Infrastructure
Section titled “Shared Infrastructure”Despite the dramatic UI and agent transformation, both modes share the same underlying infrastructure:
- Same proxy — traffic capture works identically regardless of mode
- Same interceptor pipeline — breakpoints, map rules, addons, storage, and security scanning all run the same way
- Same SQLite database — flows, sessions, conversations, and findings are all stored together
- Same WebSocket hub — real-time updates work the same way
- Same session management — sessions don’t belong to a mode; you can capture traffic in QA mode and switch to Security mode to analyze the same flows
- Same device manager and inspector — mobile device connections persist across mode switches
- Same extension connection — the browser extension stays connected when you switch modes
The mode switch is purely a UI and agent persona transformation — the underlying engine is unified. This means you can seamlessly switch between QA and Security perspectives on the same traffic without losing any data or connections.