In this article
Technical remote access and permission under a grant are separate matters; document the proposed actions before seeking the applicable decision.
Remote access to grant funded GPUs should be described as a specific operating proposal: who needs access, why, which actions are permitted and when access ends. That document supports the organisation’s review; it does not establish permission by itself.
Grant conditions vary. Use the actual programme documents and responsible institutional process rather than treating another grant’s practice as a universal rule.
State the purpose in concrete terms
Describe the proposed pilot and the role of the external operator. Distinguish checking hardware, maintaining the environment and running workloads. These activities may require different permissions even when they use the same account.
The European Commission’s grant-management guidance illustrates the importance of the applicable grant agreement. It is an example of a programme framework, not a legal conclusion about equipment funded elsewhere or under another scheme.
Build an action matrix
| Proposed action | Resource involved | Review question |
|---|---|---|
| Inspect GPU configuration | Hardware information | Which identifiers can be shared? |
| Update a container | Software environment | Who approves the change? |
| Run a pilot task | GPU and storage | Is the workload permitted? |
| Transfer results | Output files | Who owns and receives them? |
| End access | Accounts and keys | How is withdrawal verified? |
Keep the matrix tied to a named purpose. Broad administrator access should not be inferred from permission to perform one limited check.
Separate research data
Identify protected datasets, credentials and existing workloads. Describe how the pilot will avoid those locations and which approved test data it uses. An equipment discussion should not begin with sending private research documents to an external team.
OpenSSH documentation can inform the technical access plan through named accounts and authorised keys. Technical restrictions support the boundary, but they do not replace the institution’s decision about permitted use.
Define expiry and preserve the decision
Record the proposed access period, responsible owner and withdrawal check. Existing sessions, background processes and stored data require their own completion steps. A key’s removal should not be presented as proof that every consequence of access has ended.
Keep the approval or refusal separately from the technical plan. If conditions change, update the proposal and retain the earlier decision. This avoids converting a narrow permission into a broader operating arrangement through informal assumptions.
An initial resource assessment can identify technical questions while the organisation determines what use is permitted under its own programme.
Continue with GPU Operator Handover: Issue and Revoke Access Keys and Allocate Electricity Costs for a Shared Research GPU.