Security boundaries

Understand Cloud Mac isolation and security responsibilities.

Every order includes one dedicated Apple Silicon physical machine—not a virtual machine. Device, credential, network, and data boundaries are handled separately, helping development teams understand what the platform provides and what they must verify before renting.

View three physical node plans View usage checklist

Dedicated physical node BOUNDARY / 04

Device

Each order maps to one dedicated device, with computing resources used by the current renter.

Credentials

Users manage and rotate access credentials, limiting use according to each member’s responsibilities.

Network

Verify the target node, host fingerprint, and local network environment before connecting.

Data

Users are responsible for uploaded content, backup strategy, export planning, and cleanup before the rental ends.

Physical isolation

Verify every layer of the connection from user to dedicated device.

The console displays order, node, and connection details. Development, builds, and experiments run on the dedicated physical node assigned to the order.

STEP 01

Authorized users

Confirm who will use the device and the scope of their tasks.

STEP 02

Console

Review the order ID, region, and connection details.

STEP 03

Access channel

Verify credentials, address, fingerprint, and session status.

STEP 04

Dedicated device

Run workloads on a dedicated Apple Silicon physical machine.

Device boundary

Each valid order corresponds to one dedicated physical device. The selected chip, memory, and base storage follow the order configuration; do not apply assumed specifications from another project to the current node.

Connection boundary

The console provides node-related details, but verify the region, target address, and host fingerprint before starting a session. If the target differs from saved records, stop connecting and submit a ticket.

Content boundary

Users decide whether to write repositories, build artifacts, certificate files, training data, and logs to the node. Teams must set their own backups, access scope, retention period, and export plan before the rental ends.

Identity & access

Access control starts with an actionable member list.

Do not rely on shared spreadsheets or group chats to store long-lived access information. Credentials should map clearly to people, devices, and task scopes.

Use strong credentials

Use separate credentials for the console and remote sessions; never reuse them for code repositories, email, or other development services. Passwords should be long enough and avoid project names, member names, and sequential characters.

Check whether default access details need changing after the first connection.
Change credentials immediately if exposure is suspected—do not wait for the next routine review.
Never write passwords directly into build scripts or repository configuration.

Manage key material

Use distinct keys for different people and automation tasks. Store private keys only on approved devices or in a team-approved key management location, and keep traceable records of public-key changes.

Do not share one private key between personal sessions and the CI Runner.
Record each key’s purpose, owner, and revocation conditions.
Revoke old keys before distributing new access details.

Apply least privilege

Development, builds, log viewing, and data export do not need to use the same account by default. Grant only the permissions required for each task, then expand them when necessary; avoid retaining excessive access for convenience.

Give temporary collaborators only the access required for the current task.
Avoid using credentials from everyday interactive sessions in automation.
Document the reason for expanded access and its expected end condition.

Close idle sessions

When work ends, actively sign out of the graphical desktop and terminal connections, remove temporary credential files, and check for unnecessary background processes. Lock local devices in shared workspaces.

Do not substitute disconnecting from the network for properly ending a remote session.
After a build finishes, check background tasks and artifact directories.
End sensitive operations before leaving a public or shared network.

Revoke access when members leave or change roles

When a team member leaves, changes roles, or ends a contractor engagement, the node owner should perform a complete revocation—not merely remove the person from a project chat. Remove console authorization, revoke remote-access keys, rotate potentially shared credentials, terminate existing sessions, and check whether automation still references old access details.

Member list updated Old keys revoked Shared credentials rotated Existing sessions ended CI configuration reviewed

Remote sessions

Verify the connection target before transferring code or data.

Remote desktops, terminal sessions, and automated access work differently, but all require three basics: verify the target, protect credentials, and redact logs.

Verify identity and target

Confirm the order ID, node region, and connection address in the console. Do not connect directly from old screenshots, forwarded messages, or browser history—especially when your team manages multiple devices.

Verify the host fingerprint

Save the verified host fingerprint on first connection. If it changes later, stop the session and confirm the node details; do not delete the local known-host record just to bypass a warning.

Share redacted logs only

Remove access keys, passwords, tokens, private certificate material, internal repository addresses, and user data before submitting diagnostics. Keep only error codes, timestamps, command results, and necessary context.

End idle connections

Sign out after completing work and confirm that sensitive files are not left in temporary directories. Automation should record the execution identity and initiation source so background processes can be traced.

SESSION PRECHECK Before connecting

[01] ORDER_ID       CHECKED
[02] REGION         CHECKED
[03] TARGET_HOST    CHECKED
[04] HOST_KEY       CONFIRMED
[05] LOCAL_NETWORK  TRUSTED
[06] CREDENTIAL     NOT SHARED
[07] LOG_OUTPUT     REDACTABLE

Never transmit access credentials through public forums, public code snippets, or any shared location without access controls. For collaborative troubleshooting, submit reproduction steps and redacted logs without valid keys.

View remote access steps

Data lifecycle

Keep a checkpoint at each of the four stages, from writing data to cleanup.

Users manage project data on the node. The end of a rental is not a substitute for a backup process; complete exports and verification while the device is still accessible.

01
WRITE
Write

Before writing repositories, dependency caches, certificate files, build assets, or experiment data, confirm that the content comes from a legitimate source. Clearly identify what must enter the node and what should remain in the team’s existing storage.

User checks

Data classification, source, access scope, initial backup

Completion signal

Write directory and owner recorded
02
USE
Use

Limit access by task during development and builds; avoid copying private material into unrelated directories. Logs, caches, and temporary files may also contain project identifiers or paths and should be checked routinely.

User checks

Permission changes, temporary files, log contents, background tasks

Completion signal

Member permissions match current responsibilities
03
EXPORT
Export

Before the rental ends, export source changes, build artifacts, necessary logs, experiment results, and environment configuration notes. After exporting, open the files at the destination or verify their checksums; a transfer marked complete is not enough.

User checks

File list, transfer result, checksum verification, restore test

Completion signal

Critical materials verified usable at an external location
04
CLEAN
Clean up

After confirming the export, delete project files, temporary credentials, key copies, caches, and debug logs that are no longer needed, and exit all interactive sessions. The cleanup record should state who performed it, which directories were covered, and when it was completed.

User checks

Sensitive directories, credential copies, caches, sessions, automation tasks

Completion signal

Cleanup scope and executor documented

Complete export and cleanup before the rental ends.

If your project has audit or compliance requirements, your team should determine the number of backups, storage locations, verification method, and cleanup-record format. Do not treat an unverified transfer copy as a recoverable backup.

Regional responsibility

All five nodes are available; choose a region based on project requirements.

Available regions are Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US East. All three machine plans cover these five nodes; actual availability is returned in real time by the console.

HireAMac five-node region selection checklist
Node	Region code	Connection planning	Data and project checks	Confirm before selecting
Singapore	SG	Suitable for testing connection paths for teams in Southeast Asia.	Confirm that the project permits data and build artifacts to be processed in the selected region.	Local network path, member locations, delivery recipients
Japan (Tokyo)	JP	Suitable for validating remote-session paths for teams in Japan and nearby regions.	Review customer contracts, release workflows, and internal regional requirements.	Connection test, toolchain versions, delivery scope
South Korea (Seoul)	KR	Suitable for graphical desktop and terminal testing by members in South Korea and nearby regions.	Confirm the handling boundaries for logs, test assets, and artifacts.	Network path, personnel permissions, data category
Hong Kong	HK	Suitable for comparing real-world connection performance across offices in different locations.	Decide whether to use it based on project contracts and team policies.	Project rules, connection results, backup plan
US East	US-E	Suitable for connection testing by North America East teams or related delivery workflows.	Review customer location, project constraints, and data-processing requirements.	Member time zones, delivery region, access list

A / CONNECT

Test the actual connection first

Team members’ locations are more useful than broad geographic distance. Before choosing a region, test the connection from the actual work network and record the time, client, and network type.

B / POLICY

Then review project requirements

Customer contracts, internal policies, and project data categories may affect region selection. Availability does not automatically satisfy every project’s compliance requirements; a responsible owner familiar with the project should confirm the decision.

C / RECORD

Keep the rationale on record

Record the node, machine plan, purpose, test results, and approver. When changing regions, recheck the connection path, access list, data migration, and cleanup of the old node instead of reusing the original conclusion.

Security reporting

Security reports should include information that can be reproduced and located.

If you find an unusual connection, suspected credential exposure, inconsistent node information, or an unknown background task, stop the relevant activity and preserve redacted evidence before reporting through an official channel.

Prepare these seven items before submitting

01
Time of occurrence
Provide a time range including the time zone, and note when it was first discovered and most recently reproduced.
02
Node region
Verify the actual region in the console: Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, or US East.
03
Machine plan and order ID
Specify HireAMac M4 S, HireAMac M4 M, or HireAMac M4 Pro L, and include the order ID.
04
Impact scope
Describe which parts of the graphical desktop, terminal, automation tasks, files, or build artifacts are affected.
05
Reproduction steps
List the client, commands, expected result, and actual result in order. Avoid writing only “unable to use.”
06
Redacted evidence
You may attach error codes, fingerprint differences, process details, and necessary logs, but remove valid credentials and private project content first.
07
Actions taken
State whether you stopped the session, revoked keys, rotated credentials, paused automation, or isolated related files.

REPORT CHANNELS

Use email or a console ticket only.

TICKET

Console ticket

Best for linking the report to an existing order and node. Sign in and submit a ticket, putting the event time, order ID, node, machine plan, and reproduction steps at the beginning.

Submit a console ticket

Support email

If you cannot access the console, send it to support@hireamac.com. Include “Security feedback,” the node region, and the order ID in the subject line.

Send redacted security feedback

Attachments must not contain valid keys.

Do not submit passwords, private keys, access tokens, private certificate material, or anything that could directly log in to the node. When showing configuration structure, replace sensitive fields with invalid example values.

Dedicated Apple Silicon

Deploy your Cloud Mac workspace with clear boundaries.

Choose one of three physical machine plans, then confirm the target region among five nodes, rental period, and data export plan. All nodes run continuously 365 days a year; connection details and real-time availability are shown in the console.

Compare three rental plans Rent a Cloud Mac now