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