# Equipment security when joining a GPU pool

Access boundaries GPU owners should discuss with operators: separate environments, permissions, data, logs, updates and revocation after a pilot.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/hardware-security/
Language: en

Joining a pool requires discussion beyond performance. Owners must understand who accesses the server, which actions are allowed and how to end cooperation. Describing these boundaries clearly is more useful than a general promise that “everything is secure.”

Passwords, SSH keys and data from other projects are not needed to submit a proposal.

## Separate existing work

Before external workloads start, list machine directories, services and users. Determine which data remains inaccessible to the operator. If several teams use the equipment, one user’s approval does not represent everyone else’s interests.

Discuss a separate environment or dedicated machine. Containers can help organize the environment, but are not a universal protection guarantee. The actual isolation level depends on configuration and site requirements.

## Assign permissions and responsibility

Every access grant should have a purpose, owner, duration and revocation method. Avoid a shared account without identifiable actions. Never send secrets through public proposals or technical articles.

Before starting, agree who can change drivers, network rules and hardware settings. Changes affecting existing projects require a separate owner decision. The operator should have a procedure for urgent intervention.

## Separate customer data from telemetry

Technical monitoring needs service and equipment metrics. User request content is a different data category with separate requirements. Do not collect it automatically merely because detailed logs are available.

Define log contents, access and retention before launch. Do not promise no data retention until that is confirmed across the complete service chain and external platforms.

## Prepare an exit in advance

Disconnection should include stopping external workloads, revoking permissions and removing agreed components. Clarify which files remain with the owner and how restoration of original work is verified.

Test this procedure during the pilot. Access granted “for a couple of days” should not quietly become permanent after testing ends.

If your organization has security rules, begin with them. Then use the [server preparation plan](/journal/server-preparation/) and [pilot completion criteria](/journal/pilot-checklist/).