Marlowe Usage Violations

Marlowe is Stanford’s NVIDIA DGX H100 SuperPOD. Two sets of rules apply to it: Stanford’s university-wide usage policy, and the operating restrictions Marlowe applies locally. This page states both and keeps them apart.

The authoritative policy

Stanford’s Computer and Network Usage Policy, Administrative Guide 6.2.1, governs all use of University information resources, including Marlowe. It is the authoritative document.

The policy prohibits behavior. Three of its provisions are the ones Marlowe users meet most often:

• Unauthorized access. Users must not seek unauthorized access to information resources or enable others to do so (§2.b), and sharing an online identity or authenticator violates policy (§2.b.1).
• Interference. Users must not encroach on, disrupt, or otherwise interfere with access to or use of University information resources (§2.e.2).
• Locally defined conditions of use. Individual units may define additional conditions of use for the resources they operate, provided those conditions are consistent with the University policy, and are responsible for publicizing and enforcing them (§2.f). The restrictions below are Marlowe’s.

Marlowe operating restrictions

These are Marlowe’s own conditions of use, under §2.f above.

Do not provide access to Marlowe outside the authenticated login path

Marlowe is reached by SSH to the login nodes with a SUNet ID, a password, and Duo two-factor authentication. Do not run anything that lets a person or a service reach Marlowe without passing that gate.

Tools that commonly produce this, as examples and not an exhaustive list:

• websocket-based tunnels, such as SSHX or Claude Remote Control/Server
• userspace VPNs, such as Tailscale or ZeroTier
• the built-in web tunnels launched from editors such as VS Code, Cursor, and Windsurf

Ordinary SSH tunnels and port forwarding are fine, because they still require your password and Duo.

Do not degrade the shared nodes

The login nodes are shared by everyone on the system. They are for editing, compiling, submitting jobs, and moving data. Short, light commands are fine; heavy or long-running work is not. If something will run for a sustained period, or take a large share of a node’s CPU or memory, it belongs on a compute node, and may be subject to termination by Marlowe staff.

Examples:

• CPU benchmarks
• storage benchmarks
• deliberately thrashing swap space
• AI inference servers such as Ollama, vLLM, or SGLang

Run that work on compute nodes through Slurm, where you are welcome to use your allocation to its limit.

If a restriction is broken

Under the University policy, a system administrator may temporarily suspend access to a resource where that is necessary to maintain its integrity (§3.b). Violations of the policy are reported to Stanford’s Information Security Office, and the University’s Chief Information Security Officer — the policy’s cognizant office — refers violations to the appropriate University unit (§5).