Security Responsibility Boundaries

Dedicated physical nodes, controlled from access to secure return

VMKeep assigns a dedicated physical machine to every order; running instances are not shared with other tenants. The platform handles node delivery, account access, and incident assistance. Users are responsible for permissions and backups for credentials, repositories, models, signing materials, and business data.

Rent a Cloud Mac now View connection support

1 order: 1 dedicated physical machine
2 access methods: SSH command line and VNC graphical interface
365 days: Nodes remain operational

VMKEEP / SECURITY DOSSIER Node access control record

Four-layer model

Dedicated physical node One order maps to one physical device, not a virtual machine

Isolated

Account access control Login access, order ownership, and support tickets are linked

Controlled

Remote connection credentials Change the password after first connection and configure SSH keys

User-managed

Incident response process Status checks, evidence retention, and remote recovery assistance

Traceable

Four-layer security model

Identify who controls each layer before defining your team workflow

Security is not a single switch. Physical isolation addresses shared runtime resources, account controls confirm order ownership, remote connections determine who can access the machine, and operational procedures handle incident records and recovery coordination.

Physical layer

One dedicated physical device

Each order maps to a dedicated physical machine. Its CPU, memory, system disk, and runtime instance are not shared with other tenants. This is not a virtual-machine setup that divides one host among multiple users.

Delivered according to the order’s M4, memory, and storage specifications
The same order manages the physical node throughout the rental period
The node region is determined by the order and the current console response

Account layer

Orders, logins, and support tickets are linked

Your account identifies order ownership, shows the rental period, and lets you submit support tickets. Use a work email that can reliably receive verification messages, and promptly remove members who no longer work on the project.

Never share console login credentials
Update relevant passwords immediately after personnel changes
Handle billing and node issues by linking them to the order number

Connection layer

Users continuously manage their own credentials

SSH is suited to automation and command-line tasks, while VNC is suited to graphical operations. After the first connection, update the initial password, add your team’s SSH public keys, and verify exposed services.

Store private keys only on controlled devices or in a key-management system
Assign each member a separate key; do not share one key file
Expose only the listening ports required by the workload

Process layer

Incidents must be reproducible

The platform can help verify node status, connection details, and incident records. Provide the event time, node region, order number, reproduction steps, and redacted evidence so investigation can begin from a defined point in time.

Retain key excerpts from command output and application logs
State when the system last operated normally
Distinguish network, system, toolchain, and application issues

Dedicated isolation

Each order maps to a physical device; runtime instances are not shared

VMKeep provides dedicated physical Cloud Mac machines. The operating system, processes, memory space, and local disk run on the physical node assigned to the order, without sharing the same virtual instance with other tenants.

Physical dedication isolates compute resources and the runtime environment, but it does not replace repository permissions, key rotation, data encryption, or application access controls. Teams should still configure least privilege according to project sensitivity.

Device allocation VMKeep

Delivers a dedicated physical machine according to the order configuration and selected node.

In-system accounts Your team

Sets passwords, SSH public keys, member permissions, and local services.

Projects and data Your team

Manages repositories, models, build artifacts, tokens, backups, and encryption.

Incident coordination Both parties

The platform verifies the node and access point; the user provides reproducible, redacted evidence.

What isolation provides

Runtime resources are not shared with other tenants

Fixed chip and memory configurations help reproduce builds, keep runners operating continuously, and record results under consistent hardware conditions during MLX inference tests.

What isolation does not provide

Application permissions and data policies still require configuration

The user team manages repository access, business tokens, model files, signing materials, exposed ports, and backup schedules according to its own processes.

Access credential management

After the first connection, replace the temporary access with your team’s own controls

Include connection initialization in the delivery checklist for every new node. Verify passwords, SSH keys, member permissions, and listening ports before syncing code or data.

01
Update the initial password

Change the system password after the first login. Never store it in plain text in chat history, build logs, or project documentation. Manage it separately from other internal systems.
02
Add individual SSH public keys

Configure a separate public key for every member who needs command-line access. Never upload private keys to the Cloud Mac or send them through ordinary email or messaging.
03
Limit credential distribution

Use separate credentials for CI runners, deployment scripts, and manual operations. Give each token only the minimum permissions required for its task.
04
Revoke access when people leave or change teams

When a member leaves the project or changes responsibilities, revoke their SSH public key, repository tokens, and system permissions, and check whether automation still references old credentials.

Data protection

Manage code, models, signing materials, and business data separately

A Cloud Mac can run builds and inference tasks continuously, but being online does not mean data is backed up. Your team should establish clear processes for data classification, encryption, export verification, and recovery drills.

REPO

Code repositories

Use the repository’s own member permissions and deployment credentials. Restrict automation tokens to the required repositories, and never write long-lived tokens into scripts, images, or build logs.

Check: permission scope, token lifetime, log redaction

BUILD

Build artifacts

Separate regenerable caches from release artifacts that must be archived. Set traceable versions and export locations for packages, symbol files, and test reports.

Check: version, checksum, external archive

MODEL

Model files

Record the model source, quantization version, parameters, and runtime dependencies. Encrypt sensitive models and restrict the listening address and access permissions of inference services.

Check: source, version, access scope, encryption

SIGN

Signing materials

Keep certificates, private keys, and related passphrases separate from ordinary project files. Provide only the materials required during the build, then remove temporary copies when the task is complete.

Check: minimal exposure, temporary copies, revocation process

DATA

Business data

Decide whether data belongs on the node according to its sensitivity. Encrypt data that must be retained, sync it to a team-controlled backup location, and regularly verify that it can be restored.

Check: classification, encryption, backup, recovery verification

Reliability practices

Handle incidents with status checks, timelines, and reproducible evidence

All nodes operate normally 365 days a year with no scheduled downtime. The platform continuously checks node status, connection access, and incident records. When access or tasks fail, first determine the impact, then verify node and connection status, and finally use user-provided logs to identify whether the issue is at the system, toolchain, or application layer.

VMKeep does not replace concrete response procedures with unverifiable availability figures. For teams, it is more useful to record the event time, last known normal state, affected tasks, and actions already taken.

Submit a support ticket in the console View support options

Incident response runbook From symptoms to recovery

STEP 01

Confirm the impact

A single command, one project, the entire node, or the remote connection entry point.

STEP 02

Check node status

Verify the order, region, connection details, and most recent normal operating time.

STEP 03

Preserve incident evidence

Collect redacted logs, command output, error codes, and consistently reproducible steps.

STEP 04

Perform remote recovery assistance

Determine whether connection-, system-, or application-level action is needed based on node status and evidence.

STEP 05

Record results and next steps

Confirm task recovery and retain items that need rotation or correction.

Security incident report

A usable report needs six clearly defined fields

If you suspect unauthorized access, credential exposure, an anomalous process, or data risk, stop sharing sensitive information, preserve the original timeline, and submit redacted materials through a console ticket or to support@vmkeep.com.

Report fields SECURITY INCIDENT INTAKE

01

Time of incident

Include the time zone, when it was first detected, and the most recent time normal operation was confirmed.
02

Node region

Copy the region information from the order; do not substitute the network egress location.
03

Order number

Used to link the node, rental period, and support records. Do not submit payment credentials.
04

Impact

Describe the affected members, projects, services, files, or build tasks.
05

Reproduction steps

List commands, actions, expected results, and observed behavior in execution order.
06

Redacted evidence

Attach error codes and necessary log excerpts; remove passwords, private keys, full tokens, and signing materials.

Existing order

Submit a console ticket first

Tickets can be linked directly to an order and node, making them suitable for connection issues, node status, billing, and ongoing investigation.

Open the console

Security report

Send redacted information by email

Use “Security Report,” the order number, and node region in the subject line. Do not send account passwords, private keys, or full tokens.

Send to support@vmkeep.com

Delivery and secure return

Before the rental ends, leave the machine free of team assets

Do not leave migration until the final moment of the rental. First verify that data can be restored elsewhere, then revoke external access, and finally remove local copies and automation credentials from the node.

During the rental

Keep migratable assets organized

Keep code primarily in remote repositories; do not treat the node as the only copy
Sync build artifacts by version to a team archive
Record model, toolchain, and system dependency versions
Review member permissions and automation tokens regularly

Before the end

Export data and verify recovery

Export files, logs, and build results that still need to be retained
Verify at the destination that files are readable and projects can be restored
Stop runners, inference services, and scheduled tasks
Confirm that no builds or sync tasks remain pending

Final check

Revoke access and remove credentials

Revoke repository tokens, deployment tokens, and service keys
Remove SSH public keys, temporary certificates, and signing materials
Remove local model, business data, and cache copies
Confirm that the team no longer needs any files on the machine

Configure a dedicated node

Choose the configuration, node, and term first, then add the security checklist to your delivery workflow

All three Apple Silicon dedicated physical machine tiers are available by the day, week, month, or quarter. Actual availability is based on the real-time response from the console.

Rent a Cloud Mac now View the three plans Read the connection and migration guide