cognita probe
Authorized penetration testing, driven by Claude, kept on a leash.
cognita probe is the testing tool behind cognita soc. Claude runs the test from your own Claude Code session, so there is no separate model key and no autonomous agent on the loose. Every command runs inside a sandbox container, is checked against the scope and window you authorised before it runs, and is logged with its full output. When the engagement ends, one file imports it into the Penetration Testing module.
Built on the open-source Strix sandbox and testing playbooks (Apache-2.0). cognita probe's own source is a private repository; this page is its public description.
you /pentest Northwind Online Banking staging, standard mode Claude sets up the engagement, then drives every probe through pt. pt init northwind-olb-2026-q4 --app "Northwind Online Banking" --target https://olb.northwind.example --max-rps 10 --authorized-by "Priya Natarajan (CISO)" --auth-ref PT-AUTH-2026-Q4-017 engagement created pt up # sandbox container up pt accounts nwb.tester1 login ok roles=['Customer'] nwb.tester2 login ok roles=['Customer'] pt authz --openapi https://api.northwind.example/openapi.json 142 routes x 3 principals -> evidence/authz-matrix.csv lead: GET /accounts/{id}/statements reached by another customer Claude confirms the lead by hand, then records it. pt finding new --sev critical --evidence 41 F-001 Account statement readable by changing the id in the URL pt export grc-package northwind-olb-2026-q4.zip -> import in Cognita GRC
- No model keyClaude drives the test from your Claude Code session; there is no separate API key and no autonomous agent.
- Every command sandboxedTools run in a Kali-based container, never on your machine; source is mounted read-only.
- Scope, window, logEach command is checked against what you authorised, then logged in full with a unique number.
- Imports into socThe engagement exports as one signed package for the Penetration Testing module.
Claude proposes a command; pt checks it, runs it in the sandbox, and logs it.
Nothing reaches the target directly. Claude writes each probe as a pt exec command; pt reads the command and any script it would run for URLs, IPs and host names, refuses anything outside the agreed scope or after the window, runs it in the container, masks secrets in the output and keeps it under a new log number.
- Authorise.
pt initrecords who approved the test, the scope, the testing window and the rules of engagement. The skill refuses to start without them. - Start the sandbox.
pt upbrings up one container for the engagement, with the application source mounted read-only. - Probe through
pt exec. Every network command goes through it, is scope- and window-checked, run in the container, masked and logged under a new number. - Record as you go. Claude writes each test case and each proven issue, citing log numbers as evidence, so a reviewer can re-trace the test command by command.
- Report and hand over.
pt reportcompiles the PDF;pt export grc-packagewrites the package cognita soc imports.
Strix's testing knowledge, without the Strix agent.
Strix is an open-source offensive-security toolkit. cognita probe reuses two parts of it under the Apache-2.0 licence: the Kali sandbox image and seventy-five testing playbooks. It does not run Strix's own autonomous agent and needs no model API key. Claude, in your Claude Code session, is the only thing driving the test.
Kali, with the tools a test needs
nmap, nuclei and its templates, sqlmap, ffuf, httpx, katana, nikto, testssl, gobuster, feroxbuster, jwt_tool, semgrep, trivy, gitleaks and Playwright with Chromium, plus a trimmed SecLists.
Read on demand, not run blind
Vulnerability classes, frameworks, protocols and cloud. Claude reads the playbook for a risk area before testing it, for example the IDOR playbook before the authorization matrix.
Your plan, not a pay-per-call agent
Because Claude in Claude Code drives the test, it runs on your Claude Code plan. No model key is configured, and no agent acts outside the commands you can see and re-run yourself.
Set up, check the accounts, then work through the methodology.
Claude follows OWASP's Web Security Testing Guide and API Security Top 10, one phase at a time. Everything below is a command you can run yourself; Claude just runs it for you and records what it finds.
pt init northwind-olb-2026-q4 --app "Northwind Online Banking" \ --target https://olb.northwind.example --target https://api.northwind.example \ --authorized-by "Priya Natarajan (CISO)" --auth-ref PT-AUTH-2026-Q4-017 \ --end 2026-10-17 --account "nwb.tester1 customer" --account "nwb.tester2 customer" \ --max-rps 10 engagement northwind-olb-2026-q4 created fill in creds.env with the test-account passwords or tokens pt up sandbox up (pentest-kit-sandbox) pt login --set --url https://api.northwind.example/auth/token --order nwb.tester1,nwb.tester2 pt accounts nwb.tester1 login ok whoami 200 roles=['Customer'] nwb.tester2 login ok whoami 200 roles=['Customer'] ! both accounts look like the same role — add an admin for full coverage
pt accounts warns when coverage is thin, so a gap is caught before testing rather than discovered in the report.pt exec --purpose "recon: fingerprint" -- 'httpx -u https://olb.northwind.example -td -server -title' [0007] nginx · Northwind Online Banking · React pt authz --openapi https://api.northwind.example/openapi.json 142 routes x 3 principals (anonymous, nwb.tester1, nwb.tester2) -> evidence/authz-matrix.csv lead: GET /api/v2/accounts/{id}/statements reachable by nwb.tester1 for another customer's id Claude confirms the lead by hand with a real object, recording the exchange. pt exec --proxy --purpose "authz: statement IDOR" -- 'cd scripts && python3 idor_statements.py' [0041] tester1 -> GET /accounts/88002/statements/2026-09 200 OK (another customer's PDF) pt finding new --sev critical --evidence 41 \ --title "Account statement readable by changing the id in the URL" F-001 recorded CWE-639 · A01:2021 Broken Access Control pt report report.pdf · report.html (12 findings · 18 tests) pt export grc-package northwind-olb-2026-q4.zip -> Cognita GRC: Cybersecurity -> Penetration Testing
| Depth | What runs | Claude Code usage |
|---|---|---|
| Quick | Setup, account check, recon, the authorization matrix, configuration and authentication checks, injection on the riskiest inputs. | Lowest |
| Standard | Every methodology phase, a written threat model, and the Strix playbook for each risk area. | Moderate |
| Deep | Standard, plus parallel specialist subagents per risk area, a white-box source review, and a second pass on every follow-up. | Highest |
A tool that runs real attacks, held to what you authorised.
| Control | How |
|---|---|
| Authorization | Setup requires who approved the test; the approver, reference and window go into every report, and the skill refuses to start without them. |
| Testing window | Commands are refused after the end date you set. |
| Scope | Every command, and any script it runs, is read for URLs, IPs and host names first. Out-of-scope or excluded targets are blocked; an override is explicit and recorded. |
| Rate limits | Your maximum request rate is applied by the authorization sweep and passed to every other tool's rate flag. |
| Writes | Unless you allow writes, only read routes are replayed and data-changing tests stop at the point of proof. |
| Secrets | Test-account values are replaced by their names in every log; tokens, cookies, keys and partial key hints are masked by shape too, in the logs and the report. |
| Isolation | Tools run in the container, not on your machine, and the application source is mounted read-only. |
| Audit trail | Every command gets a unique number and its full output is kept, even when several run at once. |
The hard rules Claude follows: written authorization and scope before any test; every network command through pt exec; no denial of service, password spraying or lockout loops; no destructive changes unless writes are allowed; a finding needs a working reproduction; stop and ask on real customer data or anything critical.
The engagement arrives as records, not a PDF to retype.
pt export grc-package writes one signed zip: the engagement, every finding with its evidence and retest history, every test case, the screenshots and the report PDF, each with its SHA-256 in a manifest. cognita soc imports it, refuses one altered after it was built, and keys it by the engagement, so a retest package updates the same engagement and keeps the remediation tracking.
cognita soc · /penetration-testing
From there a finding behaves like any other security finding: an owner, a target date and a status from Open through retest to Fixed, Risk Accepted or Dismissed. Raise it in the Issue Tracker and it sits beside audit and regulatory issues, where an examiner's request can cite it.
Watch one test run end to end.
We will scope an engagement against a demo application, drive the test from Claude Code, prove one finding, and import the package into cognita soc.
Transcripts and screenshots on this page use a fictional bank's demonstration data; cognita probe runs real attacks and must be used only on systems you are authorised to test.