Access Controls Policy

Organization: Sierra Digital Forge LLC Product covered: Mia Budget Buddy (Android mobile application) Effective date: May 14, 2026 Last reviewed: May 14, 2026 Document owner: Ronald Warren, Managing Member Version: 1.0 Related policy: Information Security Policy (Sierra Digital Forge LLC), v1.0

1. Purpose

This Access Controls Policy (“Policy”) defines how Sierra Digital Forge LLC (“Sierra Digital Forge”) restricts and governs access to its production assets, sensitive data, and supporting infrastructure. The Policy operationalizes the controls summarized in Section 5 of the Sierra Digital Forge Information Security Policy and adds the procedural depth Sierra Digital Forge’s partners, vendors, and regulators expect.

The objectives of this Policy are:

1. To ensure that every access path to a Sierra Digital Forge production asset or to sensitive data is authenticated, authorized, and traceable.
2. To enforce the principle of least privilege across accounts, API integrations, and physical environments.
3. To establish a documented lifecycle for account provisioning, modification, and deprovisioning.
4. To define the cadence and scope of access reviews.
5. To provide a written reference Sierra Digital Forge can produce on request to partners, vendors, and regulators.

This Policy is operationalized — every commitment described below reflects a practice Sierra Digital Forge currently performs.

2. Scope

This Policy applies to:

• All accounts that provide administrative or operational access to Sierra Digital Forge production assets, including subprocessor dashboards, source-control repositories, code-signing environments, and application distribution channels.
• The developer workstation and any other physical device used to develop, test, sign, release, or operate Mia Budget Buddy or any future Sierra Digital Forge product.
• All third-party services and APIs that Sierra Digital Forge consumes on behalf of end users, including Plaid, Google Cloud (Gemini API), ElevenLabs, Google Sign-In / Calendar / Places, and the Google Play Console.
• All access to sensitive data as classified in Section 4 of the Sierra Digital Forge Information Security Policy.

This Policy does NOT cover:

• End-user authentication on the user’s own Android device. End users authenticate locally; Sierra Digital Forge does not control the user’s device-level access.
• Subprocessor-internal personnel access. Each subprocessor maintains its own access management for its employees and infrastructure.

3. Definitions

4. Roles & Responsibilities

Sierra Digital Forge is a single-member limited liability company. All access management roles are currently vested in the Managing Member.

When Sierra Digital Forge adds personnel beyond the Managing Member, the additional roles, their access scopes, and the segregation-of-duty rules between them will be added to this Section.

5. Account Lifecycle Management

5.1 Account types

Sierra Digital Forge maintains three categories of accounts:

5.2 Provisioning

New accounts are provisioned by the Managing Member as follows:

1. Verify need. Confirm that a new account is required for a specific feature or operation, and that no existing account can satisfy the need under the principle of least privilege.
2. Create with minimum scope. Provision the account at the lowest privilege tier the vendor offers, and with the smallest set of products/permissions required.
3. Enable MFA. Two-factor authentication is enabled on the new account before the account is used for any operation.
4. Store credentials. Username and password are entered in the Sierra Digital Forge password manager. The credential entry includes the service name, account purpose, creation date, and recovery information.
5. Record. The account is added to the internal access register described in Section 14.

5.3 Modification

When an account’s role, privilege scope, or owner changes:

1. The Managing Member evaluates whether the change is the minimum modification required.
2. The change is applied via the relevant vendor dashboard.
3. The change and its justification are recorded in the access register.
4. If the modification removes privilege, it takes effect immediately. If it adds privilege, it is reviewed against this Policy before approval.

5.4 Deprovisioning

When an account is no longer needed (e.g., a subprocessor is removed, a feature is retired, or a credential is rotated):

1. The account is disabled or deleted via the vendor dashboard within 30 days of the trigger event, or sooner if the account holds production-relevant access.
2. The corresponding credential entry in the password manager is moved to an archived section and the underlying credential is rotated by the vendor or invalidated.
3. The access register is updated with the deprovisioning date and reason.

5.5 Credential rotation

Service / build credentials are rotated:

• Annually, as part of the policy review cadence described in Section 14.
• Immediately on suspected compromise. See the Incident Response procedure in Section 8 of the Information Security Policy.
• Promptly when a credential’s scope is reduced (e.g., removing a product from a subprocessor account).

6. Authentication

6.1 Multi-factor authentication

Two-factor authentication is required on every account that meets any of the following criteria:

• Provides administrative access to a Sierra Digital Forge production asset.
• Provides access to a subprocessor dashboard that holds or controls Sierra Digital Forge customer integrations.
• Provides access to source code, code-signing keys, or build artifacts.
• Provides access to the password manager.

Accounts that currently enforce 2FA include, without limitation:

• Plaid Developer Dashboard
• Google Cloud Console (Gemini API project)
• ElevenLabs administrative dashboard
• Google Play Console
• GitHub (private repository hosting Mia Budget Buddy source)
• Personal password manager
• Developer workstation OS account (sign-in protected by strong password; biometric or PIN unlock layered on top where supported by Windows Hello)

No production-relevant account is exempt from 2FA. No shared administrative accounts are used.

6.2 Password requirements

Passwords used on Sierra Digital Forge administrative and subprocessor accounts meet the following minimum standards:

• 16 characters or longer.
• Mix of uppercase, lowercase, numbers, and symbols, unless the service does not accept symbols.
• Generated by the password manager’s random-password generator. Memorable passwords are not used for production-relevant accounts.
• Unique per service. Password reuse across services is prohibited.
• The password manager’s master password is at least 20 characters, randomly generated, memorized by the Managing Member, and never stored in plaintext anywhere outside the Managing Member’s memory.

6.3 Credential storage

• Administrative and subprocessor account passwords are stored exclusively in the password manager, encrypted at rest with a master-key-derived AES-256 key.
• Service / build credentials required at compile time (Plaid client ID and secrets, Gemini API key, ElevenLabs API key) are stored in local.properties on the developer workstation. local.properties is listed in .gitignore and is not synchronized to any cloud service.
• Production credentials are never embedded in source code committed to version control. Source code reviews confirm that secret literals do not leak into the repository.
• Production credentials are never transmitted by email, chat, or any unencrypted channel.

6.4 Session management

• Subprocessor dashboards use the vendor’s default session-expiration settings (typically several hours of inactivity). Sierra Digital Forge does not extend session lifetimes beyond the vendor default.
• The developer workstation locks automatically after a short idle period and on lid close.

7. Authorization & Least Privilege

7.1 Principle

Every account, API key, and integration operates at the minimum privilege required to perform its intended function. Sierra Digital Forge does not grant broader privilege “in case it’s needed later” — additional privilege is granted only when a specific feature requires it.

7.2 Subprocessor product scoping

When integrating with a subprocessor that offers multiple products, Sierra Digital Forge requests only the products that an existing or imminent feature requires. Current scopes:

7.3 API key scoping

Where a subprocessor supports differentiated keys by environment (sandbox / development / production), Sierra Digital Forge maintains separate keys for each environment. The sandbox key is used for development and testing; the production key is used only for builds intended for end-user distribution. Sandbox and production keys are not interchangeable in either direction.

7.4 Repository access

The source-code repository hosting Mia Budget Buddy is configured as a private GitHub repository owned by the Managing Member. Read and write access are limited to the Managing Member. No collaborators, integrations, or third-party apps are granted access without an explicit business justification and an entry in the access register.

8. Privileged Access Management

Because Sierra Digital Forge currently operates as a single-member LLC, all privileged access resides with the Managing Member. The following controls apply:

• No separation of duty between owner and operator. This limitation is documented and reviewed. When Sierra Digital Forge adds a second authorized operator, the privileged-action workflows (key rotation, account deprovisioning, release signing) will be restructured to require a second approver where feasible.
• No standing privilege beyond what is operationally required. Subprocessor dashboards default to read-only views; elevated actions (e.g., rotating a Plaid secret) are performed deliberately and recorded.
• Privileged actions are logged. Subprocessor dashboards generate audit trails on the vendor side. The developer workstation generates standard Microsoft Windows audit logs.
• Code-signing keys for Mia Budget Buddy are held in the developer workstation’s local keystore, protected by a strong key password stored in the password manager. The keystore file itself is backed up offline. No cloud-hosted code-signing service is used.

9. Physical Access Controls

9.1 Developer workstation

The primary developer workstation is the sole environment that compiles, signs, and releases Mia Budget Buddy.

• Location. A private office located within Nevada, USA. The office is inside a private residence and is not accessible to the general public. The specific street address is withheld from this published policy for security reasons; service of process and partner correspondence should be directed to the registered-agent address in the Distribution & Contact section.
• Operating system. Microsoft Windows with the latest stable security patches applied.
• Full-disk encryption. BitLocker is enabled on the system drive and on the working data drive (D:\Projects\mia_budget_buddy). The BitLocker recovery key is stored in the password manager and offline in a separate secure location.
• Account password. The Windows account requires a strong password to sign in. Windows Hello (PIN or biometric) is enabled as the day-to-day unlock factor; the strong password is required after reboot or after a long idle period.
• Idle lock. The workstation locks automatically after a short idle period and on lid close.
• No cloud synchronization of project secrets. The project working directory is excluded from OneDrive synchronization to prevent inadvertent replication of local.properties or other secret-bearing files to cloud storage.

9.2 Mobile test devices

Mobile test devices used to validate the Mia Budget Buddy application are configured with:

• Device-level encryption (Android default on modern devices).
• A PIN, password, or biometric unlock.
• Auto-lock on idle.

Mobile test devices do not store production user data. They store sandbox test data only, which is wiped when the test cycle completes.

9.3 Physical premises

The home office is locked when unattended. There is no shared-office or co-working environment in which Sierra Digital Forge production assets are stored.

10. Remote Access

Sierra Digital Forge does not currently operate a remote-access infrastructure (VPN, jump host, bastion server). The Managing Member accesses subprocessor dashboards directly from the developer workstation over HTTPS, authenticated with 2FA. There is no remote-administration channel into the developer workstation itself; the workstation does not accept inbound remote sessions.

If Sierra Digital Forge introduces remote-access infrastructure in the future (e.g., for a contractor or remote co-developer), this Section will be revised to include the corresponding controls — at minimum, MFA-protected VPN with strong client-side authentication, idle-session timeouts, and access logging.

11. Production Environment Access

Sierra Digital Forge does not operate a production server, database, virtual machine, or container service. All Mia Budget Buddy user data resides on the end user’s device.

The Sierra Digital Forge-controlled environment is limited to:

• Subprocessor dashboards (accessed by the Managing Member with 2FA).
• The Google Play Console (used to publish application releases).
• The source-code repository (used to develop and version the application).
• The developer workstation (used to build, sign, and submit releases).

Production-environment access controls therefore reduce to dashboard, console, repository, and workstation controls — each of which is covered in the preceding Sections.

12. End-User Data Access

Sierra Digital Forge personnel have no access path to user data at rest. This is a structural property of the Mia Budget Buddy architecture:

• All user financial data, Plaid access tokens, voice transcripts, and user identity are stored exclusively on the end user’s device.
• User data is encrypted at rest on the device via EncryptedSharedPreferences (AES-256 via the Android Keystore) for sensitive items, and protected by the Android user-data sandbox for non-sensitive items.
• The application has no remote-administration capability. There is no support-tier mechanism, customer-service backdoor, or telemetry pipeline that permits Sierra Digital Forge to view, modify, or extract a user’s stored data.
• User-initiated deletion is the only path by which Sierra Digital Forge interacts with user data — and that path runs entirely on the user’s device, with no Sierra Digital Forge-controlled component involved.

This control is the strongest access restriction in this Policy: Sierra Digital Forge personnel cannot access user data because the architecture does not provide a way to.

13. Third-Party / Subprocessor Access

The current Sierra Digital Forge subprocessor list and the data each subprocessor receives are documented in Section 7 of the Information Security Policy. The access-management commitments specific to subprocessors are:

• Onboarding. Each subprocessor is evaluated for its security posture and contractual data-protection commitments before integration. See Section 7.1 of the Information Security Policy.
• Account management. Each subprocessor account is held by the Managing Member, protected by 2FA, and scoped to the minimum products required.
• Monitoring. Subprocessor security advisories and status notifications are routed to info@sierradigitalforge.com and acted on per the Incident Response procedure in Section 8 of the Information Security Policy.
• Offboarding. When a subprocessor is removed, the relevant API keys are revoked, the corresponding code path is removed or feature-flagged off in the next release, and any locally cached tokens for the removed subprocessor are deleted from user devices in the same release.

14. Access Reviews

14.1 Scheduled reviews

The Managing Member performs an access review at least once per calendar year. The review covers:

1. Account inventory. Confirm every administrative and subprocessor account is still required.
2. Privilege review. Confirm each account is still at the minimum privilege tier required for its function.
3. MFA verification. Confirm 2FA remains enabled on every in-scope account.
4. Credential rotation. Rotate service / build credentials as described in Section 5.5.
5. Subprocessor product scope. Confirm each subprocessor’s product scope is still the minimum required.
6. Recovery information. Verify password manager recovery, BitLocker recovery key location, and code-signing keystore backup are current and accessible.

The review is documented with a date, summary findings, and remediation actions. Reviews are retained as part of the Sierra Digital Forge security record.

14.2 Triggered reviews

An access review is also performed promptly upon:

• A personnel change (joiner, mover, leaver).
• A vendor change (new subprocessor, removed subprocessor, changed scope at an existing subprocessor).
• A confirmed security incident affecting any in-scope account.
• A suspected credential compromise.
• A material architectural change that introduces new access paths.

14.3 Access register

Sierra Digital Forge maintains a simple access register listing each in-scope account with: service name, account purpose, owner, 2FA status, creation date, last-reviewed date. The register is kept current as accounts are provisioned, modified, or deprovisioned.

15. Exception Process

If an operational situation appears to require a deviation from this Policy (for example, temporarily granting elevated access to perform a specific repair):

1. The exception is documented in writing before it is implemented, including the business reason, the access being granted, the duration, and the compensating controls.
2. The exception is approved by the Managing Member.
3. The exception is logged with start and end timestamps.
4. The exception is reviewed and closed promptly when the underlying need ends. Standing exceptions are not used in place of a Policy revision.

No exception has been issued since the effective date of this Policy.

16. Enforcement & Sanctions

Violations of this Policy by Sierra Digital Forge personnel may result in immediate revocation of relevant access, mandatory corrective action, and (for material violations) termination of the personnel relationship. Because Sierra Digital Forge is currently a single-member LLC, enforcement against the Managing Member would be expressed as a self-imposed corrective action recorded in the Sierra Digital Forge security record, with the policy updated to prevent recurrence.

When Sierra Digital Forge adds additional personnel, contractor or employee agreements will reference this Policy and require acknowledgment as a condition of access provisioning.

17. Related Documents

• Sierra Digital Forge Information Security Policy (v1.0)
• Sierra Digital Forge Privacy Policy (published at the URL specified in the Google Play Console listing for Mia Budget Buddy)
• Plaid Developer Agreement and Acceptable Use Policy
• Google Play Developer Distribution Agreement and Data Safety form
• Subprocessor Terms of Service for Plaid, Google Cloud, ElevenLabs, and Google Sign-In / Calendar / Places

18. Distribution & Contact

This Policy is made available to partners, vendors, and regulators on request.

Sierra Digital Forge LLC — primary contacts

19. Acknowledgment

I, Ronald Warren, in my capacity as Managing Member of Sierra Digital Forge LLC, attest that the access controls described in this Policy are operational as of the Effective Date, and commit to maintain, review, and update this Policy in accordance with the cadences specified herein.

Ronald Warren Managing Member, Sierra Digital Forge LLC Date: May 14, 2026