EVA is a pentest agent you drive by hand, and its configuration file keeps API keys as plain strings

The install is one pip command, and the console script is named eva

The PyPI path is two lines:

pip install eva-exploit

That package name is not the repository name, which is where most of the confusion starts. The distribution is eva-exploit, the repository is ARCANGEL0/EVA, and the module is a single file called eva.py. pyproject.toml wires the console script eva to the entry point eva:cli, and it declares the package layout explicitly: two top-level modules, eva and config, plus the utils, modules, and sessions packages. Runtime dependencies are short and unglamorous, colorama for terminal colour, the openai client at 1.0.0 or newer, and requests. Python 3.10 or newer is required. Nothing in the dependency list pulls in a model runtime, so the local Ollama backend works through the HTTP API rather than through a bundled inference library.

Three version numbers disagree, and the release tag is the oldest of them

The repository carries a VERSION file at the top level, a version field in pyproject.toml, and one GitHub release. The release is v3.1, tagged on 2026-02-20, and the version declared for the wheel is 3.5. The last push was 2026-06-16, four months after that tag, so main has moved since any published release. Which number a given install reports depends on which of the three it reads, and the README does not say which one the eva command prints. The gap matters more than it looks for a tool whose whole value is being the newest thing you have on the box: the code in front of you may be a version you could not install from PyPI, and the version you could install may predate the fixes in the file you are reading.

The config file keeps every key as a plain string beside the model names

Run eva --config and it opens the configuration in your default editor. The file it shows you is a flat module of assignments, and the values printed in the README are placeholders in the shape the tool expects: API_ENDPOINT = "NOT_SET", then G4F_MODEL = "gpt-oss-120b", G4F_URL pointing at a gpt4free worker, OLLAMA_MODEL = "ALIENTELLIGENCE/whiterabbitv2", SEARCHVULN_MODEL = "gpt-oss:120b-cloud", and four separate keys for OpenAI, Anthropic, Gemini, and Ollama. CONFIG_DIR is Path.home() / "EVA_data", with sessions and reports underneath. There is no keyring, no encrypted store, and no file mode mentioned, so keys you type land in a Python file on disk in plaintext, and eva --delete removes sessions and files without being described as a key wipe.

Its own example ships a free gpt4free proxy as the default endpoint

Two of the settings are worth reading twice. G4F_URL is preset to https://api.gpt4free.workers.dev/api/novaai/chat/completions, a public free proxy rather than an endpoint you own, and SEARCHVULN_URL is preset to https://ollama.com/api/chat, which is Ollama's hosted service rather than a local daemon on port 11434. The second one is the sharper edge: the vulnerability search path, the feature that looks up exploits for the target you describe, is wired to a cloud host by default while the rest of the tool is pitched as offline-first. A pentest conversation includes target addresses, hostnames, and internal IPs, so check which of those two defaults your install is actually using before you type a real target into the chat.

The README's Ollama line pipes curl into a command spelled shr

The local model path is supposed to be the private one, and Ollama is marked as the recommended backend for that reason: complete offline operation, no API cost, and a model called the best one for offensive security work. The cost of that model is stated plainly, around 9.8GB and hardware above 8GB of VRAM or RAM. The install line for it, though, is written as curl piped into a command spelled shr, not the sh you would expect from a shell pipe. Either the README has a typo or your system has a wrapper of that name. Either way it is the first line a new user copies on a clean machine, and it is the one line here that deserves a read before it runs. A checksummed clone is the other option.

Running from source moves an unverified script into /usr/local/bin as root

The source route is five lines, and the last one is the interesting one:

git clone https://github.com/ARCANGEL0/EVA.git
cd EVA
chmod +x eva.py
./eva.py
# Adding it to PATH to be acessible anywhere
sudo mv eva.py /usr/local/bin/eva

Moving the script into /usr/local/bin with sudo makes a single Python file a machine-wide command with root write access and no hash pin, no review, and no way to tell later which commit it came from. If you take that route, clone at a tagged commit instead of the tip of main and record it, since the repository's own version numbers already disagree about what is current. The pip route avoids all of this and is the one the README lists first.

MIT in pyproject, no license file in the tree, and a badge row that links nowhere

The metadata declares license = { text = "MIT" } with a single author, ARCANGEL0. The tree has no LICENSE file, no CODE_OF_CONDUCT, and no CONTRIBUTING guide, so the only statement of terms is one line of packaging metadata that nobody reads at clone time. The badge row at the top of the README is worse: four of the links point at the repository itself, two more point at a bare #, one points at a LICENSE name with no path behind it, and one points at a different project, ARCANGEL0/NekoCLI. Empty brackets and duplicated targets render as nothing or as a dead link. If you intend to build on EVA, resolve the licence question with the author before you ship anything.

R, S, and A are the whole interaction, and the commands are suggestions you run

Once a session and a backend are chosen, the agent proposes shell commands and waits. A single letter decides each one: R runs the suggested command, S skips it, A asks for the next step, and Q quits the session. Nothing executes on its own. The slash commands are separate and worth memorising, since they are what you use when the chat goes sideways: /exit and /quit save the session, /rename names it, /model switches backend mid-session, /report writes the latest findings to PDF or HTML, /map writes an attack surface map as HTML, /menu returns to the session list, and /search runs a vulnerability lookup and feeds the results into the next analysis. Output goes under EVA_data, with sessions as JSON and reports and attack_maps beside them.

Editorial conclusion

Use EVA when you already know offensive security and want a second opinion on enumeration order, or when you need an offline path through Ollama with no API cost. Do not paste credentials into its config editor without reading where they land, and remember that every suggestion is a command you have not run yet, so R is a decision rather than a keystroke. Before you rely on it, confirm the version you installed matches the source you read, since pyproject.toml, version.txt, and the release tag do not agree.

Frequently asked questions

Official sources

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