01Request
BoundClient and device selected
Native remote operations
Start remote support with the client context already in view.
Review the device, permission and session requirements before connecting. Explore desktop, shell and file workflows, with consent and an activity record appropriate to the task.
Remote access
Every session starts with a trust decisionRemote session boundaryIllustrative session
02Consent
RequiredRole and local policy checked
03Connect
HeldSession scope approved
04Record
AwaitingOutcome and audit retained
Every access has a boundary
Useful access. Explicit control.
Bind the technician, endpoint, customer, purpose, approval, and permitted tools to one session.
Illustrative workflow · explore the steps · no action is executed
01
Request the session
Resolve tenant, endpoint, technician, role, MFA, entitlement, reason, and consent policy.
Confirm this step for your release, permissions and environment.02
Establish trusted transport
Use a signed start envelope, short-lived session identity, WebRTC, and regional TURN when needed.
Confirm this step for your release, permissions and environment.03
Close and audit
End access, settle recording policy, hash evidence, and attach the result to the activity timeline.
Confirm this step for your release, permissions and environment.Start the right session without losing consent, scope, or cleanup.
Retain consent, connection, control, recording, timeout, and cleanup evidence.
Inside the workflow
The work this connects.
- Remote desktop
- Use native WebRTC control with direct connectivity or regional TURN fallback.
- Remote browser
- Open an audited browser workflow without losing the client and device context.
- CLI and terminal
- Provide authorized PowerShell, shell, or network CLI access through governed sessions.
- Tunnels and file tools
- Use policy-controlled TCP tunnel, file browser, clipboard, and transfer capabilities.
- Consent and recording
- Apply attended or policy-approved access, recording rules, timeouts, and session evidence.
Try one useful scenario
Choose a remote mode and verify consent
Fictional attended session: the user approves screen sharing for one ticket and ends it when the task is complete. Fictional unattended session: an administrator authorizes a bounded maintenance task for a named device and time window; an expired grant blocks reconnection. Screen control manipulates the desktop; a shell runs commands; file transfer moves authorized files; a tunnel carries scoped traffic. Each mode needs separate release evidence.
Illustrative evaluation scenario, not a recorded product result.What a useful result must show
Record session identity, target, actor, consent or unattended grant, start/end, actions, transfer and recording events, timeout and cleanup. Renew authorization when target, privilege, mode or approved window changes. Test Windows, macOS and Linux independently.
Get the evaluation worksheet →Check the support boundaries
- Windows, macOS and Linux by agent version
- Screen control; shell commands; file transfer; elevation
- Recorded events, retention, bandwidth and tunnel support
- Attended consent and separately authorized unattended access
Recording is not assumed to capture every event or screen. Confirm retention, user notification, bandwidth and any recording exclusions in the evaluated release. An unattended session is not permission for unrestricted access.
Check public evidence and availability →Scope, availability and evaluation details
Platform capabilities differ by operating system and agent release.
Offline, revoked, expired, wrong-region, or locally denied sessions fail closed.
The proposed $99 monthly model includes the target product scope for evaluation, unlimited technicians, unlimited customers, and the first 50 managed devices. Final terms require confirmation. See transparent pricing →
Review full environment and integration scope
Agent, WebRTC, and regional TURN
The endpoint agent and regional signaling/TURN infrastructure establish the session while the browser receives only the scoped session it is authorized to join.
Launch from device or service work
Remote access can begin from an authorized device or ticket context and keeps consent, approval, recording, timeout, and session-cleanup evidence attached.
Native Dayrook Remote launches from authorized device or service context; optional third-party connections do not replace the native session contract.
Questions, answered
Before you choose your next step.
Is remote access browser-based?
Target design: Dayrook uses a native WebRTC workflow for browser-accessible remote desktop and related tools.
Can users be asked for consent?
Target design: Consent and unattended-access behavior are determined by tenant and endpoint policy.
Are sessions recorded?
Recording is policy-controlled. When required, encrypted recording evidence is stored in the selected regional object path.
Do third-party remote tools launch the session?
Native Dayrook sessions use WebRTC. Connected remote providers may supply account or inventory context where supported, but do not replace the native session owner.