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:
- To ensure that every access path to a Sierra Digital Forge production asset or to sensitive data is authenticated, authorized, and traceable.
- To enforce the principle of least privilege across accounts, API integrations, and physical environments.
- To establish a documented lifecycle for account provisioning, modification, and deprovisioning.
- To define the cadence and scope of access reviews.
- 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
| Term | Definition |
|---|---|
| Access | The ability to view, modify, or operate a system, service, dataset, credential, or physical resource. |
| Production asset | Any system, service, credential, code repository, or environment whose compromise could affect Sierra Digital Forge customers, products, or vendor relationships. Includes the developer workstation, source repository, code-signing keys, Google Play Console, the Firebase project, subprocessor dashboards, and build-time API secrets. |
| Sensitive data | Tier 1 (Sensitive) and Tier 2 (Confidential) data as defined in Section 4 of the Sierra Digital Forge Information Security Policy. Includes Firebase session/refresh tokens, Trakt OAuth tokens, user identity, and the watchlist / viewing-state records stored in Cloud Firestore. |
| Administrative account | An account that holds elevated privileges on a production-relevant service (e.g., dashboard owner role, repository administrator, console primary admin). |
| MFA / 2FA | Multi-factor authentication. A login that requires a knowledge factor (password) plus an additional factor (TOTP, push, hardware key, or platform authenticator). |
| Subprocessor | A third-party service to which Sierra Digital Forge entrusts data or operations on behalf of end users. See Section 7 of the Information Security Policy for the current list. |
| Managing Member | The accountable executive of Sierra Digital Forge LLC. Currently Ronald Warren. |
4. Roles & Responsibilities
Sierra Digital Forge is a member-managed limited liability company. All access management roles are currently vested in the Managing Member.
| Role | Holder | Responsibility |
|---|---|---|
| Policy owner | Ronald Warren, Managing Member | Approves and maintains this Policy; signs off on access changes. |
| Account administrator | Ronald Warren, Managing Member | Provisions, modifies, and deprovisions accounts on subprocessor dashboards and Sierra Digital Forge-controlled services. |
| Access reviewer | Ronald Warren, Managing Member | Performs scheduled and event-triggered access reviews described in Section 14. |
| Incident contact | info@sierradigitalforge.com (routes to Managing Member) | Receives reports of suspected unauthorized access. |
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:
| Category | Description | Examples |
|---|---|---|
| Sierra Digital Forge administrative | Accounts on services Sierra Digital Forge directly controls or owns | Password manager, developer workstation OS account, GitHub administrator, Firebase project owner |
| Subprocessor administrative | Accounts on third-party services where Sierra Digital Forge is the customer | TMDB Developer Dashboard, Watchmode Dashboard, Trakt Application Console, Google Play Console |
| Service / build credentials | API keys, client IDs, and secrets used by application or build tooling | TMDB API key, Watchmode API key, Trakt client ID + secret, Firebase config |
5.2 Provisioning
New accounts are provisioned by the Managing Member as follows:
- 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.
- Create with minimum scope. Provision the account at the lowest privilege tier the vendor offers, and with the smallest set of products/permissions required.
- Enable MFA. Two-factor authentication is enabled on the new account before the account is used for any operation.
- 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.
- 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:
- The Managing Member evaluates whether the change is the minimum modification required.
- The change is applied via the relevant vendor dashboard.
- The change and its justification are recorded in the access register.
- 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):
- 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.
- 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.
- 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.propertieson the developer workstation.local.propertiesis listed in.gitignoreand is not synchronized to any cloud service. - The
google-services.jsonFirebase 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:
| Subprocessor | Products Sierra Digital Forge requests | Products explicitly NOT requested |
|---|---|---|
| Firebase | Authentication, Cloud Firestore | Firebase Storage, Cloud Functions, Realtime Database, Cloud Messaging (until a feature requires them) |
| TMDB | Read-only metadata (titles, images, recommendations, video keys) | Write access; user-account creation |
| Watchmode | Read-only streaming-source resolution | Bulk catalogue download; commercial-license tier |
| Trakt | OAuth history:read scope | Write scope; collection scope; comment scope |
| YouTube | Embedded IFrame player only | YouTube Data API; live-broadcast scopes; analytics |
| Google Play Console | Distribution and billing for the StreamWrangler app | Distribution of other apps not under the SDF account |
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.propertiesor 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:
- Account inventory. Confirm every administrative and subprocessor account is still required.
- Privilege review. Confirm each account is still at the minimum privilege tier required for its function.
- MFA verification. Confirm 2FA remains enabled on every in-scope account.
- Credential rotation. Rotate service / build credentials as described in Section 5.5.
- Subprocessor product scope. Confirm each subprocessor’s product scope is still the minimum required.
- Firestore Security Rules review. Confirm the rules still scope every user document correctly and that no unintended public read/write surface has been introduced.
- 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):
- The exception is documented in writing before it is implemented, including the business reason, the access being granted, the duration, and the compensating controls.
- The exception is approved by the Managing Member.
- The exception is logged with start and end timestamps.
- 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
| Channel | Detail |
|---|---|
| Mailing address | c/o Northwest Registered Agent LLC, 732 S. 6th St., Suite N, Las Vegas, NV 89101, USA |
| Executive email | ron@sierradigitalforge.com |
| Operations / security email | info@sierradigitalforge.com |
| Telephone (voice or text, mobile) | 702-469-7646 |
| Telephone (office) | 1-855-SIERRA (1-855-743-7772) |
| Website | www.sierradigitalforge.com |
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