Architecture and isolation
Knovara is not a shared multi-tenant service. Each customer gets a dedicated deployment inside their own cloud account, reachable only by their own Microsoft 365 tenant. This page explains what that means in practice.
Last updated September 2026
One deployment per customer
A Knovara installation is a self-contained stack — application, background worker, Teams adapter, database and the AI model connection — provisioned into an AWS account you provide (Azure on request), in the region you choose for data residency. Two customers never share a process, a database, a model endpoint, an administrative surface, or a login. Infrastructure is defined as code (Terraform on AWS, Bicep on Azure) and reviewed with you before it is applied.
Where each thing runs
| Component | Where it runs |
|---|---|
| Application, worker, Teams adapter | Your cloud account, private subnets, behind health-checked load balancing. |
| Database (sign-in data, conversation state, audit, usage) | A private managed database in your account. No public access. |
| AI model | Claude, through your cloud's model service — Amazon Bedrock in your AWS account, or Azure OpenAI. Prompts and document text are processed inside your account. |
| Documents | They never leave Microsoft 365. Knovara reads them at answer time and does not copy your library. |
| Secrets | Your cloud's secret manager, injected at runtime. Never baked into images, never logged. |
The control plane is inside your stack
Administration — scope, roles, budget, audit, support access, pause and disconnect, and upgrades — is done through an Admin Console served by your own deployment at /admin, signed in with your Entra ID. There is no central admin service that reaches into customer accounts. This is a deliberate choice: a vendor-hosted control plane holding a credential in every customer account would turn a single vendor compromise into a fleet-wide one. Keeping the control plane in-stack means the vendor's footprint in your account is minimal and auditable.
Upgrades follow the same principle. We publish a signed release catalogue (a list of releases and their exact image digests). Your deployment pulls that file, verifies its signature, and — only when your administrator approves — performs a rolling upgrade behind health checks, with automatic rollback if a release does not come up cleanly. We push nothing into your account and hold no deployment credential there. The full flow is shown below.
Identity and access
Sign-in is your Microsoft Entra ID; Knovara stores no passwords. Every read and write runs with the signed-in person's own delegated permission, re-checked at the moment of a change — Knovara can never see or touch what that person could not already. See the permissions document for the exact scopes.
Assurance, stated plainly
Knovara does not currently hold a SOC 2 report or ISO 27001 certification, and we will not imply otherwise. What we provide today is this architecture, the permission matrix, the data-handling and offboarding records, and written answers to your security questionnaire. Request them from the trust center.
Migrate, roll, verify — and roll back on its own if anything is off.
Your administrator starts it; your stack does the work and records every step. We push nothing.