EVA (Exploit Vector Agent): an AI pentest CLI with six backends

What EVA is for, and who it is actually aimed at

EVA stands for Exploit Vector Agent. The README describes it as an AI penetration testing agent that guides users through complete pentest engagements with attack strategy, command generation, and vulnerability analysis based on command output. The stated intent is explicit: the goal is not to replace the pentest professional but to guide and assist and provide faster results. That framing matters, because the tool is a conversation-driven shell, not an autonomous scanner.

The audience is narrow. You need a working Linux environment, Python 3.10 or newer per the pyproject metadata, and either a local model server or an API key for a hosted provider. The topics list on the repository includes ctf and privilege-escalation alongside pentest, which suggests the author expects it to be used in lab and competition settings as much as in client work. Anyone expecting a one-command vulnerability scan will be disappointed. EVA asks you to define a target, then proposes commands you run yourself, then reads the output back into the model.

The reasoning loop behind EVA's attack strategy

The README ships a Mermaid flowchart that is the clearest description of the architecture available. It shows a linear state machine: launch, session selection, backend selection, target definition, AI strategy, reconnaissance, command execution, result analysis, then a branch on whether vulnerabilities were found. If none are found, the flow loops back to more enumeration and re-enters the strategy step. If some are found, it moves to exploitation planning, which can also export graphs and mapped networks. Exploitation branches again on whether access was gained, with failed attempts routed to alternative methods that return to planning.

Four subsystems sit alongside the main loop in the diagram: attack strategy AI, session memory, vulnerability analysis, and a CVE database search, plus output processing that feeds results back to the strategy step. Session memory is what makes the loop stateful across turns. The CVE lookup is wired to a separate model configuration, SEARCHVULN_MODEL set to gpt-oss:120b-cloud and SEARCVULN_URL pointing at the Ollama cloud API, which means vulnerability lookups can use a different endpoint from the main reasoning model. That separation is a sensible design choice, though the README does not explain how the CVE search is queried or what happens when it returns nothing.

Installing EVA and running a first session

Two installation paths exist. The pip route is the shortest, and the README gives it as a two-line sequence. The package name is eva-exploit, and the console script exposed by pyproject is eva.

pip install eva-exploit
eva

If you prefer the repository checkout, the README shows cloning, making eva.py executable, and running it. It also suggests moving the script into /usr/local/bin so the command is available anywhere.

git clone https://github.com/ARCANGEL0/EVA.git
cd EVA
chmod +x eva.py
./eva.py
sudo mv eva.py /usr/local/bin/eva

Note that the Ollama install line in the README is written as curl -fsSL https://ollama.ai/install.sh | shr, which pipes to shr rather than sh. The README does not explain this, and the command as printed does not match the usual Ollama installer invocation. Verify that line before running it.

On first start, the README says EVA handles API key setup, downloads an Ollama model (default whiterabitv2), creates the session directory, and installs dependencies. Configuration lives in a generated config file, reached through one flag.

eva --config

That file exposes the keys you will actually edit: API_ENDPOINT, OLLAMA_MODEL, SEARCHVULN_MODEL, OLLAMA_API_KEY, OPENAI_API_KEY, ANTHROPIC_API_KEY and GEMINI_API_KEY, plus ANTHROPIC_MODEL and GEMINI_MODEL. Paths default to ~/EVA_data with sessions, reports and attack_maps subdirectories, all created at import time. Two retry knobs, MAX_RETRIES at 10 and RETRY_DELAY at 10 seconds, govern request retries.

Where EVA's design gets in the way

The config file is Python, not a data format. The README's sample shows module-level statements such as CONFIG_DIR.mkdir(parents=True, exist_ok=True) and username = os.getlogin() sitting next to the API keys. Editing it is editing code, and eva --config opens it in your default editor. That is convenient for a solo operator and awkward for anyone who wants to template, version or validate the configuration in a pipeline.

The bigger gap is safety. Nothing in the README describes a dry-run mode, a command allowlist, an approval gate, or a scope restriction. The loop executes commands and feeds output to a model that then proposes the next command. If you point it at a production host, the model's suggestions are the only thing between you and an unintended action. The README also does not document rollback, undo, or a sandbox. For lab work behind a VPN that is tolerable. For client engagements it means EVA belongs in a disposable VM with a snapshot, and the operator reads every command before pressing enter.

Licensing is the other unresolved item. The README badge says MIT, and pyproject.toml declares license = { text = "MIT" }. The repository's top-level entries listed above include .gitignore, README.md, config.py, custom.py, demo.gif, eva.jpeg, eva.py, modules/, pyproject.toml, sessions/, utils/ and version.txt, with no LICENSE file among them. A badge and a metadata field are not the same as a licence file, and the repository page is the place to confirm terms before you rely on them.

EVA against Metasploit and single-purpose MCP bridges

The obvious comparison is Metasploit, which appears in the related searches as Metasploit MCP github. Metasploit is a curated exploit framework: modules are written and reviewed by humans, execution is deterministic, and the same module against the same target produces the same result. EVA inverts that. Its suggestions come from a language model at runtime, so two runs against the same target can diverge. What EVA offers instead is reach across phases: reconnaissance, enumeration, exploitation planning, privilege escalation and post-exploitation all sit in one session with shared memory, and the attack_maps directory collects generated HTML and JavaScript attack surface diagrams.

Against a narrower AI agent such as PentestAgent or LuaN1aoAgent, the difference is backend choice. EVA's README lists Ollama, OpenAI GPT, Anthropic Claude, Google Gemini, G4F.dev and custom API endpoints, all selectable at session start per the flowchart. A tool locked to one provider cannot be run fully offline. EVA can, using a local Ollama model, which matters when the target data cannot leave the network. The trade-off is that a local model's reasoning quality sets the ceiling on the whole loop, and the default OLLAMA_MODEL is a community model rather than a frontier one.

Maintenance, versions and the cost of upgrading

The repository is not archived, and the last push was on 2026-06-16. The most recent release listed is v3.1 from 2026-02-20, while pyproject.toml declares version = "3.5". That mismatch means the packaged version and the released version are not the same thing, and anyone pinning to a release tag is pinning to older code than the checkout on main. If you install via pip, you get whatever eva-exploit publishes; if you clone, you get main.

The dependency surface is small: colorama, openai and requests, with requires-python set to >=3.10. Upgrades are therefore cheap in package terms. The expensive part is configuration drift. Because config.py holds endpoints, model names and keys as Python assignments, an upgrade that changes a key name will surface as an import-time error rather than a validation message. Keep a copy of your edited config outside the repository before pulling.

On licence implications, the README badge and pyproject both say MIT, but with no LICENSE file in the repository listing, the terms are asserted rather than shipped. MIT would normally permit commercial use and modification with attribution, but that is a general property of the licence text, not legal advice about this repository. Confirm the actual terms on the project page before using EVA in commercial work.

Editorial conclusion

Adopt EVA if you already run structured engagements and want an LLM to propose the next enumeration or exploitation step while you keep the shell. Skip it if you need a reproducible, auditable pipeline, or if you cannot accept that the repository ships no licence file and no documented rollback. Before installing, run eva --config and read the generated config, then confirm the licence terms on the repository page and decide which backend you will point at a live target.

Frequently asked questions

Official sources

1. ARCANGEL0/EVA on GitHub
2. Issues
3. README
4. Releases