Information Security Policy

Effective: June 2026 · Last Reviewed: June 2026 · Next Review: September 2026

This Information Security Policy (ISP) establishes the security standards, controls, and practices that Idle Work Inc. follows to protect customer data, platform infrastructure, and financial information processed through our platform and Plaid integration.

1. Access Control Policy Attestation 5

1.1 Principle of Least Privilege

All access to systems, data, and infrastructure follows the principle of least privilege. Users and services are granted only the minimum permissions required to perform their designated functions.

• Role-based access control (RBAC): Access is assigned based on defined roles — Administrator, Operator, and Read-Only. Each role has documented permission boundaries.
• Service account restrictions: Automated services and API integrations use dedicated service accounts with scoped permissions, never personal credentials.
• Separation of duties: Critical operations (deployment, database access, financial data handling) require distinct authorization and are not performed by a single role without oversight.

1.2 Access Provisioning and De-provisioning Attestation 2

All access provisioning and de-provisioning follows a documented process:

• Provisioning: New access is requested through a formal process, approved by the administrator, and documented in an access log. Access is granted within 24 hours of approval.
• De-provisioning: When an employee or contractor is terminated or transferred, all access is revoked within 4 hours through automated processes: Google Workspace account suspended, SSH keys revoked, Tailscale access removed, Proxmox PVE access revoked, API keys invalidated, database credentials rotated.
• Transfer process: When a user changes roles, existing access is reviewed and adjusted to match the new role's requirements within 24 hours.
• De-provisioning log: All de-provisioning actions are recorded in an access change log with timestamp, administrator, and affected systems.

1.3 Centralized Identity and Access Management Attestation 3

Idle Work uses centralized identity and access management to enforce consistent authentication and authorization:

• Google Workspace: Primary identity provider for email, document management, and calendar. Enforces MFA for all users through Google 2-Step Verification.
• Tailscale (WireGuard mesh): Centralized network access control. All infrastructure access routes through Tailscale's identity-aware mesh network with ACL policies.
• Proxmox PVE: Infrastructure management uses role-based access through Proxmox's built-in authentication, integrated with Tailscale for network-level access.
• Single sign-on: Where supported, services use Google Workspace SSO for authentication, ensuring a single identity source.

2. Periodic Access Reviews and Audits Attestation 1

Each review is documented with findings, remediation actions taken, and sign-off by the administrator. Review records are retained for 3 years.

3. Multi-Factor Authentication Attestations 8 & 9

3.1 Consumer-Facing Application Attestation 8

The Idle Work portal enforces multi-factor authentication for all users before any financial data integration is available:

• Email/password authentication with minimum 8-character passwords and bcrypt hashing (12 rounds).
• Google OAuth 2.0 with MFA — users benefit from Google's multi-factor authentication (hardware security keys, Google Prompt, SMS verification).
• Activation gating: Plaid Link is only accessible after authentication, payment verification, and manual account activation. Unauthenticated users cannot view or initiate bank connections.
• Encrypted session management with HTTP-only, Secure, SameSite=Lax cookies and rotating session tokens.

3.2 Internal Systems Attestation 9

All internal systems that store or process consumer data enforce multi-factor authentication:

• Tailscale MFA: All infrastructure access requires Tailscale authentication with identity verification.
• SSH key authentication: Direct SSH access requires Ed25519 key pairs; password authentication is disabled on all servers.
• Proxmox two-factor: Proxmox VE management console requires TOTP-based two-factor authentication.
• Google Workspace MFA: All accounts enforce 2-Step Verification with hardware security key support.
• Database access: PostgreSQL requires both Tailscale network authentication and database credentials. Direct remote access is prohibited.

4. Zero Trust Access Architecture Attestation 6

4.1 Network Segmentation

• Private network isolation: All infrastructure runs on a private network behind a Tailscale WireGuard mesh. No infrastructure is directly accessible from the public internet.
• Per-client isolation: Each client's AI employee agent runs in a separate LXC container with its own IP address, filesystem, and network namespace. Client containers cannot access each other's data.
• Database isolation: Each client's data is logically separated by tenant ID. Row-level security policies prevent cross-tenant data access.
• Service separation: Portal, Discord bot, database, and reverse proxy run in separate containers with minimal inter-container communication.

4.2 Identity Verification at Every Layer

• Traffic encryption: All network traffic encrypted via TLS (external) or WireGuard (internal). No unencrypted data traverses the network.
• API authentication: All internal API calls require X-API-Key authentication. Keys are scoped per service and rotated quarterly.
• No implicit trust: Even authenticated requests are validated against access control policies.
• Cloudflare tunnel: Public-facing traffic routes through Cloudflare Tunnel, providing DDoS protection, WAF filtering, and TLS termination.

4.3 Continuous Verification

• Session validation: Every API request validates the session token and checks authorization.
• Network ACLs: Tailscale ACLs restrict which devices and users can access which services.
• Logging and monitoring: All access events are logged and reviewed during periodic audits.

5. Vulnerability Scanning Attestation 7

Remediation Timelines

• Critical (CVSS 9.0+): Patched within 24 hours
• High (CVSS 7.0-8.9): Patched within 7 days
• Medium (CVSS 4.0-6.9): Patched within 30 days
• Low (CVSS 0.1-3.9): Patched within 90 days

6. End-of-Life Software Management Attestation 4

• No EOL operating systems, runtimes, or major dependencies are deployed in production.
• Software approaching EOL within 6 months is scheduled for migration.
• Emergency security patches for EOL-adjacent components are applied within 24 hours.
• EOL review is included in the quarterly access and infrastructure audit.

7. Data Encryption

• In transit: All external traffic encrypted via TLS 1.2+ through Cloudflare. Internal traffic encrypted via Tailscale WireGuard.
• At rest: PostgreSQL stored on encrypted ZFS pool (AES-256-GCM). Plaid access tokens encrypted with AES-256 before storage. Passwords bcrypt-hashed with 12 rounds. Backups encrypted (AES-256).

8. Incident Response

• Detection: Automated monitoring for anomalous access patterns, failed authentication attempts, and infrastructure health.
• Response time: Critical security incidents within 4 hours. All others within 24 hours.
• Notification: Affected customers notified within 72 hours of a confirmed data breach.
• Post-incident review: Every incident triggers a review within 7 days, with findings documented and corrective actions implemented.

9. Third-Party Security

10. Policy Review and Governance

• Review frequency: At least quarterly, or immediately following a security incident or significant infrastructure change.
• Approval: All policy changes approved by the administrator before publication.
• Communication: Policy updates communicated to all personnel within 7 days of approval.
• Training: All personnel with system access receive security awareness training upon onboarding and annually thereafter.
• Compliance: Verified during quarterly access reviews and infrastructure audits.