Access Control Policy

Effective March 5, 2026 · Approved by Sean Appleby, CEO

1. Purpose

This policy defines how seanCo manages access to information systems, infrastructure, and user data within the attune platform. It ensures that access is granted on a least-privilege basis, monitored continuously, and revoked promptly when no longer needed.

2. Scope

This policy applies to all access to:

• Production infrastructure (GCP, GKE, Cloud SQL, container registries)
• Source code repositories (GitHub)
• Third-party services (Plaid, Anthropic, PowerSync, monitoring tools)
• Databases (PostgreSQL, MongoDB, Redis)
• CI/CD pipelines and deployment systems
• Internal tools and administrative interfaces

3. Principles

• Least privilege: Every account, service, and system receives only the minimum permissions required to perform its function.
• Need to know: Access to data is restricted to those who require it for a legitimate business purpose.
• Defense in depth: Multiple layers of access control ensure that no single failure compromises security.
• Separation of duties: No single individual can unilaterally deploy to production, modify access controls, and approve their own changes.

4. Roles & Permissions

Role	Access Level	Granted To
Infrastructure Admin	Full GCP, GKE, Terraform, database admin	CEO / Lead Engineer
Developer	Source code, staging environments, CI/CD, read-only production logs	Engineering team
Read-Only DB	SELECT on production database via restricted user	Debugging (time-limited)
CI/CD Service	Container registry push, Kubernetes deploy, secret access	GitHub Actions service accounts
Application Service	Database read/write (own schema), third-party API tokens	API and worker pods
End User	Own data only, via authenticated API and PowerSync sync rules	App users

5. Authentication Requirements

5.1 Personnel Access

• Multi-factor authentication (MFA) is required for all access to GCP, GitHub, and third-party service dashboards.
• SSH keys are used for server access where applicable; password-only authentication is prohibited.
• Personal access tokens must have expiration dates and minimal scopes.

5.2 User Authentication

• End users authenticate via a managed auth provider with support for email/password and social sign-in.
• Session tokens are short-lived and refreshed automatically.
• Revoked sessions are propagated to PowerSync to immediately stop data sync.

5.3 Service-to-Service

• Backend services authenticate to databases and third-party APIs using scoped service account credentials managed via GCP Secret Manager or Kubernetes secrets.
• API keys and tokens are never stored in source code; CI guardrails prevent accidental commits of secrets.

6. Access Provisioning & Revocation

6.1 Granting Access

1. Access requests are documented (GitHub issue or written request).
2. Access is approved by the Infrastructure Admin.
3. Permissions are configured at the most restrictive level that enables the work.
4. Temporary access (e.g., debugging) is granted with an explicit expiration.

6.2 Revoking Access

• Access is revoked within 24 hours of role change or departure.
• Shared credentials (if any) are rotated immediately upon any personnel change.
• Third-party integration tokens (Plaid, calendar) are revoked when a user disconnects an integration or deletes their account.

6.3 Access Reviews

All human and service account access is reviewed quarterly to verify that permissions remain appropriate. Unused access is revoked.

7. User Data Isolation

Attune's architecture enforces strict per-user data boundaries:

• API layer: All endpoints filter data by the authenticated user's ID. There are no admin endpoints that expose other users' personal data.
• PowerSync sync rules: Sync rules are configured so that each user's device only receives their own data. The sync layer enforces this independently of application code.
• Database: Application queries always include a user_id filter. The read-only database user has SELECT-only permissions and cannot modify data.
• AI processing: AI tools receive only the requesting user's data context. User data is never mixed across requests.

8. Secrets Management

• Production secrets are stored in GCP Secret Manager or Kubernetes secrets, never in environment files, source code, or CI logs.
• App store signing keys are rotated on schedule with CI guardrails preventing use of expired keys.
• Database passwords are unique per environment (production, staging, local dev) and rotated periodically.
• Third-party API keys (Plaid, Anthropic) use the most restrictive scope available.

9. Monitoring & Audit

• GCP audit logs record all infrastructure access and configuration changes.
• GitHub audit logs track repository access, permission changes, and CI/CD activity.
• Application logs record authentication events and API access patterns.
• Anomalous access patterns (unusual login locations, bulk data access) trigger alerts.

10. Policy Review

This policy is reviewed at least annually by the CEO, or immediately following a security incident, personnel change, or significant infrastructure change. Updates are versioned and communicated to all personnel.

11. Contact

Questions about access controls or requests for access changes can be directed to you@snappleby.xyz.