Security at Mirava

Effective Date:June 12, 2026  · Version: 2.0

Mirava connects once to your stores and then works for you around the clock — keeping your regional pricing optimal across the Apple App Store, Google Play Store and Stripe. To do that on your behalf, Mirava will hold the platform credentials you choose to connect. This page sets out the security commitments that govern how those connections are protected.

The statements below describe the security model and the binding commitments in force for connected accounts. They define how Mirava will handle the credentials and data you connect — not a claim that any particular credential is already stored. You decide what to connect and when, and you can revoke access at any time.

Connect Once — You Stay in Control

Credentials you connect will be encrypted, isolated to your organization, and used only to carry out the pricing actions you authorize. Mirava acts solely as your service provider, every change is attributable to you, and you can disconnect or revoke access at any time.

1. Encryption at Rest and in Transit

The platform credentials you connect will be encrypted at rest using a managed key service (KMS-backed encryption) and will never be stored in plaintext. All data exchanged between your browser, Mirava, and the platform APIs is transmitted over encrypted connections (TLS).

For Google Play specifically, Mirava will hold no private key at all. Access uses short-lived federatedtokens, and any configuration you connect contains no secret: Mirava’s workload can act only because you authorized it to impersonate a service account you control, and you can withdraw that authorization at any time. That configuration will still be held encrypted and isolated to your organization as described above. For the Apple App Store, the API signing key you provide will be the credential held encrypted at rest.

  • Encrypted storage: connected credentials will be held in a dedicated secrets store with envelope encryption backed by a managed key service.
  • Encrypted transport: traffic to and from Mirava and the platform APIs is protected in transit with industry-standard TLS.
  • No plaintext at rest: credentials will not be written to logs, analytics, or other operational data stores.

2. Tenant Isolation

Mirava is a multi-tenant platform built so that one organization can never access another organization’s data. Every record — brands, products, and pricing — is scoped to your organization and protected by row-level authorization that is enforced on every request. The credentials you connect will be partitioned in the same way.

  • Organization-scoped access:data access is gated by your organization identity, so users only ever see and act on their own organization’s data.
  • Isolated credentials:credentials you connect will be partitioned to your organization and will only ever be used to act on that organization’s behalf.

3. Least-Privilege Access

Mirava requests only the platform scopes and roles it needs to perform the pricing tasks you enable — nothing more. When you connect a store, the scope of what Mirava can do is shown to you in plain language, and additional capabilities are activated progressively as you enable the corresponding features.

  • Minimum necessary scopes: Mirava asks for the narrowest set of platform permissions required to manage pricing on your behalf.
  • Transparent scope display: what each connection lets Mirava do is presented to you before you grant it.

4. Accountability and Audit Logging

Mirava acts solely as your service provider: every pricing change Mirava makes is authorized by, and attributable to, you. To make that accountability visible, Mirava will maintain an audit trail of the actions taken on your behalf so you can see what changed, when, and on which store — for example, “Mirava updated pricing for N products on {store} at {time}on your behalf.”

  • Attributable actions: each automated change is tied to your authorization, so there is a clear record of why it happened.
  • Reviewable history: you will be able to review the changes Mirava made on your behalf from within the product.

5. Credential Lifecycle: Rotation, Revocation and Deletion

You remain in control of every connection for its entire lifetime. Connected credentials will not outlive the relationship, and the following commitments govern how they are managed and removed.

  • Rotation: Mirava will support rotating or replacing a connected credential without losing your configuration, so you can refresh keys on your own schedule or in response to a platform requirement.
  • Instant revocation:you can disconnect a store or revoke Mirava’s access at any time. Once revoked, Mirava will stop acting on your behalf for that connection.
  • Deletion on disconnect: when you disconnect a store, the associated credentials will be deleted.
  • Deletion on account closure:when your account is closed or your subscription ends, your connected credentials will be deleted — they will not outlive the relationship.

Revoking access does not undo pricing changes that were already made on your behalf; it stops Mirava from making further changes for that connection.

6. Reporting a Security Concern

If you believe you have found a security vulnerability or have a concern about how your data or credentials are handled, please contact us so we can investigate promptly.

7. Related Policies

This security statement should be read together with the documents that govern your use of Mirava and how we handle your data:

  • Terms of Service — how Mirava acts as your service provider and how connected credentials are governed.
  • Privacy Policy — what data Mirava ingests, how it is used, and your choices over it.

Last updated: June 12, 2026 · Version 2.0