The boundary is the product.Here is exactly where it sits.
Virex is a control plane. It coordinates with the agents and tooling on your machines and never executes customer code. This page states what that means mechanically, what is enforced where, and what we do not claim.
// Written for the person who has to sign off on it.
What crosses the boundary, and what does not.
Most security questions about agent tooling reduce to one thing: whose machine runs the code. Ours does not.
Execution stays local
Coding agents run on your hardware under your own model subscriptions. Virex infrastructure never executes customer code, so there is no sandbox to escape and no build environment holding your repository.
Credentials stay local
Machine credentials and model provider accounts remain on your side. Virex does not proxy, resell, or store your model credentials.
What we do carry
Session activity records, pending decisions and their outcomes, the memories your agents write, and entitlement state. That is the coordination surface, and it is the honest scope of what we hold.
Enforced in storage, not in application code.
Application-layer checks fail when somebody forgets one. Putting isolation in the database means a missing check is not a data breach.
Access follows the identity lifecycle you already run.
The controls below exist so that joining, moving, and leaving are handled by your directory rather than by someone remembering to revoke something.
What is recorded, and what is kept.
An agent acting on a repository is an actor. Decisions made about it need to be attributable after the fact.
What we defend against, and what we cannot.
A threat model that only lists strengths is marketing. These are the actual boundaries.
Cross-tenant access
Defended in storage. Row-level security means a compromised or incorrect query path still cannot read another organization rows. This is the failure we treat as unacceptable.
Credential theft from the browser
Defended by design. Server-side sessions behind an opaque cookie mean there is no token in the browser to exfiltrate through a script.
Stale access after offboarding
Defended by process. SCIM deprovisioning and seat removal both terminate access through the entitlement checks that gate every request.
Compromise of your own machine
Not defensible by us. If the machine running your agent is compromised, the attacker has your code and your credentials directly. Virex holding no execution rights does not change that, and no control plane can.
An agent doing the wrong thing correctly
Partially addressed. Permission requests and plan decisions are the mechanism that keeps a human in the loop, and audit logs make the decision attributable. Neither prevents an approved action from being a mistake.
Our own availability
Not a confidentiality control. If the control plane is unavailable you lose oversight and memory retrieval, while your local agent keeps running. That is a deliberate consequence of not sitting in the execution path.
Where the coordination data lives.
Stated at the level we can actually commit to today rather than implying options that do not exist.
What we will not claim.
Pre-launch companies overstate this constantly. Here is the precise position.
- Virex is not SOC 2 certified. Security controls are designed to a SOC 2-oriented control set, and the architecture was built with an audit in mind, but no audit has been completed and there is no report to share.
- There is no self-hosted, on-premise, or bring-your-own-cloud deployment. The accurate security property is that your code, credentials, and execution never leave your machines, not that the control plane runs in your data centre.
- We publish no penetration test summaries, uptime figures, or benchmark numbers, because we would have to invent them at this stage.
- We publish no customer names, logos, or case studies. We are pre-launch and have none to cite honestly.
Security questions
Does Virex ever execute our code?
No. Coding agents run on your machines under your own model subscriptions. Virex carries coordination, session state, and control signals. There is no Virex-operated environment that builds or runs customer code.
Is Virex SOC 2 certified?
No. Controls are designed to a SOC 2-oriented control set and the architecture was built with an audit in mind, but no audit has been completed and there is no certification or report to provide.
How is tenant isolation enforced?
At the database layer with row-level security, so isolation does not depend on every application code path remembering to filter by organization. The same policy applies to web, CLI, SDK, and MCP tool-call access.
Do you support SSO, SAML, and SCIM?
Yes. Single sign-on covers every Virex surface, SAML federation is available for organizations standardising on their own identity provider, and SCIM handles directory-driven provisioning and deprovisioning.
What exactly is audit-logged?
Security events with the actor, the target, and the timestamp. That includes administrative actions such as seat and member changes, and session decisions such as approving or denying a permission request, wherever the decision was made from.
Can we self-host Virex?
No. Virex is a hosted control plane and we will not describe a deployment option that does not exist. The relevant guarantee is that execution and credentials stay on your machines.
What happens to our data if we leave?
Tenant-scoped data held for the organization is removed when the organization is removed. Memories and session records belong to the organization rather than to individual members, so they do not leave with a departing employee.
Who do we contact about a vulnerability?
Use the contact page and mark it as a security report. We would rather hear about a problem directly than read about it later.
Bring the hard questions.
If something here is missing for your review, ask and we will answer specifically rather than pointing you at a brochure.