Access Controls Policy

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

⚠️ DRAFT — REQUIRES LAWYER REVIEW BEFORE PUBLICATION.

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 StreamWrangler or any future Sierra Digital Forge product.
• All third-party services and APIs that Sierra Digital Forge consumes on behalf of end users, including Firebase (Authentication, Cloud Firestore), TMDB, Watchmode, Trakt, YouTube (embedded player), 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 member-managed 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.
• Before the first public StreamWrangler build. The TMDB and Watchmode keys are subject to a known pre-rotation note (see Section 12.6 of the Information Security Policy) and are rotated before the first Internal-test and again before the first Production-track release.
• 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:

• Google Cloud Console (Firebase project owner)
• TMDB Developer Dashboard
• Watchmode Dashboard
• Trakt Application Console
• Google Play Console
• GitHub (private repository hosting StreamWrangler 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 (TMDB API key, Watchmode API key, Trakt client ID and secret) are stored in local.properties on the developer workstation. local.properties is listed in .gitignore and is not synchronized to any cloud service.
• The google-services.json Firebase configuration file is committed to the repository per Google’s published guidance — public per Google’s documentation, protected via Firestore Security Rules and not via key obscurity.
• 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 (development / production), Sierra Digital Forge maintains separate keys for each environment where possible. Development and production keys are not interchangeable in either direction.

7.4 Firestore Security Rules

The Cloud Firestore project is configured with Security Rules that scope every document under users/<uid>/... to its owning user. One signed-in user cannot read or write documents under another user’s UID. Rules are reviewed before each release and unit-tested where the schema changes.

7.5 Repository access

The source-code repository hosting StreamWrangler is configured as a private GitHub repository (rdwarren67/streamwrangler) 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 with a sole authorized operator, 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, Firestore Security Rule deployment) 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 TMDB key, changing Firestore Security Rules) are performed deliberately and recorded.
• Privileged actions are logged. Subprocessor dashboards generate audit trails on the vendor side. The Firebase project generates Cloud Audit Logs. The developer workstation generates standard Microsoft Windows audit logs.
• Code-signing keys for StreamWrangler 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 StreamWrangler.

• 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\StreamWrangler). 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 StreamWrangler 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 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’s production environment consists of:

• The Firebase project (Authentication + Cloud Firestore), administered by the Managing Member through the Google Cloud Console with 2FA.
• 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 — plus the Firestore Security Rules covered in Section 7.4.

12. End-User Data Access

Sierra Digital Forge personnel access to user data is limited to Firebase project administrators and is governed by:

• Firestore Security Rules that scope every user document to its owning UID.
• Google Cloud Console audit logging of every administrative access to Firestore.
• The principle that administrative access is performed only for legitimate operational reasons (a documented support request, a confirmed incident, a regulatory compliance request) and recorded as such.

Routine end-user activity does not surface to Sierra Digital Forge personnel. The App does not provide a support-tier mechanism, customer-service backdoor, or telemetry pipeline that allows Sierra Digital Forge personnel to view, modify, or extract a user’s stored data outside the Firebase administrative path described above.

User-initiated deletion (in-app or by email) is the path by which Sierra Digital Forge interacts with the user’s data for deletion purposes; the deletion is executed against the Firebase backend by the Managing Member or by an automated function under the Managing Member’s control.

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. Firestore Security Rules review. Confirm the rules still scope every user document correctly and that no unintended public read/write surface has been introduced.
7. Recovery information. Verify password manager recovery, BitLocker recovery key location, code-signing keystore backup, and Firebase project owner transfer plan 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 currently operates with a sole authorized operator, 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 StreamWrangler)
• TMDB API Terms of Use
• Watchmode API Terms of Service
• Trakt API Terms of Service
• Google Play Developer Distribution Agreement and Data Safety form
• Firebase Terms of Service and Data Processing and Security Terms

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 18, 2026