Security and data handling
Mirage can be deployed directly in your infrastructure or your cloud. In that case data and processing stay in the environment you control, the encryption keys are your responsibility, nothing is transferred outside the authorised environment, and Mirage's access is strictly limited, or removed after deployment, depending on the architecture you choose.
This page covers Mirage deployments. What this website collects about its visitors is in the privacy policy.
Where it runs
A deployment can run in the cloud, a private cloud, your own cloud account, a sovereign cloud, on premises, or in edge and offline environments. The architecture decides who holds the data, the keys and the access.
| Architecture | Data and processing | Encryption keys | Mirage's access |
|---|---|---|---|
| In your infrastructure: on premises, edge or offline | In the environment you control; nothing leaves the authorised environment | Your responsibility | Strictly limited, and can be removed after deployment |
| In your own cloud account | In the environment you control; nothing leaves the authorised environment | Your responsibility | Strictly limited, and can be removed after deployment |
| Hosted by Mirage | Set out for that deployment before you sign | Set out for that deployment before you sign | Set out for that deployment before you sign |
Controls inside a deployment
- Permissions
- Access permissions, validation workflows and audit logs remain controlled by your organization.
- Approval
- Role-based access, human approval flows and configurable autonomy for each workflow. A person on your side decides the exceptions.
- Audit
- A full audit history, with every agent action traceable to the input and the rule that produced it.
- Scope
- Each agent reaches only the systems and documents its workflow needs, through the access you grant for it, which you can revoke.
What Mirage's engineers need
- During the build, access to the systems and sample documents of the workflow being deployed, scoped to that workflow and granted by your team.
- A non-disclosure agreement signed before you share documents, on request.
- After deployment, access strictly limited to running the workflow, or removed, depending on the architecture you choose.
Documents for your security review
This page lists no certification and no audit report. For a security questionnaire, a non-disclosure agreement, or the data processing terms of a deployment, write to us: the answer covers the architecture you are considering.
- Contact
- mehdi@miragemetrics.com
- Legal entity
- Mirage Metrics Corp., 1111B S Governors Ave, STE 3123, Dover, DE 19904, USA
Questions
Can Mirage run inside our own infrastructure?
Yes. Mirage can be deployed directly in your infrastructure, on premises, at the edge or offline, or in your own cloud account. Data and processing then stay in the environment you control.
Does our data leave our environment?
Not when Mirage is deployed in your infrastructure or your cloud: nothing is transferred outside the authorised environment. For a deployment hosted by Mirage, where the data is processed is set out before you sign.
Who holds the encryption keys?
In a deployment in your infrastructure or your cloud, the keys are your responsibility.
Does Mirage keep access after the deployment?
Mirage's access is strictly limited to what running the workflow needs, and can be removed after deployment, depending on the architecture you choose.
Does Mirage hold a SOC 2 report or an ISO certification?
This page lists none. Ask us for the documentation available for the architecture you are considering, and check the entity, scope and period of any report or certificate a vendor shows you.