Management portal
Fleet overview, inventory, performance, groups, licences and users in the browser. File listings are read-only here.
HTTPS · administration onlyPLATFORM / ARCHITECTURE
Four layers.
One boundary.
Administration lives in the browser portal. Hands-on work lives in the installed controller. A first-party gateway authorizes every session, and the endpoint agent announces it. This page describes the shipped pilot, with its limits, as recorded in the release records.
Pilot workflowCurrent availability
04
Portal. Browser administration; file listings read-only.
03
Controller. Installed Windows, macOS and Linux app; sessions, files, terminal.
02
Gateway. First-party API; session intents; hash-chained audit.
01
Endpoint. Identity, heartbeat, session notice and privacy bar.
LAYERS
Each layer has one job.
The separation is the product: the portal cannot start a session, and the controller cannot run fleet jobs.
Desktop controller
The installed Windows, macOS or Linux application for interactive screen access, bounded terminal commands and file changes.
Authorized session · authenticator sign-inEndpoint agent
Identity, reports and authorized actions on the owned computer. It shows the session notice and privacy bar.
Reports · identity · noticeEnrolled endpoints
Windows, Mac and Linux computers enrolled with a client or group key. Android phones enroll the same way for attended sessions.
License-key enrollmentThe web portal is the client administration and observation surface. CyberCursor Remote is the interactive access surface on Windows, macOS and Linux; its interface is bundled inside the app and operating it requires no browser. The endpoint app and its background services keep an enrolled identity, send heartbeats and show the session notice and privacy bar while a session is open. On Android, the endpoint app asks the device user to accept every session and keeps a Stop sharing notification visible.
Between them sits a first-party API and session gateway with PostgreSQL behind it: tenant row-level security on every table, an append-only hash-chained audit log, and session records that store who asked, for which endpoint, in which mode, with which deadline. A platform Super Admin administers organizations and is excluded from endpoint operations.
BOUNDARY
What runs where.
Seven workflows, two surfaces. The portal refuses interactive work by design and shows controller guidance instead.
Browser remote and Android screen routes answer 403 desktop_required: a browser cannot consume a desktop connection proof or retrieve an interactive operation result. Creating a read-only request in the portal grants no permission to execute another operation kind, and cancel is controller-only.
Existing automation stays separate on purpose. Approved scripts may change files as part of administrative jobs under their own approval rules; the controller boundary does not disable those jobs, and no job or script API is exposed through the desktop app.
SESSIONS
The session path.
Every interactive session follows the same six steps, whether the operator views or controls the endpoint.
01
Request. From the installed controller: endpoint, mode (view or control), a support reason and a bounded duration. The server records an immutable intent.
02
Prepare. The gateway prepares a private, finite share for exactly that endpoint. A lost response is marked unknown rather than retried blindly.
03
Connect. The controller receives a hashed, single-use connection proof valid for at most 30 seconds, then opens the session socket with it.
04
Announce. The endpoint shows a session notification and keeps a privacy bar visible. For unattended desktop access the saved grant replaces an approval prompt; Android always asks the device user.
05
Stream. Bounded, validated screen tiles and input messages only. View mode rejects keyboard and mouse input; held keys are released on disconnect.
06
End. Logout, policy change, explicit End or expiry closes both sockets and removes the share. The outcome stays in the audit log.
Session state moves through requested, preparing, ready, consent pending and active to ended, denied or expired. Active means a bounded screen tile was observed after valid screen dimensions were received. Unattended sessions are bounded to two hours; the controller currently requests one hour. Attended desktop sessions keep a five-minute bound. Android sessions are always attended and end after at most ten minutes.
Current login membership, recent MFA, the attended policy and the exact healthy endpoint binding are rechecked before forwarded messages and periodically during quiet streaming. A new login of the same account cannot take over an earlier session.
CHANNEL
The controller channel.
Why a browser cannot pretend to be the installed app, and what that guarantee does not cover.
01
Ephemeral key. Signing in creates an Ed25519 key in the controller’s main process. Its public key is bound to the login state and the resulting server session.
02
Signed requests. Each API and WebSocket request carries a proof over method, exact URL, origin, tenant, cookie hash, CSRF token, idempotency key, timestamp, nonce and body hash.
03
30-second window. Proofs are accepted within 30 seconds and a nonce cannot be reused. Logout, session expiry, restart and membership checks still invalidate access.
04
Nothing crosses the bridge. Keys, cookies and CSRF tokens never cross the renderer IPC bridge and are not saved in preferences. There is no embedded reusable app secret.
05
Browser requests refused. Privileged requests that carry browser Fetch Metadata are refused, so a standard browser cannot use a controller-bound session even with a valid signature.
06
A boundary, not attestation. This is a channel boundary. An authenticated non-browser client could implement the protocol; managed-device attestation would be separate work.
LIMITS
Limits you can test.
The pilot enforces its boundaries in the server and the agent, not in the interface. Each number here is recorded in the release records.
Terminal execution keeps the endpoint’s OS service-account permissions. Directory removal is non-recursive. Full-size resumable transfer is separate work.
PLATFORMS
What runs on which platform.
Controller and endpoint agent are separate milestones for each operating system.
At this publication CyberCursor Remote is 0.4.1 for Windows, macOS and Linux, and CyberCursor Endpoint is 0.3.2 for Windows, macOS, Linux and Android. Windows and macOS builds cover two processor architectures each, Linux packages cover amd64 and arm64 as .deb and .tar.gz, and Android has one APK for Android 12 and later. Controllers older than 0.3.3 cannot present the session proof and must upgrade before interactive testing; attended Android sessions need controller 0.4.0. Endpoint identity and credentials are preserved across controller upgrades.
The Mac controller is signed with a Developer ID but not yet notarized; the other desktop installers are unsigned and the Android APK is signed with the Android debug certificate as an evaluation build. Linux is tested on Ubuntu 24.04 arm64 with X11, and Android on the Android 16 emulator. Physical x86_64 Linux hardware, Wayland, physical phones, publisher signing and notarization, production physical-endpoint screen and input acceptance and the Windows native Files and Terminal UI acceptance are continuing release gates.
EVIDENCE
Assurance you can ask to see.
Implementation checks are not certification. They are the evidence behind each statement on this page, and the list of what remains open.
Implementation evidence for the controller boundary release includes the checks above plus native transport, proof and IPC tests, profile and identity tests, and Go unit and race tests. Production byte delivery and sign-in validation are recorded after each publication.
Still open: physical Windows, macOS and Linux remote pixels and input on production endpoints, attended sessions on physical Android phones, Windows native Files and Terminal UI acceptance, publisher signing and notarization, and provider outage timing. No compliance certification is claimed.
QUESTIONS
Questions to take into your pilot.
Operational details matter as much as the diagram.
Is CyberCursor only a web application?
No. The web portal handles administration and observation. An installed Windows, macOS or Linux controller is required for interactive endpoint access.
Does an enrollment key become the device’s permanent identity?
No. Each enrolled installation has its own identity and certificate. Reusable keys authorize setup into the chosen client or group.
Is the controller channel device attestation?
No. The current channel enforces the portal/controller product boundary and current authorization. It is not advertised as managed binary attestation.
Are every remote and security capability production-validated?
No. Provider availability, real endpoint acceptance and security coverage have distinct gates. Evaluate the specific workflow and platform you require.
RELATED READING
Continue exploring.
Connect the architecture to the rest of your endpoint workspace.
RESOURCESPILOT
Endpoint deployment guide
Prepare client ownership, groups, license keys, platform builds and acceptance checks for a controlled CyberCursor pilot.
Explore RESOURCESPILOTCyberCursor platform architecture
Understand the roles of the web portal, installed controller, endpoint agent, identity controls and provider-connected reporting.
Explore RESOURCESPILOTEndpoint platform evaluation checklist
Compare remote support, endpoint operations and security tools using workflow evidence, platform coverage and clear commercial assumptions.
ExploreBuild your next endpoint workspace.
Start with a conversation about your fleet, your workflows, and a controlled pilot.