Security Model

Aevrin analyzes untrusted source and configuration, so execution boundaries are part of the product, not an implementation detail.

Source scanners

The local CLI mounts source read-only into version-pinned scanner containers. Production scan workers invoke pinned native scanners as a non-root user with CPU, process, timeout, and platform memory limits. Scanner subprocesses receive a sanitized environment that excludes account, database, payment, and unrelated application secrets.

MCP inspection

Only public remote HTTPS endpoints may be contacted. DNS and redirects are validated against loopback, private, link-local, metadata, and credential-bearing destinations. Submitted stdio commands are never executed by the hosted service. If no safe entrypoint is discoverable, the tool-description stage is skipped and explained.

Credentials and stored data

API keys are stored hashed; plaintext is shown once. CLI credentials and API keys are revocable. Pasted configuration is redacted before persistence. Scanner stderr and error output are scrubbed before reaching logs, reports, or CLI upload records.

Aevrin MCP capabilities

Aevrin MCP answers an agent in one of two ways, and they have different trust boundaries. Saying which one happened is part of the product.

When Aevrin runs a capability, it runs on Aevrin's servers in a fresh isolated sandbox for that one call, as an unprivileged user with no privileges to gain, a read-only filesystem apart from a small temporary area that cannot hold an executable, and capped memory, CPU, processes and run time. It has no network at all unless the version an administrator approved names hosts, and then its only reachable peer is an egress proxy that checks every requested host against that approved allow-list before any name is resolved and re-checks the resolved address. The input your agent sends is passed to the trusted providers the capability needs in order to answer. Nothing else about your account travels with it: a capability never receives your API key, your sign-in session, your cookies or your scan history. Every capability is reviewed and approved by an Aevrin administrator before it can run, and a new version is a new review.

A run's output is third-party content. Before your agent sees it, Aevrin strips control characters, redacts credential-shaped strings, and removes internal paths, container names and image digests, then labels the result untrusted. That is a floor, not a reason to trust the content: a result is data to read and report, never instructions to act on.

When Aevrin returns instructions instead, nothing runs on Aevrin. The text is Aevrin's own, written by an administrator for your agent to follow, and your agent does that work on your machine with your own privileges, outside Aevrin's sandbox. That is the same trust boundary as any other instruction you give your agent, and it is worth knowing which answer you got.

Server-side execution is switched off until the host for it has been prepared, so no capability runs today; searching and retrieving a capability work now. Every admitted run is recorded with hashes, sizes and counts only, never input or output content, and a capability whose runs keep tripping a limit has that account's runs paused rather than retried quietly.

Trust statements

CLI findings are self-reported because the scan ran on the user's machine. The API recomputes the score from uploaded findings but does not independently rerun local source. Static results are evidence for their tested scope, not a runtime sandbox guarantee or cryptographic attestation.