← Back to Cashuary

1. Purpose and Scope

This Access Control Policy defines the requirements and procedures for managing access to Cashuary systems, infrastructure, and data. It governs how identities are authenticated, how permissions are assigned and reviewed, and how non-human credentials are managed across the platform.

This policy applies to all personnel, service accounts, and automated systems that interact with Cashuary infrastructure, source code repositories, cloud services, third-party provider dashboards, and production databases. It supplements the Information Security Policy (ISP-2026-001) and should be read in conjunction with it.

2. Principle of Least Privilege

Access to all systems, data, and infrastructure is granted on a need-to-know basis following the principle of least privilege. Every identity — whether human or machine — receives only the minimum permissions required to perform its designated function.

• New access requests must specify the system, the required permission level, and the business justification.
• Permissions are scoped to the narrowest role available (e.g., read-only where write access is not required).
• Temporary or elevated access (e.g., for incident response) is time-boxed and revoked immediately after the need expires.
• Access permissions are reviewed quarterly and revoked immediately upon role change or termination.

3. Infrastructure Access Controls

The following table details the access control mechanisms for each infrastructure system used by Cashuary, including the specific controls enforced and the capabilities available to authorized personnel.

System	Access Control	MFA Required	Authorized Capabilities
GitHub (Source Code)	Role-based, branch protection rules	Yes	Org owners: manage repository settings, branch protection, and team membership. Members: push to feature branches, open pull requests, review code. No direct push to main or production.
Railway (Infrastructure)	Team-based access, environment isolation	Yes	Admins: manage services, environment variables, deployments, and database access. Members: view deployment status and logs. Environment variables are scoped per environment (production, staging, PR preview).
Google Cloud Platform	IAM roles, service account key rotation	Yes	Project owners: manage IAM policies, OAuth consent screens, and service accounts. Editors: configure APIs and credentials. Service accounts: scoped to specific APIs (Calendar only) with domain-wide delegation.
Plaid Dashboard	Restricted to authorized personnel	Yes	View and manage bank integrations, webhook configurations, API keys, and sandbox settings. Access limited to the CEO.
Stripe Dashboard	Restricted to authorized personnel	Yes	View and manage Financial Connections settings, API keys, and webhook endpoints. Access limited to the CEO.
Sentry (Error Monitoring)	Team-based access	Yes	Admins: manage project settings, integrations, and alert rules. Members: view and resolve issues, manage issue assignments.
PostgreSQL Database	No direct access; managed via Railway with connection string rotation	N/A (no direct access)	No human users have direct database access. All database operations are performed through the application layer. Connection strings are managed by Railway and rotated automatically.

4. Administrative Access

The application's administrative panel is disabled by default in production and requires an explicit opt-in via environment configuration. When enabled, administrative endpoints are protected by a minimum 32-character secret token validated using timing-safe comparison to prevent timing attacks. Administrative endpoints are additionally rate-limited to 50 requests per 15-minute window.

• Administrative secrets are stored as environment variables and never committed to source code.
• Administrative endpoints are restricted to operational tasks only (e.g., diagnostics, service account verification) and do not provide access to user data.
• All administrative access is logged with request identifiers for auditability.

5. Consumer Authentication — Google OAuth 2.0

End users authenticate exclusively via Google OAuth 2.0, which provides:

• Delegated authentication — Cashuary never stores user passwords. Authentication is fully delegated to Google's identity provider.
• Inherited multi-factor authentication from users' Google accounts, providing strong authentication without Cashuary needing to implement its own MFA.
• Scoped access tokens with minimal required permissions (calendar access only). Cashuary requests only the calendar.events scope needed to create and manage transaction events.
• Token refresh handled server-side with encrypted storage. Refresh tokens are encrypted using AES-256-GCM before being persisted to the database.

6. Session Management

• Sessions are stored server-side in PostgreSQL (not client-side cookies)
• Session cookies are configured with httpOnly, secure (in production), and sameSite=lax flags
• Sessions expire after 7 days of inactivity
• Session identifiers are cryptographically random
• Session data is bound to the authenticated user and validated on every request to prevent session fixation attacks
• On logout, sessions are destroyed server-side and the session cookie is cleared from the client

7. Infrastructure Authentication & MFA

All infrastructure systems (GitHub, Railway, Google Cloud, Plaid, Stripe) require multi-factor authentication for human access. Service-to-service authentication uses API keys and secrets stored as encrypted environment variables, never committed to source code.

• GitHub: MFA enforced at the organization level. SSH keys or personal access tokens are required for Git operations.
• Railway: MFA enforced for all team members. Environment variables are encrypted at rest and scoped per deployment environment.
• Google Cloud Platform: MFA enforced via Google Workspace. Service account keys are stored securely and rotated periodically.
• Plaid & Stripe: MFA enforced on dashboard access. API keys are stored as environment variables with separate keys per environment (sandbox, production).
• Sentry: MFA enforced for all team members. Auth tokens for API access are stored as environment variables.

8. Role-Based Access Control

Cashuary uses role-based access control (RBAC) across all infrastructure platforms to enforce the principle of least privilege. The following tables detail the roles, their permissions, and current assignments.

8.1 GitHub

Role	Permissions
Organization Owner	Full repository administration, manage branch protection rules, configure GitHub Apps and integrations, manage team membership, access billing and audit logs.
Member	Clone repositories, push to feature branches, create and review pull requests. Cannot push to main or production (enforced by branch protection and pre-commit hooks).

Branch protection: The main and production branches require pull request reviews before merging. Direct pushes are blocked by both GitHub branch protection rules and local pre-commit/pre-push hooks.

8.2 Railway

Role	Permissions
Admin	Manage services, configure environment variables, trigger deployments, access database connection strings, manage team membership and billing.
Member	View deployment status, view logs, view service configuration. Cannot modify environment variables or trigger manual deployments.

Environment isolation: Production, staging, and PR preview environments have separate environment variable sets. PR preview environments inherit from the staging base environment with sandbox credentials and use isolated database instances.

8.3 Google Cloud Platform

Role	Permissions
Project Owner	Full project administration, manage IAM policies, configure OAuth consent screens, create and manage service accounts, enable/disable APIs.
Editor	Configure API settings, manage OAuth credentials, view audit logs. Cannot modify IAM policies or delete projects.
Service Account	Scoped to specific APIs only (Google Calendar). Domain-wide delegation is limited to the calendar and calendar.events scopes. No access to other GCP services or user data beyond calendar operations.

Project separation: Development/staging (cashuary-dev) and production (cashuary-prod) use entirely separate GCP projects with distinct OAuth client IDs, service accounts, and consent screen configurations.

9. Access Review and De-provisioning

Cashuary conducts quarterly access reviews to ensure that all access grants remain appropriate and that the principle of least privilege is maintained. The review process is as follows:

1. Inventory: Compile a list of all human and non-human identities with access to each infrastructure system (GitHub, Railway, GCP, Plaid, Stripe, Sentry).
2. Validation: For each identity, verify that the assigned role and permissions are still required for their current responsibilities.
3. Remediation: Downgrade or revoke access for any identity that no longer requires its current permission level. Document all changes.
4. Certification: The CEO signs off on the completed review, confirming that all access grants are appropriate.

9.1 De-provisioning

When a team member's role changes or they leave the organization, the following de-provisioning steps are executed immediately:

• Revoke GitHub organization membership and remove from all teams
• Remove from Railway project and revoke all deployment access
• Remove IAM bindings from all GCP projects
• Revoke access to Plaid, Stripe, and Sentry dashboards
• Rotate any shared secrets or API keys the individual had access to
• Document the de-provisioning actions and the date completed for audit purposes

10. OAuth Tokens for Non-Human Authentication

Cashuary uses several non-human credentials for machine-to-machine authentication with third-party services. All non-human credentials follow strict security controls:

10.1 Plaid Access Tokens

• Issued per bank connection (Item) during the Plaid Link flow. Each token grants access to a single institution for a single user.
• Encrypted using AES-256-GCM before storage in the database. Decrypted only in memory when needed for API calls.
• Scoped to transaction data retrieval only — cannot initiate transfers or modify account settings.
• Revoked when a user disconnects a bank or deletes their account.

10.2 Google Service Account

• Used for server-side calendar operations via domain-wide delegation. The service account impersonates the authenticated user to create calendar events.
• Scoped to calendar and calendar.events — no access to email, drive, or other Google services.
• Key material is stored as a base64-encoded environment variable (GOOGLE_SA_KEY_JSON), never committed to source code.
• Separate service accounts are used for development/staging and production environments.

10.3 Stripe API Keys

• Separate API keys for sandbox (test mode) and production (live mode). Sandbox keys are used in development, staging, and PR preview environments.
• Stored as environment variables (STRIPE_SECRET_KEY) scoped per Railway deployment environment.
• Used for Financial Connections session creation and account data retrieval only.
• Publishable keys (STRIPE_PUBLISHABLE_KEY) are exposed to the client for Stripe.js initialization but grant no data access on their own.

10.4 Sentry Auth Token

• Used for programmatic issue management (auto-resolving test issues). Stored as an environment variable (SENTRY_AUTH_TOKEN).
• Scoped to project-level issue management only — cannot access organization settings or billing.

10.5 General Controls for Non-Human Credentials

• All API keys and secrets are stored as environment variables, validated at startup via Zod schema validation, and never logged or committed to source code.
• Credentials are rotated when compromised or when personnel with access to them leave the organization.
• Each environment (development, staging, production) uses distinct credentials to prevent cross-environment access.

11. Centralized Identity and Access Management

11.1 Centralized Identity Provider

All infrastructure access is authenticated through Google Workspace (@cashuary.com) with organization-wide MFA enforcement. Google Workspace serves as the centralized identity provider for all personnel.

11.2 Service Access via Google Identity

All infrastructure services (GitHub, Railway, Google Cloud Platform, Sentry, Plaid Dashboard) are accessed using @cashuary.com Google Workspace identities. MFA is enforced at the IdP level via Google Workspace 2-Step Verification (set to “Enforced” for the organization).

11.3 De-provisioning

Upon employee departure, suspending or deleting their Google Workspace account immediately revokes OAuth-based access to all connected services. Railway and GCP access is tied to Google identity; GitHub access is revoked by removing the user from the organization. Service account keys are rotated independently.

11.4 Periodic Access Reviews

Access to all infrastructure systems is reviewed quarterly by the Security Officer. Reviews verify that only authorized personnel have access, that permissions follow least privilege, and that no stale accounts or excessive permissions exist. Review findings are documented and remediated within 30 days.

12. Zero Trust Access Architecture

12.1 Never Trust, Always Verify

Every API request requires a valid, authenticated session. No endpoint trusts implicit network location or prior authentication state. Session tokens are httpOnly, Secure, SameSite=lax cookies with 7-day expiry. CSRF protection via double-submit cookie pattern is enforced on all mutation routes.

12.2 Least-Privilege Data Access

All data access enforces ownership verification — users can only access their own financial data. Database queries include user ID scoping. Admin endpoints require a separate secret token and are disabled by default in production.

12.3 Network Isolation

The application database has no public endpoint and is accessible only via Railway’s private network. All external traffic is served over HTTPS with HSTS preload (max-age 1 year). Rate limiting is applied to all API, auth, webhook, and admin routes.

12.4 Continuous Monitoring

Authentication failures (missing sessions, rejected admin tokens) are logged as structured security events and forwarded to Sentry for alerting. Request-level logging captures method, URL, status code, and latency for all traffic. Unhandled errors are captured by Sentry with user context for incident response.

Revision History

Version	Date	Author	Description
1.0	March 10, 2026	Harvey Multani	Initial release — extracted from Information Security Policy (ISP-2026-001) sections 3 and 4, with expanded RBAC, access review, and non-human credential documentation.
1.1	March 11, 2026	Harvey Multani	Added Section 11: Centralized Identity and Access Management — centralized IdP, service access via Google identity, de-provisioning procedures, and periodic access review requirements.
1.2	March 11, 2026	Harvey Multani	Added Section 12: Zero Trust Access Architecture — always-verify auth model, least-privilege data access, network isolation, and continuous monitoring.