Avenge | The session follows the clinician

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 pixels and keep the record still. That is the job of the session layer 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.

The record never moves

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 to a machine. The hospital signs an identity for each thing that acts on her behalf, using the same identity layer that decides what each one may do, and that is not only hardware: her phone, her workstation, a tablet on a ward, or an AI assistant working under her authority each hold one. Any of them can list her running session, attach its pixels, 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 the hand-off is written to the log. 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 pixels come 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 in the log. The keystrokes themselves, and the pixels, are not.

Avenge desktop showing the working view: files, notes, messages, and a to-do window on the local screen — The working view on the device. What crosses the hallway is this screen, not a copy of the record.

But if the pixels can reach any screen, the next question is who at that screen is allowed to act.

Three screens in a row, exam-room workstation, physician’s iPad, office desk, with the input lease moving between them, and one record fixed below on the machine that holds the session — The working view follows the clinician from screen to screen. The record never moves; the screen receives pixels and sends input.

Watchers, by policy

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 pixels 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 pixels and nothing else. The same line separates a person from an assistant: software working under a clinician's authority is given pixels, or given the keyboard, as a decision someone made and can revoke, never as a side effect of being trusted to run at all. 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 pixels 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.

Two share invitations side by side. The left is view only. The right includes keyboard and mouse. — The recipient sees the grant before accepting. One invitation is view only. The other includes the keyboard. Nothing connects until they accept. The applications in the shot are test apps on our desk, not a clinical record.

Therefore the real question is where a keystroke can come from at all.

No keystroke from the control plane

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.

Two lanes: a control plane carrying device identity, SecurisNexus, and session host policy over mutually authenticated TLS, and a data plane carrying execution, video, and input between the device and the host, with a barred mark showing no path from the control plane into the session — The control plane carries decisions. The data plane carries the session. Nothing in the control plane can type into a chart.

What a stolen tablet holds

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.

Her tablet, stolen

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.

Her credential, phished

The attacker gets the sessions her role and her device's tier allow, and nothing beyond them. No access her role was never granted, and no access that leaves no trace: every one writes a log entry naming what was opened and from which device.

The control plane itself

The attacker can record grants and leases, within what the local rules and the central policy allow. Not a frame, and not a keystroke.

One source's stream key

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.

A table of four losses, the tablet, the credential, the control plane, one stream key, with what the attacker gets and what they do not get for each — Four things a lost device usually carries, and what an Avenge session leaves on it.

The shared window

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.

Three boxes: the owner’s host signs and enforces a share grant, SecurisNexus carries it as a courier and cannot widen it, the recipient’s viewer opens the signed invitation and pins the source key; below, revocation as three cuts — Sharing one window: the owner’s host enforces, the control plane only carries. Revocation is three cuts, any one of which ends it.

Share sheet with application, recipient desktop, sound, keyboard and mouse, and a fifteen-minute limit — The four decisions, set by the owner before the invitation is signed: which application, whether sound travels, whether the keyboard travels, and for how long.

The source, under her own identity, 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.

A shared window marked view only, after the application disconnected — After the share stops, the window says the application disconnected. Reconnecting is a new request. The stream that was granted is gone.

A redacted share grant in JSON, role observer with view and audio, a 900 second lifetime, an ed25519 signature, and separately signed origin labels, with callouts for who, what, how long, and signed — A grant is a small signed object: who, which operations, for how long, signed by the owner. A real grant from a test share, 17 September 2026, with identifiers and keys removed.

Why the line holds where it does

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.

On your hardware

Everything on the path to a patient record runs on the hospital's own equipment: the identities, the policy, the keys, the sessions, and the records themselves. The clinic signs its own devices and its own people. We hold no key to a patient's data, which is a property of how the system is built rather than a promise about how we behave.

VivaSecuris workspace home. The line under the mark reads: Your workspace. Your control. — The workspace on the machine that holds the session. What the glass says is the ownership rule: your workspace, your control.

That is also what makes it operable by a hospital with one and a half IT staff. Every enforcement point decides locally, so the building keeps admitting and refusing correctly whether or not it can reach anyone outside, including us.

Avenge is one layer of a set that fits together. SecurisNexus issues the identities and decides what each one is allowed to do. Avenge carries the session to the glass and holds each device to that decision. In a hospital deployment, both would be configured for care and narrowed by the hospital's own signed policy.

Avenge runs this way on our own fabric and on the founder's desk every day, and we would rather show it to you than describe it.

Therefore, the questions to put to any remote-access layer, ours included.

What to ask

A session layer sits beside the foundation every hospital is already building: the HHS cybersecurity performance goals for the sector, which the department describes as voluntary, cover multifactor authentication, asset inventory, and centralized log collection.^[4] On top of that foundation, 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 pixels 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.

← Back to Blog

Evaluating remote access? Ask for the same evidence.

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.

Network and remote-access monitoring — see every remote session, vendor login, and device on your clinical network, with a record you can reconstruct months later. Observation only; we never block care.
Security testing & assessment — test the boundaries of the remote access you have, not the login: what a lost device holds, whether a watcher can type, whether revocation stops a live session. Reports written for auditors and insurers.
Medical device security — assess the devices on your network and document what a gateway can and cannot enforce. Manufacturers preparing an FDA submission can start with our 524B evidence checklist.
AI systems before clinical use — review an assistant’s permissions, delegation, and behavior under pressure before it touches patient data.
Security training — role-based sessions for clinicians, biomed, and IT, tied to issues we actually see — risk reduction, not compliance theater.

Request a scoping call

Or write to josh@vivasecuris.com.

References

NIST Special Publication 800-207, Zero Trust Architecture, August 2020. https://csrc.nist.gov/pubs/sp/800/207/final
NIST Special Publication 800-46 Revision 2, Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security, July 2016. https://csrc.nist.gov/pubs/sp/800/46/r2/final
Arcan, an open-source display server, compositor, and the a12 network protocol, by Björn Ståhl. https://arcan-fe.com/
U.S. Department of Health and Human Services, Healthcare and Public Health Cybersecurity Performance Goals (voluntary). https://hhscyber.hhs.gov/cybersecurity-performance-goals.html