How the session layer under VivaOS separates watching from driving from running, and what is proven so far
A physician reads a chart at the exam-room workstation, walks out with a tablet, and finishes her note at the desk in her office. Three screens in one afternoon. In most hospitals, what makes that possible is a copy: the record, or a remote session that holds all of it, follows her from machine to machine. Whatever follows her can be lost, stolen, or watched.
The alternative is to send the picture and keep the record still. That is the job of the session layer of VivaOS, which we call Avenge, short for AV Engine: the audio and video engine that brings the working view to whichever screen the clinician is standing at. It treats watching, driving, and running as three separately granted things rather than one bundle. NIST treats authentication and authorization as "discrete functions performed before a session to an enterprise resource is established."[1] This article is about what has to stay discrete during the session.
For a hospital security leader the useful questions are concrete. What does a stolen tablet hold? Can the software that authorizes a session also type into it? When a colleague, or an ambulance crew, is shown a window, can they act in it? This article answers each for Avenge, and closes with where the work stands today.
NIST's telework guidance describes conventional remote desktop access plainly: the user "has keyboard and mouse control over the remote computer and sees that computer's screen on the local telework client device's screen," and most such systems "offer features for copying files from computers inside the organization to the teleworker's client device."[2] One channel carries the pixels, the keystrokes, the clipboard, and the files. Whoever holds the session holds all of it, and the session belongs to the machine it was opened on.
Avenge starts from a different ownership rule. A session belongs to the person, not the device. Any of the physician's enrolled devices can list her running session, attach a picture of it, and take over the keyboard by transferring the input lease. The transfer is one operation: the previous device loses the lease as the new one gains it, and both are recorded. What crosses the hallway is an encrypted stream and a thirty-minute lease, not a file.
That is the mechanism that retires the USB stick. The record stays where it runs and the working view comes to whichever screen she is standing at. It also answers the reviewer's question afterwards: who held the keyboard for this session, from when until when, and who it was handed to. That much is recorded. The keystrokes themselves, and the frames, are not logged anywhere.
But if the picture can reach any screen, the next question is who at that screen is allowed to act.
Watching and driving are separate grants. A supervising physician looking in on a resident's session, an auditor replaying an incident, a wall display at a nursing station, a corridor workstation anyone can walk up to: each can be given the picture with no possibility of acting in the record.
Two rules make that hold before the central policy is even consulted. A device carries a trust tier, and the shared-workstation tier is refused every input, audio, microphone, clipboard, camera, USB, and file-transfer lease, even when the person signed in owns the session. A person carries a role, and the observer and auditor roles can hold a picture and nothing else. Both are local decisions the central policy cannot override. Locking down a shared hospital workstation is one line of policy, not a second product.
The clearest case is outside the building. An ambulance crew today usually arrives with what the patient or a family member could tell them and what the radio carried, because the hospital's record sits behind an account in a record system, a managed laptop, and a VPN the crew does not have. In this design the crew's tablet is a device of a tier that can be shown a picture and can never hold a keyboard, and the hospital grants it a view of one patient's summary for the length of the run. Nothing is installed, no account is created, and no copy is made. When the run ends the grant expires and the tablet holds nothing. Access is faster because it is a grant on a view, not a provisioning project, and safer for the same reason.
Therefore the real question is where a keystroke can come from at all.
Every remote-access system has a control plane: the code that checks tokens, parses requests, and decides who may attach. It is the most exposed code in the system, because it is what the network talks to. In Avenge it is also the code that can do the least.
No endpoint on the control plane accepts a frame or an input event. The request that grants a device the keyboard is an authorization record, not a channel. Input exists only as events on the stream, and the stream is a different protocol on different keys: an x25519 exchange, a ChaCha stream cipher, a BLAKE3 keyed MAC on every packet, and a fresh set of keys for every connection.
The consequence is that the control plane can at worst be tricked into recording that a device may drive. It cannot inject a keystroke, because it never touches the stream. Driving a session takes the stream, and the stream is keyed to one source at a time.
Therefore the value of separating the flows is measured by what an attacker gets from any one of them.
NIST's advice on client devices is blunt: "organizations should assume that client devices will be acquired by malicious parties who will either attempt to recover sensitive data from the devices or leverage the devices to gain access to the enterprise network."[2] The point of splitting a session into flows is that no single loss yields the whole.
The device holds a key it cannot export and a session token that is expired or soon will be. It holds no record: no frame is ever written to disk on the device, and the session transfers no file. The same is true of the tablet in the ambulance.
The attacker gets the sessions her role and her device's tier allow, every one recorded. Not anything her role was never granted, and not silent access.
The attacker can record grants and leases, within what the local rules and the central policy allow. Not a frame, and not a keystroke.
That one source's pixels and input, for the life of that connection. Not any other source, and no action on the control plane.
But a list of what an attacker does not get is a claim. Here is the path where the whole thing has been shown enforced end to end.
She wants a second opinion, so she shares one application with a colleague. Before anything is signed, the owner decides four things: which application, whether sound travels, whether keyboard and mouse travel, and for how long, with a ceiling of twenty-four hours. The invitation is signed with her key and names the recipient's key. The colleague is shown exactly what they are accepting, and nothing connects until they accept.
The source, on her machine, enforces the grant. It refuses a viewer with the wrong key. It drops input from a viewer whose grant did not include control, and carries the keyboard for one that did. It sends sound only if the sound bit is set, and refuses clipboard and file segments the grant did not include. When she stops the share, the live connection closes and a reconnection is refused. The recipient pins her source key from the signed grant, so nothing in between can widen what was granted. This path admits nobody on a password.
Today, a grant issued with control carries real keystrokes to the owner's application, a view-only grant does not, and stopping the share closes the connection on both sides. A grant signed by the wrong owner, a revoked grant, and an ungranted key are each refused. In the clinic edition, sharing stays off until the hospital's own policy turns it on.
Underneath the session layer is Arcan, an open-source display server written by Björn Ståhl and released under the BSD licence.[3] It ships with no window manager and no policy. A script owns the screen and receives every event, and a program gets a keystroke only if the script hands it one; no program can read another's pixels, and sharing and recording are a single primitive the script gates. That is what let the shared-window source enforce the grant in front of the pixels rather than behind them.
Therefore that enforcement point, in front of the pixels, is the shape the whole system takes.
The shared window works today: signed, time-boxed, key-pinned invitations, with sound and control as separate switches, enforced on the owner's machine. The session layer that owns sessions, leases, device tiers, and roles is built, and it records every grant and every hand-off of the keyboard.
What comes next is bringing every path to the footing the shared window already has, and connecting a record system behind the ambulance workflow.
Avenge is not yet installed in a hospital. It runs on our demonstration fabric and on the founder's own desk every day, and we would rather show it than describe it.
Therefore, the questions to put to any remote-access vendor, us included.
None of this replaces the basics. The HHS cybersecurity performance goals for the sector, which the department describes as voluntary, cover multifactor authentication, asset inventory, and centralized log collection,[4] and a session layer belongs beside that foundation. With that said, five questions, each of which can be tested rather than taken on faith.
What does a lost device hold five minutes after it is lost? Ask for the answer as a list of files on the device, not as a feature name.
Can the piece of software that authorizes a session also type into it? If it can, the most exposed code in the product is also the most powerful.
Can a watcher become a driver without a new grant, and who would know? Ask where that is enforced: in a client that chooses to behave, or in front of the pixels.
When you revoke, does the live stream stop, or only the next one? Both answers can be acceptable. Only one of them should be called revocation.
Which of these can you show me? A demonstration is evidence. A feature list is not.
The standard is simple to state. Nothing travels with the physician's view except the picture and, when granted, the keyboard, for a bounded time, on the record. The same standard puts one patient's summary in front of an ambulance crew without giving them an account, a laptop, or a copy. That is what Avenge is built to do, and we are glad to show it.
The article asked what travels with a clinician's view and how you would check. The session layer above runs on our demonstration fabric today, and we are glad to show it. What we can do for you now is put the same questions to the remote access you already have. The services below are how that work gets done; the platform this article belongs to is described on Where we're headed.
Or write to josh@vivasecuris.com.