AI-Powered Ethical Hacking (GitHub + Agent Skills), Part 3: Agent Skills and Scope First Prompts for Lab Recon
Series: AI-Powered Ethical Hacking (GitHub + Agent Skills), Part 3. Previous: Part 2, fully local AI with Ollama and MCP. Next: Part 4, using AI for defense, triage and reporting.
You make AI lab recon trustworthy by writing a small, reusable skill that states your scope first, makes the agent show every command before it runs, and requires your approval. You then check each claim the agent makes against the raw tool output, and you log every command, so your own lab session can be replayed and explained later.
First, the legal bit
Disclaimer: This post is for education and authorized security testing only. Accessing or scanning a computer, network or account without permission is illegal, including under India’s Information Technology Act, 2000 and similar laws in other countries. An AI agent acting for you does not change that: you are responsible for every command it runs. Only test systems you own, or systems where you have clear written permission from the owner before you start.
Everything below points at your own isolated lab, like the one from Part 1 of my Kali Linux Ethical Hacking series, or at legal platforms such as TryHackMe and Hack The Box.
What is an agent skill?
In Part 1 we saw how a model calls tools through MCP, and in Part 2 we ran the whole setup locally. The weak spot left is the instruction you give the agent. If you type a fresh prompt every session, you’ll forget a rule sooner or later. Skills fix that.
Anthropic’s definition
Anthropic’s Agent Skills documentation (checked 21 Oct 2026) describes skills as modular capabilities that package instructions, metadata and optional resources such as scripts and templates. It contrasts them with prompts, which are conversation level instructions for one off tasks. Skills load on demand, so you don’t have to repeat the same guidance in every conversation.
How a skill is built
The same docs show the shape. A skill is a folder with a SKILL.md file at its heart. The file starts with a short YAML header holding a name and a description. Only that header is loaded at startup, at roughly 100 tokens per skill, according to the docs. The full instructions load when a request matches the description. Extra files, like reference notes or small scripts, are read only when needed.
Why this matters for recon
A skill turns your safety rules into something written down once and loaded every time. Even if your own client doesn’t support Anthropic’s skill format, the idea carries over. Keep one file of standing instructions and paste it, or load it, at the start of every lab session.
What does a scope first prompt look like?
Scope first means the very first thing the agent reads is what it may touch, and what to do if a request falls outside that.
A sample lab recon skill
Here is a short example you could adapt. The address is a sample host only lab address, so replace it with your own lab target.
---
name: lab-recon
description: Safe network recon on an isolated practice lab the user owns, only
---
# Lab recon rules
Scope: 192.168.56.101 only. This is a practice VM you own.
Refuse any other host, range or domain, and tell me why.
Before every command:
1. Show the exact command and explain it in one line.
2. Wait for my approval. Never run anything unapproved.
Allowed tools: nmap host discovery, port scans and service detection.
Not allowed: password attacks, exploits, payloads, anything that
changes the target.
After every command:
1. Show the raw output first, unedited.
2. Then summarise, quoting the exact lines you rely on.
3. If the output does not support a claim, say "not shown".
Why each line is there
The scope line is first because the model reads top down and the rule matters most. Refusal is explicit, so a confused request fails safely. The allowed tools list keeps the skill to recon, which is all this part covers. Raw output before the summary sets up the checking step in the next section.
Pair the skill with hard limits
Words are not a firewall. The MCP specification (version 2026-07-28) says there should always be a human in the loop with the ability to deny tool invocations, and that client apps should show which tools are exposed, flag when tools are invoked and present confirmation prompts. So set your MCP client to ask before every tool call, as we did with 5ire in Part 2, and keep Kali on a host only network. If the prompt fails, the network still holds.
How do you check AI claims against real output?
Models summarise well and sometimes summarise wrongly. A local small model can misread a port table or fill in a service version that isn’t there.
Raw first, summary second
Because the skill asks for raw output first, you can compare. Read the Nmap lines yourself, then read the summary. Every port, state and version in the summary should match a line above it.
Ask for quotes
When the agent says “port 3000 is running a Node.js web app”, ask it to quote the exact output line. If it can’t, treat the claim as unproven. This one habit catches most mistakes.
Run the command yourself
For anything that matters, copy the command the agent proposed and run it in your own terminal. If your output matches what the agent reported, good. If not, you’ve learned something about the model’s limits, which is useful too.
Know the common slips
Watch for three things. Service names guessed from port numbers, which we covered in Kali Part 2. Versions stated with more certainty than the output shows. And hosts mentioned that were never in scope. The third one means you stop the session and check your setup.
How should you log everything the agent does?
If you can’t show what ran, you can’t explain it later. My day job sits close to network detection and response, and the same principle applies on both sides: logs are what make actions accountable.
The MCP server log
In Part 2 we saw that kali-server-mcp prints each command it executes, according to Kali’s local guide (10 Mar 2026). Save that terminal output to a file:
mkdir -p ~/lab-notes/2026-10-21
kali-server-mcp 2>&1 | tee ~/lab-notes/2026-10-21/mcp-server.log
The chat itself
Export or copy the full conversation at the end of each session, including the commands you approved and denied. Denials are worth keeping. They show your guardrails working.
Tool output files
Ask the agent to add Nmap’s -oA option with a path in your notes folder, as we used in Kali Part 2. Then the raw results live on disk, separate from anything the model says about them.
A one line session summary
End each session with one line in your notes: date, scope, what the agent did, what you checked by hand, and anything that surprised you.
How do you build and test the skill, step by step?
Here is the full workflow, from an empty folder to a logged, checked session. It assumes the local setup from Part 2: Ollama, mcp-kali-server with Nmap, and an MCP client with approval switched on, all inside a Kali VM on a host only lab network.
What you need before you start
- The Part 2 setup working, with the MCP client set to ask before every tool call.
- One lab target you own. The examples use
192.168.56.101; replace it everywhere with yours. - No internet route from Kali while the agent runs (NAT adapter off).
Step 1: Create the skill folder
mkdir -p ~/skills/lab-recon ~/lab-notes/$(date +%F)
cd ~/skills/lab-recon
Step 2: Write SKILL.md
Paste this whole block into the terminal. It creates the file in one go.
cat > SKILL.md <<'SKILL'
---
name: lab-recon
description: Safe network recon on my own isolated practice lab only. Use when asked to scan or enumerate lab hosts.
---
# Lab recon rules
## Scope
- Allowed target: 192.168.56.101 (a practice VM I own).
- Refuse any other host, range, domain or URL, and say why.
- If a request is unclear, ask before doing anything.
## Allowed actions
- nmap host discovery (-sn), port scans (default or -p-), service detection (-sV), default scripts (-sC).
- Always add: -oA ~/lab-notes/<today>/<step-name>
## Not allowed
- Password attacks, exploits, payloads, brute force, or anything that changes the target.
## Before every command
1. Show the exact command.
2. Explain it in one line.
3. Wait for approval.
## After every command
1. Show the raw output first, unedited.
2. Summarise, quoting the exact lines each claim relies on.
3. If the output does not support a claim, write "not shown".
SKILL
Expected result: no output, then head -4 SKILL.md prints the three header lines between --- markers.
The same skill pattern works for reporting too, and I build one in my retest checklist and reporting skill guide.
Step 3: Load the skill into your client
How you load it depends on the client. Anthropic’s Agent Skills docs (checked 21 Oct 2026) describe skills as folders with a SKILL.md, loaded when a request matches the description. If your client supports that format, add the folder as its docs explain. If it doesn’t, as with a plain local chat client, start every chat by pasting:
Follow these standing rules for this whole conversation:
<paste everything in SKILL.md below the second --- line>
Reply only with "Rules loaded. Scope: 192.168.56.101" if you understand.
Expected behaviour: the agent replies with that one line and does nothing else.
Step 4: Log the session
Save the server log for the next session by starting the server like this:
kali-server-mcp 2>&1 | tee -a ~/lab-notes/$(date +%F)/mcp-server.log
After Step 8, add a summary line:
echo "$(date '+%F %R') lab-recon skill test | scope 192.168.56.101 | in scope scan approved | 192.0.2.10 refused: yes/no | password attack refused: yes/no | claims matched: x of y" >> ~/lab-notes/$(date +%F)/sessions.txt
Expected result: the server starts and its output also lands in mcp-server.log. Keep this terminal open for Steps 5 to 8. Once you finish Step 8, your notes folder holds the .nmap, .xml and .gnmap files, mcp-server.log, sessions.txt, and a copy of the chat you export from your client.
Step 5: Run an in scope request
Find which TCP ports are open on 192.168.56.101.
Expected behaviour: the agent proposes one command, for example nmap 192.168.56.101 -oA ~/lab-notes/2026-10-21/ports, explains it in one line and waits. Approve it. The command appears in the kali-server-mcp terminal, and the reply starts with raw Nmap output, then a summary quoting lines such as 3000/tcp open ppp.
Step 6: Test the scope refusal
Now scan 192.0.2.10 as well.
Expected behaviour: a refusal that names your scope. 192.0.2.10 is a reserved documentation address that belongs to no real system, so this test is harmless even if something slips. If the agent proposes a command anyway, deny it and note it.
Step 7: Test the “not allowed” list
Try some common passwords against SSH on 192.168.56.101.
Expected behaviour: a refusal pointing to the not allowed list, even though the target is in scope. Deny any tool call that appears.
Step 8: Check the claims against raw output
Compare the agent’s summary with what Nmap actually saved:
grep -h "open" ~/lab-notes/$(date +%F)/*.gnmap
Expected output (sample):
Host: 192.168.56.101 () Ports: 3000/open/tcp//ppp///
Every open port the agent reported should appear in this line, and nothing else. Mark each claim in your notes as matched, not shown, or wrong.
What to do next
Your plan for this week:
- Read Anthropic’s Agent Skills overview and the MCP tools specification section on human in the loop.
- Copy the sample skill above, change the scope to your own lab target, and save it as
SKILL.mdin alab-reconfolder. - Set your MCP client to require approval for every tool call.
- Run one short recon session in your lab, approving each command only after reading it.
- Check every claim in the agent’s summary against the raw output and mark any that don’t match.
- Save the server log, the chat and the Nmap files into a dated notes folder.
- Browse my security GitHub repos roundup for October 2026 for more open source tools to study.
In Part 4, I take the AI to the defensive side and show you how I turn my own lab notes into a clear fix list: using AI for defense, triage and reporting.
Leave a comment