# HexStrike AI: What 150+ Security Tools in an MCP Server Reveal About Agent Sandboxing > Source: > Published: 2026-09-29 00:07:12+00:00 HexStrike AI is an MCP server that exposes 150+ offensive security tools to AI agents. It supports Claude, GPT, Copilot, and other LLMs, letting them autonomously run penetration testing tools, vulnerability scanners, and exploit frameworks. The project has 12,218 GitHub stars and is trending at rank #3 for Python repositories. This creates an interesting architectural problem: how do you give an agent access to tools designed to break systems while preventing the agent from breaking your own infrastructure? The MCP (Model Context Protocol) server pattern provides one answer, but the implementation details expose fundamental questions about tool boundaries, permission models, and audit trails. An MCP server acts as a bridge between LLMs and external tools. The agent sends a tool invocation request over the MCP protocol, the server executes the tool, and returns structured output. For low-risk tools like calculators or web searches, this is straightforward. For offensive security tools, every layer needs additional guardrails. HexStrike AI exposes tools across multiple categories: Each tool has different input requirements, output formats, and failure modes. The MCP server must normalize these into a consistent interface that agents can reason about. The core isolation question is: when an agent chains together three tools (port scan, vulnerability scan, exploit attempt), how do you prevent the exploit from escaping the intended target and attacking the MCP server itself? Standard approaches include: **Container-per-invocation**: Spin up a fresh Docker container for each tool execution, destroy it after output collection. This provides strong isolation but adds latency (2-5 seconds per tool call) and resource overhead. **Namespace isolation**: Use Linux namespaces to isolate network, process, and filesystem access. Faster than containers but requires careful configuration of capabilities and seccomp filters. **Proxy-based boundaries**: Route all tool network traffic through a transparent proxy that enforces allowlists for target IPs and blocks internal network ranges. Requires tools to respect proxy settings. **Filesystem sandboxing**: Mount tool directories read-only, provide ephemeral writable scratch space, and scan outputs before returning them to the agent. Prevents tools from modifying their own binaries or planting persistence. HexStrike AI's architecture diagram shows a "Security Sandbox Layer" between the MCP server and the tools, but the implementation details matter. A sandbox that blocks outbound connections breaks half the tools. A sandbox that allows arbitrary network access breaks containment. The MCP protocol supports tool invocation without human approval. This is necessary for agent autonomy but dangerous for offensive tools. If an agent decides to run `sqlmap` against a production database, you want a circuit breaker. Three permission models appear in MCP server implementations: | Model | Approval Flow | Agent Autonomy | Audit Complexity | |---|---|---|---| | **Pre-approved allowlist** | Admin defines safe tool/target pairs upfront | High within bounds | Low (violations are clear) | | **Just-in-time approval** | Human approves each high-risk invocation | Low (blocks on human) | Medium (approval latency) | | **Risk-scored auto-approval** | System scores tool+target risk, auto-approves below threshold | Medium (tunable) | High (scoring logic is opaque) | For penetration testing workflows, pre-approved allowlists work well. You define the target scope (IP ranges, domains, credentials) during engagement setup, and the agent can autonomously run any tool against those targets. Invocations outside the scope are rejected at the MCP server layer. The challenge is scope drift. An agent that discovers a new subdomain during reconnaissance needs to either request scope expansion or ignore the finding. Fully autonomous agents will push against these boundaries. Offensive security tools are designed to evade detection. They randomize user agents, spoof source IPs, and avoid leaving logs. This conflicts with the audit requirements for an MCP server. You need to log: The last item is the hardest. If an agent runs `nmap -sV -p- target.com`, you can log the command. But if the agent then runs `searchsploit Apache 2.4.49` based on the nmap output, you need to capture the reasoning chain that connected those two actions. Otherwise, your audit log is just a list of tool executions with no causal structure. MCP servers can request agent reasoning through the protocol's "thoughts" field, but this is optional and agents often omit it to reduce token usage. Forcing agents to explain every tool invocation adds latency and cost. Penetration testing workflows are stateful. An agent might: `nmap` to discover open ports`nikto` against discovered web servers`sqlmap` against forms found by `hashcat` against password hashes dumped by Each step depends on outputs from previous steps. The MCP server needs to manage this state without leaking it between different agent sessions or targets. Two patterns emerge: **Session-scoped state**: Each agent conversation gets an isolated state store (Redis namespace, SQLite database, filesystem directory). Tools can write intermediate outputs to the state store, and subsequent tools can read from it. The state store is destroyed when the session ends. **Explicit state passing**: Agents must explicitly pass outputs between tools. If `nmap` finds port 80 open, the agent must include that information in the `nikto` invocation. No shared state, but more verbose tool calls. Session-scoped state is more ergonomic but harder to audit. If an agent runs 50 tools in a session, you need to reconstruct the dependency graph from logs to understand what data flowed where. Security tools fail frequently. Targets are unreachable, credentials are wrong, payloads are blocked by WAFs, and tools crash on malformed input. An MCP server for offensive tools needs to handle these failures gracefully. Common failure scenarios: **Tool timeout**: A port scan takes 10 minutes instead of 30 seconds. Do you kill it and return partial results, or let the agent wait? **Credential exhaustion**: An agent burns through all available credentials for a service. Do you block further attempts, or let it continue with anonymous access? **Rate limiting**: A target blocks requests after 100 in 60 seconds. Do you queue subsequent requests, or fail fast and let the agent adjust its strategy? **Sandbox escape attempt**: A tool tries to write to `/etc/passwd` or connect to an internal IP. Do you kill the tool, kill the session, or just log and continue? The MCP protocol has a standard error response format, but it does not distinguish between "tool failed because target is down" and "tool failed because sandbox blocked it." Agents need this distinction to adjust their behavior. The most interesting failure mode is: what happens when an agent discovers a vulnerability in the MCP server's own sandbox? If the sandbox uses a known-vulnerable version of Docker, and the agent has access to CVE databases and exploit tools, it could theoretically: This is not hypothetical. Agents with access to `linpeas` (Linux privilege escalation scanner) will run it inside the sandbox. If `linpeas` reports a vulnerable kernel or misconfigured capability, the agent might attempt exploitation. Defenses include: `uname`, `cat /proc/version`, etc.) The fundamental tension is that you cannot give an agent offensive tools and also prevent it from using those tools against your infrastructure. You can only make your infrastructure hard enough that the agent's success rate is low. HexStrike AI is owned by OTT Cybersecurity LLC, suggesting commercial deployment. Likely shapes include: **Managed service**: Customers connect their LLM to a hosted MCP server. The service provider handles sandboxing, tool updates, and compliance. Customers define target scopes through an API. **On-premises appliance**: Customers deploy the MCP server inside their own network. This allows testing of internal systems without exposing them to a third party. Requires customers to manage sandboxing and updates. **Hybrid**: Reconnaissance and scanning run in the cloud, exploitation and post-exploitation run on-premises. Reduces data exfiltration risk but complicates state management. For bug bounty automation, the managed service model works well. For red team engagements against sensitive targets, on-premises is required. Here is a simplified example of how an MCP server might wrap a security tool with scope enforcement: ``` python import subprocess import ipaddress from typing import Dict, Any class ScopedToolExecutor: def __init__(self, allowed_targets: list[str]): self.allowed_networks = [ ipaddress.ip_network(t) for t in allowed_targets ] def is_target_allowed(self, target: str) -> bool: try: ip = ipaddress.ip_address(target) return any(ip in net for net in self.allowed_networks) except ValueError: # Handle domain names by resolving first return False def execute_nmap(self, target: str, flags: str) -> Dict[str, Any]: if not self.is_target_allowed(target): return { "error": "Target outside approved scope", "target": target, "allowed_ranges": [str(n) for n in self.allowed_networks] } # Execute in isolated namespace with timeout cmd = ["unshare", "--net", "--pid", "--fork", "nmap", flags, target] try: result = subprocess.run( cmd, capture_output=True, timeout=300, text=True ) return { "stdout": result.stdout, "stderr": result.stderr, "returncode": result.returncode } except subprocess.TimeoutExpired: return {"error": "Tool execution timeout"} ``` This enforces IP-based scope checking and uses Linux namespaces for isolation. Real implementations need domain resolution, CIDR range expansion, and more sophisticated timeout handling. Use HexStrike AI or similar MCP security tool servers when: Avoid when: The MCP server pattern for offensive tools is viable, but it shifts the security boundary from "prevent agents from accessing dangerous tools" to "prevent agents from misusing dangerous tools they already have access to." That is a harder problem, and the tooling is still immature.