Single-tenant by deployment: every customer gets a fully separate set of Azure resources in their own subscription. There is no shared database, application instance, or secret store between customers — isolation is structural, not a row-level flag inside a shared system.
The main risks a security reviewer would ask about, and what actually mitigates each one today.
| Risk | Mitigation today | |
|---|---|---|
| A compromised AI Pulse instance is used to pivot into other Azure resources | The managed identity is read-only (Reader/Cost Management Reader/Key Vault Secrets User) — it cannot modify, delete, or create resources, so a compromise can leak read access but cannot make changes elsewhere in your subscription. | mitigated |
| A leaked secret exposes the database or gateway credentials | Secrets live in Key Vault, referenced (not copied) by the Container App. A secret leaked from the running container doesn't expose the Key Vault's other secrets or other customers' installs. | mitigated |
| Cross-customer data leakage | Structural isolation — separate subscription, database, and Key Vault per install. There's no shared code path that queries "all customers." | mitigated |
| Network-level access to the database or Key Vault by an unauthorised party on the internet | Both currently allow public network access (protected by credentials/firewall rules, not network isolation). Locking these behind private endpoints is a planned hardening step, not yet shipped. | partial |
| A malicious insider at SYLVA accesses customer data | No standing access path exists to exploit — the only outbound touchpoint is the entitlement check, which never carries customer data. | mitigated |
| Denial of service against the single portal instance | The portal runs as a single replica today with no automatic failover (see Operations & support guide). A sustained outage of that one instance is a real availability risk at this stage. | partial |
Mapped to the categories most security reviewers ask about first. This is a self-assessment, not a certification.
| Area | Status | Detail |
|---|---|---|
| Encryption in transit | yes | TLS enforced on every ingress (Container Apps ingress allowInsecure: false); Postgres connections require SSL. |
| Encryption at rest | yes | Azure default platform-managed encryption for Postgres, Storage, and Key Vault. |
| Least-privilege access control | yes | Three built-in read-only roles for the managed identity; see §1. |
| Audit logging | yes | Admin/change activity tracked with a configurable retention period; see the Data processing & privacy statement. |
| Network isolation (private endpoints) | roadmap | Not yet shipped — see the threat model row above. |
| Third-party security certification | not yet | No SOC 2 / ISO 27001 report exists today. State clearly to reviewers rather than implying otherwise. |
| Vulnerability & dependency scanning | yes | Container images are scanned; findings are tracked and remediated as part of the release process. |
| Responsibility | Who |
|---|---|
| Application code, secure defaults, least-privilege template | SYLVA |
| Granting install-time permissions correctly (§1 of the install guide) | You — an admin with the right Azure/Entra privilege runs the install |
| Deciding which optional connectors to enable (Defender, Sentinel, M365) | You |
| Underlying Azure platform security (physical, hypervisor) | Microsoft Azure |
| Your own subscription-level policies, network rules, and other resources | You |
To report a suspected security issue or ask a question not answered here, contact hello@sylva.sg.
SYLVA Labs Pte Ltd · AI Pulse — Security & Trust White Paper. Pre-release draft.
Companion to Azure services, data & security. Reflects the current shipping install; "roadmap" items are tracked and will be re-labelled once shipped.