CyberCursor Remote 0.4.1 · Endpoint 0.3.2 · Easier desktop sign-inExplore the pilot builds
SECURITY

Security practices we can show.

How this website, the portal, the controller channel and the endpoint agent are protected, as recorded in the release records. No certification is claimed; the evidence is listed instead.

Layered glass infrastructure and a shield-shaped security object
Original editorial illustration · Conceptual architecture
WEBSITE

This website.

A static site with no third-party code and a strict content policy.

01

Content Security Policy. Scripts and styles load only from this origin; inline scripts, inline styles and third-party assets are refused by the browser. The build checker rejects any page that would need them.

02

No trackers. No external fonts, analytics, advertising or embedded trackers load. The only interactions that leave the page are the contact form and the installer downloads.

03

TLS everywhere. The site, the portal and the endpoint bootstrap listener are served over TLS with their own certificates; the portal and the site are separate origins.

04

Reproducible builds. Every page is generated from the repository with a hash manifest; publication is guarded by a release lock, byte readback and a rollback target.

CONTACT

Contact intake.

Your enquiry is encrypted at rest and never leaves the host.

01

Isolated service. A separate standard-library service on the loopback interface, running as its own system user with a memory limit and a restricted writable directory.

02

Encrypted fields. Contact fields are encrypted with AES-256-GCM and authenticated against the unique reference you receive. Files are mode 0600 in a mode-0700 directory.

03

Abuse limits. Exact origin check, JSON only, explicit consent, validated fields, an 8 KB body limit, a honeypot and per-IP and global rate limits.

04

Bounded retention. Requests are kept for at most 90 days, with encrypted backup rotation for a further 30. There is no email, CRM delivery or public request list; review is a private, mode-0600 export.

PORTAL AND CONTROLLER

Portal and controller.

Named people, a second factor, and a channel a browser cannot imitate.

01

Authenticator for everyone. Sign-in uses OpenID Connect with a required authenticator at first login. Sensitive operations such as creating keys or starting sessions require recent MFA.

02

Request integrity. Mutations require CSRF and origin checks plus an idempotency key, so a replayed or forged request is refused.

03

Signed controller channel. The installed controller creates an ephemeral Ed25519 key per login and signs every request; proofs are accepted for 30 seconds, nonces are single-use, and keys never cross the renderer bridge.

04

Browser refusal. Privileged requests carrying browser Fetch Metadata are refused, so a browser cannot use a controller-bound session even with a valid signature. This is a channel boundary, not device attestation.

05

Tenant isolation. PostgreSQL row-level security is forced on tenant tables; the runtime role has no delete permission on session records, and the audit log is append-only by design.

06

Scope on every request. Management and guest scope is recomputed from current membership on each request and each relay check; expiry and revocation take effect immediately.

ENDPOINT

Endpoint agent.

Enrollment is signed and single-use; sessions are announced; operating-system controls are respected.

Enrollment sequenceThree stations: a client or group license key, the endpoint installer where the key and an agent name are entered, and the enrolled record that appears in the portal before a controller session.01 / LICENSE KEYOwned by the client. Scoped to a device groupwhen needed.02 / INSTALL AND ENROLLEntered once in the endpoint setup. NoID-and-password pairing step.03 / REVIEW AND CONNECTThe record appears in the intended workspace.Review it before connecting.CLIENT KEYNorthstar IT · every enrolled endpointGROUP KEYLondon office · lands in one groupCreated and revoked by the client ownerCyberCursor Agent setupLICENSE KEY••••-••••-••••-7F2AAGENT NAMELON-FINANCE-04Windows x64 · Arm64macOSChoose the processor architecture that matches the computerLON-FINANCE-04Windows 11 Pro · London officeENROLLED 10:42NEXT STEPOpen the session from the installed controllerOS permissions and report freshness are checked hereKEY + AGENT NAMEENROLLED RECORDFICTIONAL EXAMPLE DATA · THE SEQUENCE IS THE SHIPPED PILOT WORKFLOW
Enrollment sequenceShipped pilot workflow
01

Signed setup profiles. A license-key bootstrap returns a short-lived, signed profile bound to the installation key, request and origin; the installer verifies a pinned signing key before enrollment.

02

Single-use grants. Each machine gets its own single-use grant even when many machines share a key; a retained identity cannot be reassigned by entering a different key.

03

Certificate identity. The agent authenticates with its device certificate; heartbeats and queue reads use that identity, and key material is encrypted with the server’s protected key.

04

No permission bypass. macOS Screen Recording and Accessibility permissions are granted locally or by the owner’s management deployment. Administrator access is required to install machine services. On Android, the device user accepts every session and only they can turn on the accessibility service used for control.

AUDIT

Audit.

Append-only, hash-chained, without passwords.

Operator actions, session intents and outcomes, account changes and enrollment completions are recorded in an append-only audit log with a hash chain per tenant (decision D010). Account mutations are audited without passwords, and the log is append-only by design. Guests and management users cannot read the audit at all.

This is a self-claim from the release records, not an audited certification. The verification report notes that database superusers and compromised writers remain threats, which is why external checkpoints and restore verification are part of the plan rather than assumed.

Access and audit context
NOT CLAIMED

What is not claimed.

The gaps are stated so you can plan around them.

No SOC 2, ISO 27001 or sector compliance certification is claimed.

Only the Mac controller carries a Developer ID signature, and it is not yet notarized; the other desktop builds are unsigned and the Android APK uses the debug certificate. Publisher signing and notarization are continuing release gates.

The signed controller channel is a channel boundary. Managed-device attestation would need device certificates and deployment policy.

The endpoint’s remote engine is a pinned provider process behind the gateway; the engine itself is not described as least privilege.

No penetration test report or bug bounty programme is published.

REPORTING

Reporting a concern.

Write to us directly. Please do not include credentials or personal data of third parties.

Send security concerns to connect@cybercursor.com with the product, version, build hash and steps to reproduce. The contact form on this site is encrypted at rest and reviewed privately, and is also acceptable for a first message.

Please allow time for a reply before public disclosure. We will acknowledge the report, confirm whether it reproduces, and record the fix in the release notes when it ships.

Trust page Release notes

Build your next endpoint workspace.

Start with a conversation about your fleet, your workflows, and a controlled pilot.