Security & Data Handling

e-volv does not resell model capacity. You register your own provider credentials per workspace - OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, OpenRouter or DeepInfra - and choose which model each agent uses. At run time the key is decrypted from your workspace vault and used for that call only.

The practical consequence is the one that matters: your source code is sent to the provider you selected, under the agreement you hold with that provider, and to no other model vendor. Changing providers is a configuration change, not a migration.

The exceptions, stated plainly

Every plan includes a small allowance of AI runs that work without a key of your own, so that a new workspace can execute a playbook before it has any credentials configured. Those runs use e-volv's own provider account, which means the prompt and the code context in them reach that provider under our agreement rather than yours.

• Starter - 20 included runs per month.
• e-volv Pro - 200 included runs per month.
• Studio - 1,000 included runs per month, per client workspace.
• Register a provider key and the allowance stops being used at all: your key takes precedence on every run, on every plan, including the free one.

If your policy is that no code may leave under a third party's vendor agreement, configure a provider key before your first execution and the allowance is never touched.

The second exception: Code Map indexing

Code Map builds a searchable index of a repository, and the embeddings behind it are generated by a provider e-volv configures for the whole service - currently DeepInfra, running the open-weights model BAAI/bge-m3 - using our account, not the key you registered. Choosing a provider for your agents does not redirect this. It is the one place where the “your model, your key” rule above does not hold, and we would rather say so here.

• Indexing is off by default, and is enabled per repository by someone with editor access. A repository that is never enabled is never indexed and never embedded.
• What is sent - for each symbol, its file path, its declaration signature, and up to the first 60 lines of its body, capped at roughly 1,500 tokens. Not whole files, and not the repository.
• What comes back is a vector. Unchanged symbols are never re-sent: embeddings are cached against a hash of the symbol's source, so re-indexing a quiet repository sends nothing.

If that trade is not one you want to make, leave Code Map indexing switched off. Every other part of the product works without it.

Provider keys, git tokens, and any secret you add to a workspace are encrypted before they are written to the database. They are never stored in plaintext and are never returned to the browser after they are saved.

• AES-256-GCM. An authenticated cipher: a modified ciphertext fails to decrypt rather than decrypting to garbage.
• Per-secret salt and IV. Both are freshly random for every value encrypted, so two identical secrets do not produce identical ciphertext.
• scrypt key derivation from a master key that is held in Google Secret Manager in production and never stored beside the data it protects.
• Redaction on the error path. Payloads are scrubbed of any field whose name looks like a key, secret, token, password or credential before an error is logged, so a failed agent run cannot spill a credential into a log line.

Every read of a stored secret writes a vault.secret_accessed audit event naming the actor, the secret, and the workspace. Reading a credential is itself a recorded event, including when the reader is an agent rather than a person.

Agents check out your repository and run tools against it - reading files, searching code, and executing commands. In our hosted deployment that work happens inside a per-run container, not on a shared application host.

• No network. The container is started with networking disabled, so a command inside it cannot reach the internet, our internal services, or another customer's run.
• Bounded resources. 2 vCPU and 4 GB of memory per run, which caps what a runaway or hostile command can consume.
• One repository, one mount. Your checkout is mounted at a single working directory and nothing else from the host is visible to it.
• Torn down after the run. Containers are not reused between executions.

Self-hosted deployments choose their own isolation mode, and the product runs without containers if you configure it that way. The description above is what the hosted service at e-volv.io is deployed with.

The controls that stop an agent writing something you did not intend are product features, not settings buried in an admin page.

Dry run

Any workflow can be executed in dry-run mode. Every step that would reach an external system - opening a pull request, commenting on a ticket, triggering CI, publishing a report - returns what it would have done instead of doing it. The run is fully logged so you can read the intended actions before authorising them, and dry runs are not counted against your plan limits.

Approval gates

An approval gate is a node you place in a workflow. Execution pauses there, a named approver decides, and the workflow resumes or stops on that decision. Gates expire rather than defaulting to approved: a request nobody answers does not eventually let the write through.

Start read-only

Agents only hold the tools you give them. A review agent configured without write tools cannot create a branch or push a commit regardless of what it decides to do - the capability is absent, not merely discouraged by the prompt.

Two independent records exist for every action taken in a workspace, and both are readable by you.

Audit events

A dedicated event log records authentication, secret access, integration changes, trigger changes, and workspace membership changes. Each entry names the actor and whether it was a user, an agent, the system, or e-volv staff; the action; the resource; the originating IP address; and a risk level.

The service that writes this log exposes two operations - append and read. There is no update path and no delete path, in the API or in the application code, so an event cannot be edited or removed after the fact through the product.

Execution logs

Separately, every workflow run records its step lifecycle: which steps ran, in what order, with what inputs and outputs, how long each took, which model was used, and what it cost in tokens. You can replay a finished run step by step. If an agent wrote a review comment you disagree with, the exact prompt and tool calls that produced it are recoverable.

• Credentials are held by Firebase Authentication, Google's identity service. e-volv never stores your password and never sees it.
• Sessions are short. Sign-in issues an ID token valid for one hour, refreshed by the client while you are active rather than held as a long-lived credential.
• Every workspace endpoint checks membership. Authentication proves who you are; a separate guard proves you belong to the workspace whose data you asked for. Both must pass.
• Record identifiers are not capabilities. Knowing a workspace or execution ID does not grant access to it.

Two checks stand between tenants, and both have to pass. The first is membership: every workspace endpoint confirms you belong to the workspace named in the URL. The second is narrower and is the one that matters most, because it is the one a membership check cannot see - every request that names a single record resolves that record against the workspace in the URL, so pairing a workspace you legitimately belong to with a record id belonging to someone else returns nothing.

• Enforced in continuous integration, not by convention. A structural check fails the build if a route that addresses a single record does not scope it to a workspace, and a second one fails if a route that changes anything does not declare the minimum role it requires. A new endpoint that forgets either is caught the day it is written.
• Proved against a real database. An integration suite creates two separate tenants and has one attempt to read, rename and delete the other's records - workflows, agents, models and repositories - through its own workspace. It asserts the records are unchanged afterwards, because a request that is refused and writes anyway is the failure that matters.
• Lists are scoped, not filtered afterwards. The same suite checks that one tenant's listings never contain another's records.
• Record identifiers are not capabilities. Knowing an id does not grant access to it, and a request for a record you cannot see is answered as not found rather than as forbidden - confirming that something exists is itself a disclosure.

We audit this rather than assume it. The automated checks above exist because a convention enforced only by care is a convention that decays quietly, and the point of moving it into the build is that decay becomes a failing test instead of a finding in someone else's audit.

• Repositories are not retained. They are shallow-cloned into a run's working directory and discarded with it. e-volv does not keep a copy of your codebase, and file contents are never written to our database.
• A Code Map index is derived data, and it persists. For a repository with indexing enabled, e-volv stores one row per symbol: its name, its repo-relative path, its line numbers, its declaration signature - which is a line of your source - a hash of its body, and an embedding vector. Bodies themselves are not stored. Disabling indexing or deleting the workspace removes the index.
• Step outputs - the intermediate values a workflow passes between steps - sit in a cache with a 24-hour expiry during the run, then persist with the execution record so the run stays replayable.
• Execution and audit records persist for the life of the workspace. Deleting a workspace deletes them.
• Payment details never reach us. Card data is entered directly with Stripe; e-volv stores only a customer reference and your plan.

The third parties that process data on our behalf - the hosting, database, queue, email, billing and error-monitoring providers, and their regions - are listed in full in the Privacy Policy. Your chosen LLM provider is on that list; it is the only one that receives your source code.

e-volv is a young product from a small company. The controls above are real and implemented; the following are not, and we would rather you learn that here than in a questionnaire six weeks into an evaluation.

• We are not SOC 2 certified and have not begun a Type I or Type II audit.
• We are not ISO 27001 certified.
• We do not offer a HIPAA business associate agreement and e-volv should not process protected health information.
• No third-party penetration test has been performed on the platform to date. When one has, its date and scope will be named on this page.
• We do not offer customer-managed encryption keys, a private deployment tier, or data residency guarantees beyond the regions named in the Privacy Policy.

If your procurement process requires any of the above today, e-volv is not yet the right fit, and we will tell you so on the call rather than after the pilot.

Report suspected vulnerabilities to security@e-volv.io. Include the steps to reproduce and what you were able to access. We aim to acknowledge within two business days.

Test only against your own workspace and your own data. Do not run automated scanners against the production service, and do not access, modify, or retain another customer's data - if a flaw exposes it, stop and tell us what you saw. Research conducted within these limits is welcome and we will not pursue it.