Security

This page explains the security boundaries of VARUA Remote Control, a user-controlled bridge between AI/MCP clients and explicitly paired computers. It also explains which safeguards VARUA provides and which decisions remain with the person who connects and operates a computer.

Identity, pairing, and encrypted connections

Users sign in through OAuth. A computer must run a locally authorized VARUA Remote Control agent and complete the account pairing flow before the account can operate it. Agents use per-device cryptographic identities, and production connections use TLS. Knowing an IP address alone does not authorize pairing or remote access.

Users should revoke devices and end sessions they no longer recognize. Compromised AI-client accounts, operating-system accounts, and locally granted permissions can still create risks even when the VARUA connection is secure.

Local permission and execution boundaries

The local machine owner chooses whether to enable filesystem changes and process or terminal execution. These permissions are separate from read-only inspection. An enabled capability allows subsequent authorized AI/MCP requests; it does not guarantee a fresh, on-device confirmation before every operation.

Dedicated filesystem tools are limited to configured authorized roots and protected-path rules. Commands and interactive shells must start in an approved working directory but then run with the operating-system permissions of the agent's local user. VARUA is not an operating-system sandbox: such processes may be able to read or change other OS-accessible resources, contact networks, install software, or run destructive instructions.

Long-running processes, searches, and terminal sessions may persist during transient network disconnects. Use the available management tools to inspect, stop, or cancel work, and revoke access when it should no longer be possible.

AI-client integrity and prompt injection

The connected AI client, its account, and the information it reads can all affect the commands it requests. Untrusted text in a repository, document, website, message, or tool response may contain malicious instructions intended to redirect an AI assistant (prompt injection). A compromised client account could also ask VARUA to perform actions the machine owner never intended.

VARUA authenticates and authorizes tool requests and enforces applicable local and public security controls. It cannot reliably determine whether a permitted request reflects a person's true intention or was induced by hostile content. Protected paths and credential checks are important but do not guarantee that every unsafe command or disclosure will be stopped. In particular, an authorized shell can access resources permitted to its operating-system user outside the dedicated filesystem tools' root restrictions.

For stronger separation, run the agent under a minimally privileged account or inside a properly configured virtual machine or container with only the necessary files and networks exposed. Protect AI accounts with multifactor authentication where available, and review sensitive operations before authorizing autonomous or long-running work.

Credential and data safeguards

The public MCP endpoint enforces credential-value checks and protected-path restrictions, with an additional gateway-side secret scan. These are defense-in-depth safeguards, not a guarantee that every sensitive value or unsafe instruction will be detected. Do not deliberately send passwords, private keys, access tokens, or other secrets to an AI client.

Private-use security profiles are distinct from the enforced public MCP profile. Changing a private profile does not disable public MCP protections. Users should understand the additional risk before relaxing their locally chosen protections for private use.

Machine file contents, command output, and terminal output must travel over the authenticated connection when the user requests that information. VARUA does not retain those results as hosted control-plane content by default. A connected third-party AI service may process or retain the returned information under its own privacy practices. The VARUA Privacy Policy describes operational metadata and retention separately.

User responsibilities and safer operation

Pair only computers and accounts you own or are expressly authorized to control.
Use a dedicated, unprivileged operating-system account for the agent when practical; avoid running it as root.
Limit allowed filesystem roots, local capabilities, and connected AI clients to what your work actually needs.
Review AI-generated instructions before enabling sensitive workflows; test destructive changes on disposable data first.
Keep independent, recoverable backups. Secret checks and path restrictions cannot prevent every mistaken or destructive command.
Check ongoing jobs and terminals, rotate exposed credentials, and promptly revoke unexpected access.
Follow the laws, privacy obligations, contracts, and third-party platform rules that apply to the computers and data you operate.

Responsibility and limits

VARUA provides authentication, routing, scoped tools, and security controls for its hosted service and agent integrations. Users control which devices and capabilities they authorize, and their connected AI clients may request work within those permissions. VARUA does not select those user-directed instructions or promise that executing them will be safe or achieve the intended outcome.

To the extent allowed by law, users remain responsible for consequences of their own authorizations, instructions, and use of their computers. This is not a blanket waiver: VARUA remains responsible for obligations and liabilities that cannot legally be excluded, including applicable privacy, security, and consumer-protection duties. See https://varua.ca/terms for the governing terms.

Security reports and incident response

Please report suspected vulnerabilities privately to security@varua.ca. In-scope reports include security issues in VARUA-managed public services, Remote Control authentication and device pairing, public or private MCP authorization boundaries, and supported VARUA agent or dashboard releases. Bugs in independent AI providers, Auth0, Stripe, or other third-party services should also be directed to the operator of the affected service.

Include the affected feature or version, potential impact, minimal reproduction steps, and redacted evidence. Never include live tokens, passwords, private keys, unrelated customer content, or other people's personal information.

Test only systems, accounts, and devices that you own or are explicitly authorized to test. Do not access other users' data, attempt persistence, conduct denial-of-service or disruptive high-volume scans, use social engineering, or exploit a suspected issue to extract information. Please coordinate public disclosure of exploitable findings while they are assessed.

Response target: VARUA aims to acknowledge vulnerability reports within three business days, then triage severity and coordinate follow-up and disclosure as circumstances permit. This is a goal, not a guaranteed response time or a promise to remediate within a fixed period. VARUA will address security incidents and notify affected people or authorities where applicable law requires it.

If you suspect your own device or account has been compromised, disconnect or revoke the device, disable elevated local capabilities, rotate relevant credentials, review active jobs, and contact security@varua.ca.

Privacy and retention: https://varua.ca/privacy

Terms and acceptable use: https://varua.ca/terms

Help and reporting: https://varua.ca/support