Home/Platform/Governed Sessions
Remote access
Reach the resource. Keep the work accountable.
A governed remote session starts with a request. Policy decides, a credential is checked out by reference, the connection is authenticated before the session exists, and the session stays attached to the operation it belongs to.
How it opens
The connection is authenticated before the session exists.
That ordering is the whole design. If the password goes in after the window is open, then someone typed it, and someone can type it again tomorrow. Here the credential is resolved and used to authenticate the connection first — and the person at the keyboard never sees it.
Two modes, one rail
Native RDP and Seraph Remote are different things.
We keep them separate on purpose, because a buyer who is told "remote access" and shown two different technologies stops believing the rest of the sentence. Both ride the same outbound tunnel and the same policy point. What happens at the far end is not the same.
What we claim today: a session is requested, checked against policy, authenticated before it opens, attached to an operation, and its facts land in that operation's record. What we do not claim: complete session recording and playback across every surface. Capture exists and is being proven one surface at a time, and until a surface passes a full end-to-end run on a live system we will not sell it. If you need session video as a control, ask us on a call and we will tell you exactly where each surface stands rather than pointing at a feature grid.
What lands in the record
Six facts, attached to the operation, not to a tool's own log.
A session here is not a free-standing event. It is part of an operation, and it writes into the same record as the work it was opened to do.
What we do not do
- We do not claim complete session recording and playback across every surface.
- We do not claim multi-monitor remote access.
- We do not put file transfer in the shop window. It is not the reason to buy this and we will not pretend otherwise.
- No technician views or drives an end user's browser. Browser-based attended support here is a join code with an explicit consent step and a revoke — the lifecycle, not the screen.
The path in
Your machines dial out. We never dial in.
There is no inbound listener for us on your network and no port for you to open. Both ends of a session dial out to the gateway, and the gateway is where policy, identity and the audit write happen.
Outbound only
The agent on the machine and your console both dial out over an encrypted WebSocket. Nothing on your network is exposed for us to reach, which is usually the first question a security reviewer asks.
Trust center →Shared or your own
You can sit on a shared gateway, or run a dedicated one for your workspace. Both are real options today, and the choice does not change how policy, leases or records behave.
Roles & tenancy →One region today
The gateway runs in a single cloud region. If that region has an outage, new sessions pause and reconnect when it comes back — we do not silently reroute. Leases still expire on schedule and audit writes still land, because neither depends on the session transport.
Multi-region and multi-cloud failover is something we intend to build, not something we are selling. Anyone quoting you an always-on remote-access guarantee at this stage is quoting you an ambition. See the roadmap for the order we are doing things in.
The questions that come up on the call.
Can the AI open a session by itself?
It has to ask, exactly like anything else. It files a request under its own principal with its stated intent, policy is checked, a human authorizes, and it gets a scoped lease with an expiry. It can never approve its own request — that invariant is enforced in more than one place on purpose. See Commanded Autonomy.
What does the person at the desk see?
For an attended session, a join code, an explicit consent step, and a revoke they can use at any point. Consent and revocation are recorded events, not UI politeness. For unattended work on a server there is no person to prompt, which is exactly why the authorization and the lease matter so much.
What happens if the gateway is unreachable?
The session fails closed with a clear reason. It does not fall back to some other route — there is no second path, by design, because a fallback transport that skips the policy point is not a feature. Your leases still expire on schedule and your audit writes still land, because neither of those rides the session transport.
Do you record the screen?
Narrower than you want us to say. The operation record is complete — who authorized, which credential reference, the lease and its expiry, the job, the machine's answer. Screen capture exists and is being validated surface by surface, and we will not describe it as shipped recording and playback until each surface has passed a live end-to-end run. The receipt is the artifact we are willing to be measured on today.
Can a technician take over while the AI is working?
Yes, mid-operation. Taking the wheel mints a fresh lease under the technician's own identity — it does not inherit the agent's. The work continues in the same operation and lands in the same record, so the handover is visible rather than being a gap in the story. How leases work →
Bring the hard question
Watch a session open without anyone typing a password.
We will run one live, then open the record it wrote and show you which fields came from the machine rather than from us.