Scope, discipline by discipline

What this is, and what it will not be

The verdicts below are rendered from web/scope_taxonomy.py: one description, kept where the code can be read, that becomes this page, the table in BETA.md and the scope clause in the terms of use. Each row names a path in this repository, and a test resolves it.

A penetration test has three parts: find out what is exposed, prove what is reachable, then get in and stay in. This beta is the first two, done automatically and without changing the state of the estate it assesses, plus the report that keeps a verified finding apart from a lead. The only writes it can make are to a source repository or a model hub the scope names, each one behind a human approval for that exact command line, never a destructive one. The third part is not implemented, not hidden behind a setting and not available on approval - it is what safety/guard.py refuses by construction. Below is each discipline in the field, and where this beta stands on it.

• Reconnaissance and OSINTCovered. What is out there, and what does it belong to? Passive sources first, then rate-limited probing: assets, technology and entry points, and a target you can prove you own before any of it starts.
• Vulnerability assessmentCovered. Which known weaknesses are present on this host or service? Version and configuration facts are gathered with fixed-safety adapters, and a template can be run against one hypothesis at a time.
• Web and API application assessmentCovered. Does this application's own logic fail? Content discovery, authentication and session logic, injection classes, access control and IDOR, headers and CORS - named in the web pack, and behind the approval class that gates injection probes.
• Cloud security posture reviewCovered. Is this account exposing something it should not? Read-only: public buckets, over-permissive policy documents, exposed managed services, logging gaps. It never mutates cloud state.
• AI and LLM security assessmentCovered. Can this model or agent be steered out of its design? Prompt injection and jailbreaks, system-prompt and tool-definition extraction, insecure output handling, excessive agency, retrieval leakage.
• Exploitability verificationCovered. Is this finding real, or a scanner's guess? Each hypothesis is reproduced, the bytes are kept with their hashes, and a lead is never promoted to a finding without them.
• Penetration testingCovered, up to a point. Could an authorised attacker achieve a goal here? It does the assessment third of a pen test and stops there: findings are not chained towards an objective, nothing pivots to a second host, and no impact is demonstrated. A human closes the rest.
• Impact and post-exploitation proofCovered, up to a point. What would follow a successful exploit? Impact is argued from the verified condition, not shown: escalation, persistence, destructive writes, reverse shells and bulk exfiltration are permanently forbidden, so no run can go there.
• Source repository and model supply-chain reviewCovered, up to a point. Is this repository, or this model, what it is claimed to be? A repository and a hub model are scope targets of their own - named, matched against the scope and never resolved - and their published facts are read: visibility, archived and fork state, default branch, last push, licence, whether vulnerability alerts are on, which branches exist; and for a model, whether it ships pickle-format weights that execute when loaded, carries its own Python, or is gated or private. It does not judge the code: no secure code review, no dependency resolution, no scanner over the tree. Publishing is the part a human decides - a push, a pull request or an upload needs an approval for that exact command line and reads only from a directory the operator nominates, and a force-push or a deletion is refused with no approval available.
• Vulnerability managementCovered, up to a point. What is outstanding, who owns it, and has it been fixed? It finds, verifies and reports, with CVSS 4.0 scoring and exports. The tracking, ownership and retest loop is a system it feeds rather than one it is.
• Audit and compliance evidenceCovered, up to a point. Can you show what was done, and show that nothing else was? Every decision goes into an append-only hash-chained log and the chain is verified before the run exits; mapping that evidence onto a control framework stays a human's job.
• Red teaming and adversary emulationOut of scope by design. Can a goal-directed adversary get in and stay invisible? A red team takes an objective, hides, measures whether the defenders noticed and coordinates people. This beta announces itself, holds one authorised target at a time, and writes down everything it does.
• Purple and blue teaming, detection engineeringOut of scope by design. Would we see this happen? It reports what it did and when; it has no defender-side adapter and sends no telemetry anywhere, so it cannot answer whether a control fired.
• Breach and attack simulationOut of scope by design. Would our controls stop a known technique, everywhere, all day? That needs an agent inside the estate and a library of techniques run continuously. This runs from outside, against one target you authorise, when you start it.
• Exploit development, malware analysis and C2Out of scope by design. Here is code somebody found. What does it do? Writing an exploit, analysing a sample and running command-and-control are forbidden action classes rather than settings: no configuration and no human approval can enable them.
• Social engineering, phishing and physical testingOut of scope by design. Will a person let an attacker in? Nothing here addresses a human or opens a door. The registry is closed, too: a binary nobody registered is treated as intrusive and refused rather than attempted.
• Wireless, RF and hardwareOut of scope by design. What is on the air, or inside the box? No adapter reaches a radio or a physical interface; those live outside the four domain packs, and an unregistered tool is gated rather than silently attempted.
• Mobile application assessmentOut of scope by design. Does the app on the handset fail? There is no registered adapter for it, and a capability with no adapter is reported as not tested rather than as absent.
• Threat modelling, tabletop exercises, secure code reviewOut of scope by design. What could go wrong, and is the code written defensively? A tabletop exercise, a threat model and a secure code review each start from a document or a source tree and reason about it. This beta can read an authorised repository and report what the host publishes about it, but reading is not reviewing: it names what is there rather than judging how it is written, and it starts from a target the scope names, not from a design to critique.
• Vulnerability research and coordinated disclosureNext to the product, not in it. Is this a new flaw, and how does it get reported? Done by hand and published as evidence, which is what the write-ups on the site are. The product finds what is already exploitable; it does not go looking for a zero-day.

Where each verdict is enforced

These are claims about the code rather than settings. Every one of them names where it is decided: the guard's permanently forbidden action classes, the four domain packs, the closed tool registry, the scope check that runs before the first packet, and the hash-chained audit log that records the refusals as well as the actions. python web/build_scope.py --check fails when this page, the BETA.md table or the clause in the terms of use has moved on its own, so the three cannot tell a reader three different stories.

Enigmatic Red — an independent research project. Authorised testing only: every scan needs a signed, dated authorisation that covers the target, and this beta is a non-destructive assessment agent, not a red team. Back to the page · Terms of use · info@enigmaticred.com