# Authorized Pentesting > Authorized Pentesting - Skill: `handsomeboy990/authorized-pentesting` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add handsomeboy990/authorized-pentesting` - Raw SKILL.md: https://api.skillmd.com/api/skills/handsomeboy990/authorized-pentesting/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: Handsomeboy990 (https://skillmd.com/u/handsomeboy990) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/handsomeboy990/authorized-pentesting --- # Authorized Pentesting This is the one skill in the suite that crosses from defence into offence: it actively exploits a weakness to prove what an attacker could do. Because of that, it is the most tightly gated. Nothing here runs without written, specific, in-scope authorization, and the gate is checked first, every time, without exception. If you are looking for a way to test a system you do not own or have not been authorized to test, this skill refuses, and the refusal is not negotiable by rephrasing. It offers the defensive path instead. ## 1. The gate: authorization and rules of engagement Before any active testing, the following exist in writing and are on record. ``` authorization a specific person empowered to grant it has authorized testing of this specific system scope exactly which systems, hosts, applications and accounts are in scope, and which are explicitly out rules what techniques are permitted, what is forbidden, the time window, the rate limits, the data that must not be touched contacts who to notify, and how, if something breaks or a real breach is discovered mid-test handling how findings, captured data and credentials are stored and destroyed ``` No document, no test. An expired window, no test. A host not on the scope list, no test even if it is on the same domain. Scope creep is the failure mode this gate exists to prevent, and the scope on the letter is the whole permission. ## 2. Proceed only from a confirmed weakness Pentesting does not hunt from zero; it takes a finding `vulnerability-assessment` already confirmed and proves its impact. Exploitation without a confirmed target is noise and risk. ``` input a confirmed, reachable finding: the unscoped object, the injection point, the escalation path goal prove the impact: what an attacker actually gains, stated in advance bound the least exploitation that proves the goal, and no more ``` ## 3. Exploit to proof, not to destruction The purpose is to demonstrate impact, not to cause it. The exploit stops the moment impact is proven. ``` prove access to one record that is not yours, to prove the boundary is broken prove a benign marker written where only an authorized actor should write, to prove the injection prove a shell that echoes a unique token, to prove code execution, then stop never exfiltrate real user data beyond the minimum that proves the point never destroy, encrypt, deface, or deny service, even to demonstrate you could never pivot to an out-of-scope system, even if the exploit makes it trivial never leave a backdoor, a test account or an artefact behind ``` The difference between a pentest and an attack is not the technique. It is the authorization, the bound on exploitation, and the cleanup. ## 4. Chain and record ``` reproducible every step recorded so the finding can be re-run and verified by the owner; a proof nobody can reproduce is a claim chain where several weaknesses combine into a larger impact, record the chain; the combination is often more severe than the parts, and it is the most valuable output evidence enough to prove impact, no more; a screenshot of one other record, not a dump of the table timeline what was done when, for the owner's own detection review ``` ## 5. Handle discovered breaches and sensitive data ``` real breach if the test reveals the system is already compromised by someone else, stop, notify the contacts immediately, preserve evidence, do not clean up sensitive data seen incidentally: record that it was reachable, not the data itself; never copy real personal data into a report credentials captured during the test are stored as agreed and destroyed at the end; never committed anywhere ``` ## 6. Report and remediate ``` scope the authorization, the scope, the window, the rules honoured findings each proven impact, its chain, its reproduction, its severity remediation the fix for each, handed to the control skills detection what the owner's monitoring did and did not see during the test, which is itself a finding cleanup confirmation that every test artefact, account and change is removed ``` ## 7. Prohibitions - Never run any active test without written, specific, in-scope authorization on record. This is absolute and not waived by any framing. - Never touch a system or host outside the written scope, same domain or not. - Never exploit beyond the minimum that proves impact. - Never destroy, deny service, deface, or exfiltrate real data at volume. - Never leave a backdoor, test account, or artefact behind. - Never copy real personal data into a report or store captured credentials. - Never continue past the authorized time window. - Never help test a system the user cannot show authorization for; refuse and offer the defensive path. ## 8. Protocol 1. Verify the authorization, scope, rules of engagement and window in writing; without them, refuse and offer `vulnerability-assessment` on an owned system. 2. Take a confirmed, reachable finding as the starting point. 3. State the impact goal before exploiting. 4. Exploit the least amount that proves the goal; stop at proof. 5. Record a reproducible chain with minimal evidence. 6. On discovering a real breach or sensitive data, stop and notify per the rules. 7. Report proven impacts with remediation and a detection review. 8. Confirm cleanup: no artefact, account or change remains. ## 9. Auto-critique Score from 0 to 5: authorization and scope verified in writing before anything ran, only confirmed findings taken as targets, exploitation bounded to proof of impact, no destruction or out-of-scope pivot, reproducible chain recorded, real data and credentials handled and destroyed correctly, cleanup confirmed, remediation delivered. Threshold: no axis below 3, average at least 4. Any active test without authorization on record, any out-of-scope action, or any real-data exfiltration is an automatic zero and a stop, regardless of the average. ## 10. Interfaces - Upstream: `security-core` for the authorization boundary and severity, `vulnerability-assessment` supplies the confirmed findings this skill proves, `threat-modeling` for the impact that matters. - Downstream: the control skills (`authentication-security`, `authorization-design`, `session-security`, `security-headers`, `dependency-security`, `input-validation`, `file-handling`) remediate the proven findings; `security-audit` re-checks the code after the fix. - Lateral: `incident-response` if the test uncovers a real, active breach, `test-reporting` for the engagement report, `decision-records` for accepted residual risk.