Agents your security team can actually sign off on.
Coding agents arrived in most organizations before the governance did. The questions that follow are always the same: where does the code go, who authorised that action, and what happens when somebody leaves.
// Code, credentials, and execution stay on your machines.
The four questions that decide this.
None of them are about features. They are about boundaries, evidence, and what happens on a bad day.
Where does our code actually go?
The first question, and the one that eliminates most options. With Virex the answer is that it does not go anywhere: agents run on your machines and Virex never executes customer code.
Who did that, and can you prove it?
An agent taking action on a repository is an actor. Security events are audit-logged with the actor, the target, and the timestamp, so approving a permission request from a phone is as traceable as doing it at a keyboard.
How does access start and stop?
Access is granted by seat and removed by an admin. Combined with single sign-on and directory integration, it follows the identity lifecycle you already run.
What is stored, and for how long?
Session state and organization-scoped memory live in the control plane, with retention controls and isolation enforced at the database layer.
What the architecture guarantees.
Stated at the level a review board needs, with the deep dive on the security page.
A control plane, not a runtime
Virex coordinates with the tooling on your machines. Execution and credentials stay on your side of the boundary.
Tenant isolation in storage
Per-organization isolation enforced at the database layer with row-level security, not application checks alone.
Audit logging
Security events recorded with actor, target, and timestamp across administrative and session actions.
Server-side sessions
Sessions are managed server-side behind an opaque cookie, so browsers never hold tokens.
Controls, at a glance.
A summary for the shortlist stage. Each of these is covered properly on the security page rather than twice here.
Full detail, including the architecture behind each control, is on the security page.
What we will not claim.
Enterprise buyers get lied to constantly. Here is where we stop.
- We are not SOC 2 certified. The controls are designed to a SOC 2-oriented control set, and no audit has been completed.
- There is no self-hosted or customer-cloud deployment. Virex is a hosted control plane, and the honest security property is that your code and execution never leave your machines.
- We publish no customer names, logos, case studies, or benchmark numbers, because we are pre-launch and would have to invent them.
- Virex Remote is built around Claude Code. If your organization has standardised on a different coding agent, that matters more than any governance feature.
Enterprise questions
Is Virex SOC 2 certified?
No. 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 certification to claim. We will say so plainly rather than imply otherwise.
Do you support SSO and SAML?
Yes, single sign-on is part of the platform identity model, and SAML and directory integration are available for organizations that need them. The security page covers the detail.
How is one organization isolated from another?
Isolation is enforced at the database layer with row-level security, so a query scoped to one organization cannot return another organization data even if application code is wrong.
Does Virex ever execute our code?
No. Agents run on your machines under your own model subscriptions. Virex carries coordination, session state, and control signals, and never executes customer code.
Can we self-host?
No. Virex is a hosted control plane. The relevant property is that code, credentials, and execution stay on your machines rather than that the control plane runs in your data centre.
What is audit-logged?
Security events are recorded with the actor, the target, and the timestamp, which covers administrative actions and the decisions made against running sessions.
Bring it to your security review.
The security page has the architecture detail. If something is missing for your review, tell us what and we will answer it directly.