Policy Document

Access Control Policy

How Hypernova AI manages user identities, authentication, and system access

Honest status, updated October 27, 2026. This document describes how Hypernova AI operates and the standard we hold ourselves to. Some of it isn't in place yet, and we'd rather say so: not yet in place: multi-factor login, encryption at rest for the server disk and databases, automated off-site backups, outside audits or certifications. Working toward: HIPAA, GDPR and CCPA compliance. Our server host is IONOS. The current list of every outside company that handles data is on our Security page. Where this document and that page disagree, the Security page is current.

📄 Access Control Policy

1.0
January 1, 2026
August 2026
August 2027
Cale McMillin, CEO
Active
← Security Center

1. Purpose & Scope

This policy governs how access to Hypernova AI systems, data, and infrastructure is granted, maintained, and revoked. It applies to all users, administrators, contractors, and third-party services.

2. Principle of Least Privilege

All access rights are granted based on the minimum permissions required to perform a defined function. Access is explicitly granted — nothing is inherited by default. Elevated access requires explicit approval from the CEO and is audit logged.

3. Role-Based Access Control (RBAC)

RoleAccess LevelCapabilities
founderFull AdminAll systems, all data, admin panel, infrastructure, billing, user management
adminDelegated AdminUser management, support tools, content moderation — no infrastructure access
userStandard UserOwn account data only, product features per subscription tier
serviceMachine AccountScoped API access only, no UI access, rotated keys

4. User Provisioning & Deprovisioning

Provisioning

  • New accounts created via self-registration with email verification
  • Admin accounts granted only by CEO — documented and audit logged
  • Service accounts created with minimal scope and documented purpose
  • Third-party OAuth (Google) provisioning supported — same RBAC rules apply

Deprovisioning

  • User-initiated account deletion: processed within 30 days, data erased per retention policy
  • Admin account revocation: effective within 24 hours of authorization change
  • Service account revocation: immediate upon role change or termination
  • OAuth connections revocable by user at any time via account settings

5. Password Requirements

RequirementStandardStatus
Minimum length8 charactersEnforced in code
Password hashingbcrypt (cost factor ≥12)Enforced in code
Plaintext storageProhibitedEnforced — never logged or stored
Password reuseLast 5 passwords cannot be reusedPlanned Q4 2026
ComplexityMix of character types encouragedUI guidance provided

6. Session Management

  • Session duration: Maximum 30 days — sessions expire after 30 days of inactivity
  • Cookie security: Secure, HttpOnly, and SameSite=Lax flags enforced on all session cookies
  • Session invalidation: All sessions invalidated immediately upon password change or account compromise
  • Concurrent sessions: Multiple active sessions permitted — users can view and revoke sessions from account settings
  • HTTPS only: Session tokens only transmitted over HTTPS — never over plaintext HTTP

7. Account Lockout

Lockout Policy (Enforced in Production Code)

  • Trigger: 5 consecutive failed login attempts within a 15-minute window
  • Lockout duration: 15 minutes (automatic release) or until manually unlocked
  • Scope: Per-account lockout — protects against credential stuffing
  • Notification: User notified via email when account is locked
  • Rate limiting: Additionally enforced at infrastructure layer — 10 req/15min per IP on auth endpoints

8. Privileged Access

  • Founder-level (admin) endpoints protected by separate authentication checks beyond standard session
  • All privileged actions are audit logged with: timestamp, user ID, action type, IP address, and target resource
  • Admin access not shared across individuals — each admin has a unique account
  • Production database access limited to named individuals with business need
  • Infrastructure access (SSH, server management) via key-based authentication — password authentication disabled

9. Third-Party & OAuth Access

  • Google OAuth: Supported for user authentication — grants read-only profile access (name, email)
  • Scope limitation: OAuth scopes are minimized to only what the feature requires
  • Revocation: Users can revoke OAuth connections at any time from account settings or Google Security settings
  • Token storage: OAuth tokens stored encrypted, never exposed in logs or responses
  • Third-party API access: Service accounts use rotation-eligible API keys with documented purpose and scope

10. Access Review

  • All user access rights reviewed quarterly by the CEO/Security Officer
  • Dormant accounts (no login in 6 months) flagged for review and potential deactivation
  • Admin accounts reviewed monthly
  • Service accounts reviewed on each key rotation (at least annually)

Document Control

VersionDateAuthorChanges
1.0January 1, 2026Cale McMillinInitial document
1.0.1August 2026Cale McMillinAnnual review — added OAuth section