Healthcare teams trust Micromeet with their most sensitive data, and we earn that trust the way clinicians work: with clear accountability at every step.
Micromeet runs AI inside the systems your clinicians already use, only with your authorization, never beyond the access you grant, and never taking an action with clinical or operational impact without a person confirming it.
Your data stays yours, every AI output is reviewed by a clinician, and every step is logged and reversible.
Data ownership
Patient and institution data belong to the customer. Micromeet processes data only to deliver the contracted service, on customer instruction, and under the applicable data processing agreement.
Patient, clinician, and institutional data remain customer data. Selling data is not part of Micromeet’s business.
Micromeet does not use identifiable patient or customer data to train AI models. Product improvement uses de-identified data only where the required consent and agreements are in place.
External model providers are used under enterprise terms designed to prohibit training on customer data, with retention minimized to what is needed to return a result.
Customer data is stored in Singapore by default. For Indonesia and Hong Kong customers, Micromeet supports in-country storage; other markets follow applicable local data-protection laws and deployment requirements.
Retention is governed by customer agreements, service requirements, and legal obligations. Customer data can be deleted on request and at contract end according to the applicable agreement.
AI writes. Doctors decide. AI-assisted clinical content is governed as clinician-in-the-loop clinical decision support.
AI-generated clinical content must be reviewed and may be edited by the responsible physician before it is released, communicated, or relied on in a patient-facing workflow.
For composite workflows such as MCU reporting, responsibility can be assigned at the clinical item or report-section level, so each responsible physician remains accountable for their part of the output.
The raw AI output, physician edits, reviewer identity, timestamps, release action, operator, and version history are retained as a traceable audit trail for quality review and incident investigation.
If AI-assisted content raises a material clinical concern, escalation follows the responsible physician or designated clinical escalation pathway rather than an autonomous AI decision path.
White paper summary
Micromeet combines controlled cloud services with bounded, customer-authorized Agent Browser / AI CRMS product surfaces that run inside existing systems. The model is designed so that even a compromised or misled AI model cannot act beyond tightly defined limits.
Cloud services run on managed infrastructure with encrypted transport and storage, monitored operations, controlled releases, and backup and recovery paths.
Agent Browser / AI CRMS capabilities come from reviewed and signed skill packs, run inside isolated product surfaces, and are constrained by domain allowlists.
Task data is processed only for authorized workflows, credentials stay in operating-system managed stores, and local cache is protected with encrypted storage.
Skill boundaries, domain allowlists, and human confirmation contain what an influenced model can do.
Layer 1
Micromeet cloud services provide identity, policy, model orchestration, configuration release, logs, monitoring, storage, and operational support through controlled infrastructure.
Internet-facing services are protected with web application firewall controls, TLS, traffic filtering, and managed rules to reduce common web attack paths.
Cloud capacity planning covers compute, storage, network, and model workloads so customer growth and peak task volume can be handled predictably.
Production services use health checks, multiple service instances, recovery procedures, and backup paths to reduce service interruption risk.
Administrative access is limited to authorized personnel, scoped by role, protected by least-privilege permissions, and logged for review.
Databases, object storage, logs, and backup environments use cloud encryption capabilities, with access controlled by environment and role boundaries.
Cloud monitoring, application logs, access logs, security alerts, and failed-task signals support troubleshooting, audit review, and incident response.
Build, deploy, and publish workflows produce evidence that supports change review, rollback, and operational accountability.
Layer 2
Agent Browser and AI CRMS are bounded application layers designed to contain model mistakes, malicious webpages, and prompt-injection attempts.
Every capability comes from centrally authored, reviewed, and signed skill packs. The agent cannot self-evolve or grant itself new powers at runtime.
Agent Browser / AI CRMS can only reach approved customer systems, APIs, and model endpoints. Other navigation, requests, and data-exfiltration paths are blocked by policy.
Authorized customer systems run inside isolated client views. The agent cannot control other local applications, read other application windows, or inject commands into them.
Local cache and app data are protected with encrypted on-device storage. Copying the local data file should not make the content readable.
Customer system credentials stay in operating-system protected storage on the customer device, not in Micromeet backend services.
The agent proposes; a person confirms. Write or irreversible actions require explicit approval and are retained in the audit trail.
Agent steps, key inputs and outputs, confirmations, operators, timestamps, and version changes are recorded for troubleshooting and compliance review.
Security does not depend on the model never being influenced. Skill boundaries, domain allowlists, and human confirmation contain what an influenced model can do.
Layer 3
Micromeet employees operate under confidentiality obligations, role assignment, documented procedures, and security lifecycle controls for regulated healthcare workflows.
Employees are required to follow the employee handbook, confidentiality expectations, and security handling requirements for customer, clinical, and operational data.
Security awareness, privacy handling, and workflow-specific training support consistent behavior in regulated healthcare environments.
Operational changes, support handling, and escalation paths are performed through documented workflows with review, approval, and audit evidence.
Code changes, infrastructure configuration, and releases are reviewed through engineering workflows with automated checks and rollback paths where applicable.
Dependencies, images, cloud configuration, and public endpoints are reviewed through scanning and prioritized remediation.
Subprocessors are tracked by purpose, region, data category, security obligation, contract status where applicable, and vendor-review evidence, with customer-facing disclosure through the Trust Center or contract materials.
We disclose every third party that processes data on our behalf. Model providers operate under enterprise terms that prohibit training on customer data; cloud hosting is region-pinned per the residency policy above.
| Subprocessor | Purpose | Data processed | Region | Data terms |
|---|---|---|---|---|
| OpenAI | Model provider where used | Task content sent for processing | Singapore | Enterprise terms prohibit training on customer data. |
| Alibaba Cloud (Aliyun) | Cloud hosting | Operational and service data | Region-pinned per customer residency policy | Cloud hosting controls aligned to HIPAA security expectations. |
Illustrative list — the authoritative subprocessor register is maintained and available on request.
Request trust documents for security review, procurement, and compliance diligence.
No. The agent is bounded to centrally authored, signed skill packs. It can’t self-evolve, invent new actions, or expand its own capabilities at runtime.
Only to an explicit allowlist of approved endpoints, over TLS — and only the minimal data a given task needs. Everything outside the allowlist is blocked.
Yes. Data is encrypted in transit with TLS 1.3 where supported and at rest. On-device data is held in encrypted storage with keys protected by operating-system security controls; cloud-stored data is encrypted at rest.
No. Agent Browser runs as a sandboxed app, and AI CRMS exposes only controlled product interfaces. Other local applications cannot pull data through them.
Your system credentials stay on-device in operating-system protected storage and are never sent to Micromeet’s backend or any model provider.
We contain them rather than rely on the model never being fooled. A hijacked prompt still can’t act outside the skill pack, can’t reach a non-allowlisted domain, and can’t complete a write without your confirmation.
A human. Every write or irreversible action requires explicit user confirmation before the agent executes it.
Cloud services use TLS, encrypted storage, role-scoped access, monitoring, WAF and edge controls, environment separation, backups, and controlled release workflows.
Production data is protected through encrypted backup environments and recovery procedures. Backup frequency, retention, RPO, and RTO can be provided in customer review materials where applicable.
Customers remain responsible for device ownership, operating-system patching, disk encryption, endpoint protection, account lifecycle, and physical access control. Micromeet provides the bounded app, local encryption, signed updates, allowlists, and audit records.
Subprocessors are tracked by purpose, region, data category, access need, and security obligation. The public list is maintained in this Trust Center and can be supplemented through contract materials.
Contact us
Request trust documents, submit a security or compliance question, or report a vulnerability. Our team will route the request to the right owner.
Hong Kong
Group HQ
Singapore
Southeast Asia hub
Jakarta, Indonesia
Regional office
Shanghai
R&D centre
Found a vulnerability? Please use this support form and include enough detail for our team to triage it responsibly.