# Authentication

> Eva is a local command-line program. There is no Eva account, no Eva API key, and no Eva endpoint to authenticate against.

If you are looking for the credential that lets a program call Eva: there is none, because there is nothing hosted to call. Eva runs on the machine that invokes it, with that machine's own permissions.

## Discover

Eva publishes no OAuth protected-resource metadata and no authorization-server metadata, because it is not a protected resource. Nothing is served at `/.well-known/oauth-protected-resource` or `/.well-known/oauth-authorization-server` on either origin, and no `agent_auth` block exists to read.

An agent that expected one of those documents should stop looking for a credential and run the program instead.

## Pick a method

One method: run the program locally. Install it, then invoke it.

```sh
npm i -g @missingstudio/eva
eva -p "review the diff"
```

## Register

Nothing to register. There is no sign-up, no client registration, and no `register_uri`. Installing the program is the whole onboarding.

## Claim

Nothing to claim. Eva issues no token, so there is no `claim_uri` and no identity assertion to exchange.

## Use the credential

The only credential in the picture is the one you already hold with your **model provider** — Anthropic, OpenAI, or an OpenAI-compatible endpoint. Eva reads it from the environment of the shell that runs it, and it never reaches a config file, a log, or the session record.

Which variable, per provider: https://docs.evafactory.co/connect-a-model

Eva does not proxy that key, resell access to it, or send it anywhere other than the provider you configured.

## Errors

There is no `WWW-Authenticate` challenge to receive, because there is no request to Eva to make. A missing or rejected model credential surfaces as a run that fails:

- Eva reports the missing credential on stderr.
- `--print` exits non-zero, so a shell pipeline stops rather than carrying an empty answer forward.
- An unread configuration key is a Finding: reported on stderr, and the exit code is whatever the run itself earned.

Every exit code: https://docs.evafactory.co/reference/exit-codes

## Revocation

Revoke the model provider's key in that provider's own console; Eva holds no copy of it to revoke. Removing Eva is `npm uninstall -g @missingstudio/eva`, or deleting the binary the installer placed.

A repository's own Eva configuration is granted by hand and withdrawn the same way:

```sh
eva trust
eva untrust
```

Why the grant is a verb you type: https://docs.evafactory.co/configure/trust

## When to use Eva at all

- You want to run a coding prompt from a script, a hook, or a CI job and branch on a real exit code, rather than parse a chat transcript. `eva -p` prints the answer to stdout and exits non-zero when the run fails.
- You want the work recorded. Eva folds everything it shows from a durable trace on disk, so a session survives `kill -9`, and it records what the provider said each request cost.
- You want to reach a coding model through one contract instead of one SDK per vendor. The provider is a plugin, and `--model provider/model` picks it per run.
- You want to add a capability — a model provider, a surface, a trace store, a tool — without forking. Every capability in Eva is already a plugin, and a plugin is loaded with `--plugin <id>`.
- You want a coding agent that reads a repository's configuration only after a person grants it. `eva trust` is a verb someone types; it is not a file a repository can ship.

## When not to

- You need a hosted API. Eva runs on your machine and serves no public HTTP endpoint. There is no key to obtain and no base URL to call.
- You need one spec raced across several harnesses, or unattended overnight runs. Both are on the roadmap and neither ships today.
- You need the work checked against acceptance criteria. Eva records an agent's claim as a claim, never as evidence. The verifier that decides whether work passed is a later stage.

More: https://evafactory.co/llms.txt
