Problem
Three issues found during hackbrowser tool access audit:
1. Permission key mismatch (4 agents)
Sub-agent permission configs for web-application, mobile-application, cloud-security, and internal-network had browser: "allow" — but the hackbrowser tool registers with permission: "hackbrowser". No tool named "browser" exists in the registry.
Current impact: Benign — these agents inherit "*": "allow" from defaults, so hackbrowser is accessible via wildcard. But if any of these agents ever adopts a deny-by-default policy (like the vuln testers and orchestrator already have), hackbrowser access would silently break.
2. Phantom browser tool in prompts
Both cyberstrike.txt and web-application.txt prompts tell the agent "use the browser tool for targeted testing" — but no such tool exists. This causes LLMs to hallucinate a tool call that fails.
3. Misleading tool list
cyberstrike.txt lists "bash, browser, file operations" in core identity — referencing a non-existent tool.
Fix (committed to dev)
agent.ts: Changed browser: "allow" → hackbrowser: "allow" in all 4 sub-agent configs
cyberstrike.txt: "browser" → "hackbrowser" in tool list, "use the browser tool" → "use http_replay"
web-application.txt: "use the browser tool instead" → "use http_replay instead"
Commit: 3763146
Audit Summary
| Agent |
hackbrowser access |
Status |
| cyberstrike (main) |
✅ via *: allow defaults |
Correct |
| web-application |
✅ via *: allow + hackbrowser: allow |
Fixed |
| mobile-application |
✅ via *: allow + hackbrowser: allow |
Fixed |
| cloud-security |
✅ via *: allow + hackbrowser: allow |
Fixed |
| internal-network |
✅ via *: allow + hackbrowser: allow |
Fixed |
| proxy-agent (orchestrator) |
❌ *: deny + no whitelist |
Correct by design |
| proxy-analyzer |
❌ *: deny + no whitelist |
Correct by design |
| vuln testers (idor, authz, etc.) |
❌ *: deny + no whitelist |
Correct by design (line 727) |
Problem
Three issues found during hackbrowser tool access audit:
1. Permission key mismatch (4 agents)
Sub-agent permission configs for
web-application,mobile-application,cloud-security, andinternal-networkhadbrowser: "allow"— but the hackbrowser tool registers withpermission: "hackbrowser". No tool named"browser"exists in the registry.Current impact: Benign — these agents inherit
"*": "allow"from defaults, so hackbrowser is accessible via wildcard. But if any of these agents ever adopts a deny-by-default policy (like the vuln testers and orchestrator already have), hackbrowser access would silently break.2. Phantom
browsertool in promptsBoth
cyberstrike.txtandweb-application.txtprompts tell the agent "use thebrowsertool for targeted testing" — but no such tool exists. This causes LLMs to hallucinate a tool call that fails.3. Misleading tool list
cyberstrike.txtlists "bash, browser, file operations" in core identity — referencing a non-existent tool.Fix (committed to dev)
agent.ts: Changedbrowser: "allow"→hackbrowser: "allow"in all 4 sub-agent configscyberstrike.txt: "browser" → "hackbrowser" in tool list, "use thebrowsertool" → "usehttp_replay"web-application.txt: "use thebrowsertool instead" → "usehttp_replayinstead"Commit: 3763146
Audit Summary
*: allowdefaults*: allow+hackbrowser: allow*: allow+hackbrowser: allow*: allow+hackbrowser: allow*: allow+hackbrowser: allow*: deny+ no whitelist*: deny+ no whitelist*: deny+ no whitelist