What Excalibur VITRO Is¶
When a user opens a web application, that web application runs in the user's browser. Its JavaScript executes there. Its cookies and storage live there. Its outbound network calls originate there. Any password it requires is typed into a form rendered there.
Existing security products accept this and work around it. A web application firewall (WAF) inspects HTTP between the user's browser and the application. A virtual private network (VPN) and zero-trust network access (ZTNA) extend the user's network so the user's browser can reach the application directly. Virtual desktop infrastructure (VDI) moves the user's browser into a remote desktop, but the web application still runs in that browser, with the same exposure model. A privileged-access management (PAM) browser extension stores enterprise credentials and types them into login forms in the user's browser at the moment of use. Remote browser isolation (RBI) moves execution off the user's machine and streams the result back as video; every interaction then waits for an encode, a network round-trip, and a decode, text loses sharpness to video compression, and continuous per-session video encoding burns GPU or CPU for as long as the session is open.
VITRO moves execution off the user's machine and streams DOM mutations instead of pixels. The user's browser holds a local mirror of the remote DOM and applies incremental updates as the remote DOM changes.
The architecture¶
VITRO splits a web session into three parts.
Execution runs in a remote browser, which holds the application's JavaScript, cookies, storage, network access to the application's backend, and any secret it needs.
Presentation runs in the user's browser, which mirrors the remote browser's DOM. As the remote DOM changes, only the mutations are sent.
Control flows through a mediated channel. Every click, keystroke, form input, navigation, or upload is sent through that channel to the remote browser, which is where the application runs.
What this removes from the user's browser¶
The user's browser does not run the application's JavaScript. It does not hold its cookies or storage. It cannot reach its origin. It cannot call its internal APIs or change the state it reads, because that state lives in the remote browser. Credentials are typed into the remote browser by the server; they never enter the user's browser.
A PAM browser extension cannot match this. The extension can store a secret on the user's machine, but to log the user in it must type that secret into the page rendered by the user's browser, where any script on the page can read it. VITRO never puts the secret in the user's browser at all.
Lateral movement from a compromised endpoint stops here too. With VPN or ZTNA, an endpoint with valid credentials can reach every system its policy allows, and a foothold on the endpoint inherits that reach. With VITRO, the endpoint has no network path to the application at all — the remote browser does. A foothold on the endpoint can manipulate what the user sees and types, but it cannot open its own connection to the protected system.
Why this is not classical RBI¶
RBI also moves execution off the user's machine. Classical RBI then delivers the result as video. Every keystroke and scroll is a round-trip to the remote browser, text loses sharpness to video compression, and the video pipeline burns GPU or CPU continuously for every open session.
VITRO keeps remote execution and changes the delivery. The user's browser mirrors the remote DOM and applies incremental DOM mutations, not video frames. Scrolling, typing, and selection run against the local mirror without a round-trip. Round-trips happen where users already expect them: navigation and other moments that change remote state.
Why PAM is the natural first use case¶
A privileged web session carries secrets, performs high-consequence actions, and is held by a user entitled to operate the application but not to possess its runtime. Conventional PAM products provide workflow, recording, and approval, but the secret and the runtime still sit in the user's browser. VITRO puts both in the remote browser. The user logs in, navigates, and operates; the credentials and the runtime never leave the server.
Why density matters¶
Isolation only becomes the default for interactive web access if per-session cost is low. Classical RBI gives each user a separate isolated browser, which keeps it confined to a few high-risk workflows. It must do this because it isolates the page: the page is arbitrary web content that may be malicious, so it cannot share a browser process with anything else. VITRO isolates the user from a known, trusted web application, so concurrent sessions can be tabs in a shared remote browser instead of separate browsers.
The density claim is not theoretical. In internal scalability tests on an HP Z2 Mini G1a workstation with an AMD Ryzen AI Max+ 395 and 128 GB of RAM, against https://www.bbc.com/, the system kept roughly 1,000 Chromium contexts alive. The live dashboard for that run showed 45.2 GB in use out of 109.0 GB visible to the test, 12.4 GB deduplicated by KSM, and 3.2:1 ZRAM compression. Density comes from the whole stack at once: many sessions share remote browser processes, identical memory pages are merged by KSM, and colder pages are compressed in ZRAM instead of forcing a separate full-browser footprint per session.
Review cost behaves the same way. Because the reasoning layer resolves most ambiguous actions at the user, the share of actions that reach a human reviewer falls as the system sees more of an organisation's workflows. Reviewer load grows slower than session volume.
Why the categories collapse¶
VPN, ZTNA, VDI, PAM, WAF, and RBI all address consequences of one fact: the user's browser runs the web application. VPN and ZTNA give the user's browser network access to the web application. VDI moves that browser to a remote desktop, but the web application still runs in a browser the user controls. PAM controls who is allowed to log in from the user's browser. WAF inspects what the user's browser sends. RBI moves execution off the user's browser but pays in encoded video and per-session compute. VITRO removes the underlying fact. The user's browser no longer runs the web application, reaches its origin, or holds its secrets. The mediated session itself becomes the access boundary.
This is not a feature an existing product can ship in its next release. A WAF, VPN, ZTNA gateway, VDI stack, or PAM proxy is built to let the user's browser reach the protected web application under controlled conditions. Removing that reach removes the product. Adopting the VITRO model means rebuilding from the access boundary up.
Why reasoning belongs after isolation¶
Isolation does not remove the need for security judgment. It changes what must be judged.
Without isolation, security must reason about everything that can happen inside the user's browser while the web application runs there. With isolation, that surface is gone. What remains is the mediated channel: the user can type, click, submit, navigate, upload. The remaining question is narrow — does this action belong in this session, on this surface, for this purpose, at this level of consequence?
Excalibur Context Bubble answers that question. Context Bubble is the pre-execution reasoning layer of VITRO: for every action the user attempts, the action is held in flight while the reasoning layer decides whether it fits. If the answer is yes, the remote browser performs it. If the answer is no, the remote browser never sees it. There is no block-after-the-fact and no alert-after-the-fact. The decision happens before the action exists in the protected system.
When the answer is unclear, the reasoning layer does not silently fail. It pauses, discards the attempted action, and tells the user why it was not accepted. The user has two choices: end the session, or continue and try again — typically with a different input. The action that triggered the pause never reaches the protected system. A genuine user who typed the wrong thing into the wrong field corrects course in seconds; a user with nothing better to try ends the session. Most ambiguous actions resolve at the user, without a human reviewer.
Identity decides who reaches the system. Access policy decides what they are authorised to use. Neither decides whether a specific high-consequence action belongs right now. VITRO adds that decision.
Why the decision path has no rules¶
Rule-based security follows from the wrong starting point. If the user's browser runs the web application, security has to keep separating good behaviour from bad inside it by recognising known payloads, signatures, and evasions. That is why the industry lives inside a permanent update cycle of signatures, regexes, allowlists, denylists, and exception logic.
VITRO changes the starting point. Isolation removes most of the exposed surface before any decision is made. Contextual reasoning governs what is left by asking whether the action belongs, not whether a string matches a catalogue entry. The decision path has no rules: it is not a pattern-matching program that must be updated whenever a new payload form appears. Policy and governance remain; signature maintenance does not.
This is why the model is zero-day resistant. A novel payload still has to act through the user's browser, and the user's browser does not run the web application. The decision layer does not need to recognise the payload to judge whether the action makes sense.
It also raises the cost of attacking at scale. A signature bypass scales: one payload works against every system using the same signature. A coherent-looking action does not. It has to match the specific application's workflow, the session's prior actions, and the expected next step. That match has to be reconstructed per target.
Where context enters¶
The reasoning layer judges whether an action belongs by comparing it to what the session is for.
For many sessions, what the user has already done and what the web application is currently showing are enough. An operator can also supply three kinds of standing or per-session context. A role expectation describes what a class of users (for example, a finance approver, an infrastructure operator) is normally allowed to do. A target expectation describes what a specific protected web application is intended to be used for. A just-in-time (JIT) context describes the purpose of this specific session — for example, "approve refund for ticket INC-4821 up to 5,000 EUR" or "rotate the TLS certificate for api.corp.com".
None of this changes the architecture. The user's browser still does not run the web application. Context only changes how precisely the remaining actions can be judged. Missing or wrong context can lower precision. It cannot put the web application's runtime back in the user's browser.
The synthesis¶
No single component is the breakthrough on its own. DOM mutation streaming makes remote execution usable. Density makes it affordable. The pre-execution reasoning layer turns the mediated browser session from a delivery mechanism into a security boundary.
For decades, web security has tried to compensate for one premise: the user's browser runs the web application and holds its secrets. WAFs inspect traffic. VPNs and ZTNA restrict network reach. PAM vaults credentials. RBI moves execution but often pays in latency and cost. VITRO rejects the premise itself. It removes the runtime from the endpoint and governs the remaining user-action surface before execution. The system no longer has to recognise a threat pattern to stop it. It only has to decide whether the action makes contextual sense. The mediated session is not just the way the user reaches the web application. It is the security boundary.