Hostnot GPU

Security Policy

Security practices for Hostnot GPU accounts, API keys, SSH access, authorization, secrets, rate limits, logs, and responsible disclosure.

Effective 8/28/2026

Hostnot GPU security is shared between the platform and each customer workload. This overview describes implemented control areas without making certification or uptime claims.

Account and credential security

Customer sessions, administrator sessions, scoped API keys, password controls, optional two-factor authentication, and account-level authorization separate access by identity and role. Keep API keys server-side, use the narrowest scopes available, and rotate credentials after suspected exposure.

SSH and workload access

Register public SSH keys through the customer workflow and keep private keys on trusted devices. Verify host fingerprints before accepting a new connection. Bind notebooks, model servers, and development tools to private interfaces where possible, then use controlled forwarding rather than exposing unauthenticated services.

Authorization and platform boundaries

Customer resources, support conversations, wallet records, and administrative operations are authorization-scoped. Provider credentials and internal routing remain behind the platform boundary. Customer-facing errors and documentation do not require upstream credentials or internal provider identifiers.

Secrets, rate limits, and audit records

Sensitive settings are handled through the platform's encrypted secret paths. API and support workflows apply validation and rate limiting, while account and administrative actions produce audit records used for operational review. Do not put secrets, private prompts, or payment credentials in logs or support messages.

Customer responsibilities

Customers are responsible for their SSH private keys, API keys, model code, containers, data, network exposure, and lawful use of workloads. Review the Developer Security guide, Privacy Policy, and Acceptable Use Policy.

Report a security issue

Use Support or the configured security contact to report a suspected vulnerability. Include a safe description, affected public route, timestamps, and reproduction details. Do not access another customer's resources, send active exploit payloads, or include credentials in a report.

Last updated 9/7/2026