AI-Assisted Penetration Testing Lab

MCP-Based Security Tool Orchestration

A controlled proof-of-concept demonstrating how an AI agent can orchestrate cybersecurity reconnaissance tools through the Model Context Protocol (MCP) against an authorized local OWASP Juice Shop laboratory.

For authorized cybersecurity laboratory testing and educational purposes only.

Related MCP server: pentestMCP

Overview

This project explores a simple question:

Can an AI agent coordinate conventional penetration-testing reconnaissance tools without being given unrestricted shell access?

Instead of allowing the LLM to execute arbitrary operating-system commands, this prototype exposes a small set of bounded security tools through a custom MCP server.

The final implementation successfully orchestrated four controlled reconnaissance functions:

1. Target reachability verification

2. HTTP response-header inspection

3. Nmap service reconnaissance

4. Web content enumeration using ffuf

The evidence produced by these tools was then correlated by an LLM into a concise reconnaissance assessment.

No exploitation was performed.

Final Architecture

The completed prototype uses a hybrid architecture:

User
  │
  ▼
AnythingLLM
  │
  ▼
Gemini 3.1 Flash Lite
  │
  │ Tool requests
  ▼
Custom MCP Server (Node.js)
  │
  ├── check_juice_shop
  │       └── HTTP reachability check
  │
  ├── inspect_juice_shop
  │       └── HTTP header inspection
  │
  ├── scan_local_lab
  │       └── Nmap
  │
  └── enumerate_local_web
          └── ffuf
                │
                ▼
       OWASP Juice Shop
       127.0.0.1:3000
                │
                ▼
             Evidence
                │
                ▼
     AI-Assisted Assessment

The reasoning model is cloud-based, while the security target, MCP server, and reconnaissance tools remain local.

In simplified form:

Cloud LLM
    ↓
AnythingLLM Agent
    ↓
Local MCP Server
    ↓
Local Security Tools
    ↓
Authorized Local Lab

Technology Stack

Authorized Scope

The security target is deliberately restricted to:

127.0.0.1:3000

This is the locally hosted OWASP Juice Shop laboratory.

The MCP tools do not accept arbitrary Internet targets.

This restriction is an intentional part of the design.

MCP Security Tools

The custom MCP server exposes four bounded tools.

1. check_juice_shop

Purpose:

Verify whether the authorized local OWASP Juice Shop laboratory is reachable.

The tool performs an HTTP request against:

http://127.0.0.1:3000

Example evidence obtained during testing:

HTTP 200 OK

The result confirmed that the target application was running and reachable.

2. inspect_juice_shop

Purpose:

Inspect HTTP response headers returned by the authorized local application.

Evidence observed during the experiment included headers such as:

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Access-Control-Allow-Origin: *
X-Recruiting: /#/jobs

This tool provides application-level reconnaissance evidence without attempting exploitation.

3. scan_local_lab

Purpose:

Perform controlled service reconnaissance against the authorized local target.

The equivalent Nmap command is:

nmap -sT -sV -p 3000 127.0.0.1

Both the target and port are defined by the MCP server.

The LLM cannot provide an arbitrary host to this function.

The experiment confirmed:

Host: 127.0.0.1
Port: 3000/tcp
State: open

The service returned HTTP responses and was confirmed to be the local Juice Shop application.

4. enumerate_local_web

Purpose:

Perform controlled web content enumeration against the authorized Juice Shop application.

The tool invokes ffuf against:

http://127.0.0.1:3000/FUZZ

using a small project-specific wordlist.

The experiment discovered resources including:

/robots.txt
/security.txt
/assets
/ftp

Why Response Filtering Was Necessary

OWASP Juice Shop is a Single Page Application (SPA).

During initial enumeration, several paths appeared to return:

HTTP 200

even when they did not represent unique resources.

For example, several routes returned the same application HTML response with an identical response size.

This creates potential false positives during directory enumeration.

The enumeration workflow therefore incorporated response-size filtering to distinguish the generic SPA fallback page from resources with different responses.

This was an important practical lesson from the experiment:

A successful HTTP status code does not necessarily prove that a unique endpoint exists.

Security-tool output still requires interpretation and validation.

Safety by Design

One of the main design goals of this project is to avoid providing an LLM with unrestricted command execution.

A conventional autonomous-agent design could potentially look like:

LLM
 ↓
Shell
 ↓
Arbitrary command
 ↓
Arbitrary target

This prototype instead uses:

LLM
 ↓
Approved MCP Function
 ↓
Predefined Security Operation
 ↓
Authorized Local Target

For example, the Nmap MCP tool internally defines:

Target = 127.0.0.1
Port   = 3000

The agent therefore requests:

scan_local_lab()

rather than constructing an unrestricted command against an arbitrary host.

The same principle is used for web enumeration.

This provides a basic security boundary between AI reasoning and security-tool execution.

Experimental Workflow

Phase 1 — Local Target Environment

OWASP Juice Shop was deployed locally using Docker.

The application was accessible at:

http://127.0.0.1:3000

This provided an intentionally vulnerable application specifically designed for cybersecurity education and testing.

Phase 2 — Custom MCP Server

A custom MCP server was implemented using Node.js and the Model Context Protocol SDK.

The MCP server was first validated independently using MCP Inspector.

This allowed each security function to be tested before introducing the AI agent.

Phase 3 — Reachability Testing

The first MCP function was:

check_juice_shop

The tool successfully contacted the local target and returned:

HTTP 200

This established the first complete path:

MCP Client
   ↓
MCP Server
   ↓
Local Web Application
   ↓
Structured Evidence

Phase 4 — HTTP Inspection

The second tool:

inspect_juice_shop

retrieved response headers from the application.

This demonstrated that the MCP server could collect application reconnaissance evidence and return it in structured form to an AI client.

Phase 5 — Nmap Integration

Nmap was then integrated as:

scan_local_lab

The tool executed a restricted scan against:

127.0.0.1:3000

The scan confirmed that TCP port 3000 was open and responding as the Juice Shop web application.

Phase 6 — Web Enumeration

The fourth MCP function integrated ffuf:

enumerate_local_web

The initial enumeration exposed an important issue with SPA fallback responses.

After filtering generic responses, useful resources included:

robots.txt
security.txt
assets
ftp

Phase 7 — AI Agent Orchestration

After the MCP tools were individually validated, they were exposed to an AnythingLLM agent.

The agent was instructed to:

1. Verify target reachability

2. Inspect HTTP headers

3. Run controlled Nmap reconnaissance

4. Perform controlled content enumeration

5. Correlate evidence

6. Produce a reconnaissance assessment

The agent successfully invoked all four MCP tools.

Final End-to-End Result

The completed workflow was:

Gemini 3.1 Flash Lite
        ↓
AnythingLLM Agent
        ↓
Custom MCP Server
        ↓
┌──────────────────────────────┐
│ check_juice_shop             │
│ inspect_juice_shop           │
│ scan_local_lab               │
│ enumerate_local_web          │
└──────────────────────────────┘
        ↓
Nmap + ffuf + HTTP inspection
        ↓
OWASP Juice Shop
127.0.0.1:3000
        ↓
Evidence
        ↓
AI-Assisted Reconnaissance Report

All four MCP functions were successfully executed within the authorized local scope.

Evidence

1. MCP Server Connected

The custom MCP server was successfully connected and validated.

2. Target Reachability — HTTP 200

The MCP reachability function confirmed that OWASP Juice Shop was available at the authorized localhost target.

3. HTTP Header Inspection

The second MCP function successfully collected HTTP response-header evidence.

4. Controlled Nmap Scan

Nmap was successfully executed through the bounded MCP function.

5. MCP Tools Available to AnythingLLM

The MCP integration exposed the security functions to the AI agent.

6. Agent Tool Orchestration

The AnythingLLM agent successfully invoked MCP security tools during the reconnaissance workflow.

7. Final AI-Assisted Assessment

The final experiment produced an evidence-based reconnaissance assessment.

Final Four-Tool Execution

The final AnythingLLM experiment demonstrated successful execution of all four security functions:

check_juice_shop
inspect_juice_shop
scan_local_lab
enumerate_local_web

The resulting assessment correlated evidence from HTTP inspection, Nmap, and ffuf.

The final assessment included confirmed observations, potential concerns, and recommended additional validation.

The completed AnythingLLM session used Gemini 3.1 Flash Lite for reasoning.

Reconnaissance Results

The final assessment collected the following evidence.

Connectivity

Target: 127.0.0.1:3000
HTTP Status: 200

HTTP Inspection

Observed headers included:

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Feature-Policy: payment 'self'
X-Recruiting: /#/jobs

Network Reconnaissance

Nmap confirmed:

3000/tcp open

Web Enumeration

The filtered ffuf enumeration identified:

/robots.txt
/security.txt
/assets
/ftp

Interpretation of Findings

An important distinction in this experiment is the difference between:

Evidence
Observation
Potential Concern
Confirmed Vulnerability

These are not equivalent.

For example:

/ftp is accessible

is an evidence-supported observation.

However:

/ftp contains sensitive information

cannot be concluded without inspecting its contents.

Therefore, discovering an accessible /ftp endpoint does not automatically prove a vulnerability.

This distinction is particularly important when LLMs are used for cybersecurity analysis because generated reports can otherwise sound more certain than the underlying evidence supports.

AI Assessment Behavior

The AI was instructed to base conclusions only on actual tool evidence and not to claim vulnerabilities without sufficient support.

The final report separated:

• tools executed

• evidence collected

• confirmed observations

• potential security concerns

• uncertain findings

• recommended next tests

This evidence-first structure is important for reducing unsupported AI conclusions.

Human validation remains necessary.

Local LLM Experiment

Before using Gemini for the final agent workflow, local LLM execution was also evaluated using Ollama.

Models tested included:

Qwen3 4B
Qwen3 0.6B

The local environment had limited unified memory while simultaneously running components such as:

• AnythingLLM

• Docker

• OWASP Juice Shop

• Ollama

• MCP

• security tooling

Qwen3 4B was capable of ordinary local inference but created substantial resource pressure when combined with the complete agent environment.

Qwen3 0.6B required significantly fewer resources but was not sufficiently reliable for the desired agent/tool orchestration workflow.

The final prototype therefore adopted a hybrid approach:

Cloud reasoning
      +
Local execution

Specifically:

Gemini
   ↓
AnythingLLM
   ↓
Local MCP
   ↓
Local security tools
   ↓
Local authorized lab

This preserved local control over security-tool execution while moving LLM reasoning away from the resource-constrained machine.

Key Lessons

Several practical lessons emerged from the experiment.

1. AI does not require unrestricted shell access

Useful security-tool orchestration can be implemented through narrowly defined functions.

2. MCP can act as a control boundary

MCP provides a structured interface between LLM reasoning and external security tools.

3. Tool output is evidence, not automatically a vulnerability

The existence of an endpoint, header, or open port still requires security interpretation.

4. HTTP 200 can produce false positives

Single Page Applications may return the same application shell for many paths.

5. Security enumeration requires validation

Filtering and manual verification remain important even when tools are automated.

6. Small local models have practical limitations

A model that can answer ordinary prompts may still struggle with multi-step agent orchestration and tool use.

7. Hybrid AI architectures can be practical

Cloud reasoning can be combined with tightly controlled local execution.

8. Human oversight remains essential

The LLM assists with orchestration and evidence interpretation; it does not replace security validation.

Security Boundaries

This proof-of-concept intentionally limits its capabilities.

The current implementation:

• targets localhost only

• targets a predefined port

• uses an intentionally vulnerable laboratory application

• exposes predefined MCP functions

• does not provide unrestricted shell access to the LLM

• does not perform exploitation

• requires human supervision

These restrictions are intentional design features rather than limitations to be removed.

What This Project Does Not Claim

This project does not claim to be:

• an autonomous penetration-testing platform

• a replacement for professional penetration testers

• a vulnerability scanner

• an exploitation framework

• a production security assessment system

It is a proof-of-concept for studying controlled AI-assisted security-tool orchestration.

Repository Structure

ai-assisted-pentest-mcp/
│
├── evidence/
│   ├── 01-mcp-server-connected.png
│   ├── 02-http-check-200.png
│   ├── 03-http-header-inspection.png
│   ├── 04-nmap-mcp-scan.png
│   ├── 05-anythingllm-mcp-tools.png
│   ├── 06-agent-tool-orchestration.png
│   ├── 07-final-ai-assessment.png
│   ├── 05-final-four-tools-and-assessment.png
│   ├── 06-final-assessment-conclusion.png
│   └── 07-final-anythingllm-session.png
│
├── juice-wordlist.txt
├── package.json
├── package-lock.json
├── server.mjs
├── .gitignore
└── README.md

Running the MCP Server

Install dependencies:

npm install

Start or inspect the MCP server according to your MCP client configuration.

For development validation, MCP Inspector can be used to verify the exposed tools.

Example:

npx @modelcontextprotocol/inspector node server.mjs

The security laboratory itself must be running locally at:

http://127.0.0.1:3000

Ethical Use

This repository is intended exclusively for:

• cybersecurity education

• controlled laboratory experimentation

• authorized penetration-testing research

• AI/MCP security-tool integration experiments

Never scan, enumerate, probe, or test systems without explicit authorization.

The example target used by this repository is deliberately restricted to an authorized local OWASP Juice Shop instance.

Future Work

Potential extensions of the experiment include:

• structured JSON evidence output

• stronger validation of tool responses

• audit logging for every MCP invocation

• risk classification with explicit evidence references

• human approval gates before higher-risk actions

• additional read-only reconnaissance functions

• comparison of different LLMs for tool-selection reliability

• evaluation of hallucination rates in security assessments

• formal measurement of false-positive handling

• improved local-model experiments on larger-memory hardware

Any future security functionality should preserve explicit authorization, bounded scope, and human oversight.

Acknowledgement

This experiment was inspired by notes and discussions on AI-assisted penetration testing shared by Prof. Onno W. Purbo.

The implementation in this repository explores that concept through a controlled MCP-based architecture using bounded security functions and an authorized local OWASP Juice Shop environment.

Disclaimer

This project is a cybersecurity laboratory proof-of-concept.

Use security-testing tools only against systems that you own or for which you have explicit authorization.

The authors assume no responsibility for unauthorized or unlawful use of the concepts or code contained in this repository.