Data handling and privacy

What Strata collects, where it lives, who can see it, and how long it is kept.

This page documents the data model from the security and privacy angle. For the legal framing, see Legal and policies. For the high-level security posture, see Security overview.

Data categories

Strata stores the following classes of data in its platform database (Azure SQL Database) and in Azure Blob Storage for binary artifacts:

The only data category that is org-shared (visible to other members of your org) is org-level configuration: roles, org-managed connections, agent templates, audit log, usage analytics. Conversations, messages, memory, personal connections, and chats are scoped to the user — admins can see that a user had N conversations and what they cost, but cannot read message content without going through an admin data export.

Atlassian content is not a stored category. Jira issues, comments, and service requests, and Confluence pages and page comments, are read from Atlassian Cloud on each request and are never indexed into the Knowledge Base. What Strata keeps on its own side is the token row above, the organization's Atlassian settings on the organizations row (connection mode, pinned site, the Jira project allow-list and the Confluence space allow-list, the per-product write toggles, with the service-account secret encrypted), whatever tool output the conversation itself retains under Save extension output, and an audit row for every Jira and Confluence write.

Privacy toggles

Two layers of toggles govern data saving:

Organization defaults

Configured under Organization settings → Defaults:

• Memory enabled — Strata remembers facts users share between conversations.
• Save AI conversations — persist chat history.
• Save extension output — persist SQL results, file contents, email bodies.
• Feedback collection — show thumbs-up/down on responses.
• Required AI mode — locks every chat into one mode.

Lock toggles

Organization settings → Locks — when ON, users cannot change the corresponding setting in their personal Settings page. They see a "Managed by your organization" notice next to it. Available locks: memory, save AI conversations, save extension data, rate limit, database permission (when SQL Server is enabled), extensions, agents, feedback, timezone, display name, profile picture.

Note

There is no "allowed models" lock. Model availability is governed directly by the org → role → per-user allowlists below, not by a personal toggle a lock would protect.

Per-user controls

Users can change any unlocked setting in their personal Settings page → Privacy. The exact controls:

• Save my conversations — when off, every new chat is treated as incognito; nothing is persisted.
• Save extension output — when off, SQL results, file contents, and email bodies are not stored alongside the conversation.
• Memory — when off, no memory entries are written.
• Feedback — when off, the thumbs-up/down buttons disappear.

Additionally, the incognito toggle in chat suspends all persistence for a single conversation regardless of these settings. The chat itself, messages, AI output, memory updates, and voice transcripts are not saved. Token usage is still billed and counted toward quotas — the admin Usage page sees aggregate spend but not message content.

Model access governance

Which AI models a user can prompt is governed centrally, not by a privacy toggle. Strata runs a DB-driven Model Catalog that Kronisys curates across providers (OpenAI, Anthropic, xAI, DeepSeek, Mistral AI, Cohere, and Microsoft, all served through Azure AI Foundry). Each organization enables the subset it wants. Open the in-app Model Catalog from Organization settings → Models → Open the catalog for the live list and per-model cost, capabilities, and benchmarks.

The set of models a given user can actually use is the intersection of three allowlists:

• Organization — the models the org enables from the catalog (organizations.allowed_models).
• Role — the subset granted to the user's role (org_roles.allowed_models).
• Per user — an optional override that narrows a single user below the org/role set (user_settings.allowed_models_override).

The per-user override lives in Admin → Users → (manage user) → Extensions & Data → AI models. Leaving every model checked means inherit (the user can use everything the org and role allow); unchecking a model removes it for that one user. This narrowing is enforced everywhere a chat model is selected — chat, scheduled agents, the Teams bot, and the API//v1 endpoints — so a disabled chat model cannot be reached through any of those surfaces.

Note

Voice mode is governed separately. It runs on a dedicated realtime model (not a chat model you pick), so it is gated by the org-level voice policy rather than these chat-model allowlists.

Note

These allowlists are governance controls, not per-conversation privacy toggles — the choice of model never changes what data is collected or retained, only which provider receives the inference call.

Memory data

Memory is scoped along two axes:

• Per-user memory — user_settings.memory_entries (JSON array of structured entries) and user_settings.memory_text (free-text blob). Both are wiped when an admin runs Wipe memory from the Users → user-manage modal.
• Per-connection memory — connection_memory.entries, scoped to a (user_id, connection_id) pair. Carries facts about a specific database — "tblInstance is the multi-tenant key" — that should not bleed across connections. Wiped automatically when the user or connection is deleted.

Memory is always scoped to the individual user. There is no organization-shared memory. Two users in the same org querying the same database have completely separate memory banks.

Activity log vs. message content

Strata distinguishes two log streams:

• activity_log — one row per AI request with model, mode, token counts, elapsed time, and the user query as text. Drives Usage analytics. Org-scoped so admins can see aggregate spend per user. Includes the user's prompt but NOT the AI's full response (only a 500-character preview).
• messages — one row per chat message with full role, content, model, tokens, SQL queries run, and metadata. Per-user. NOT visible to admins through the normal admin console — they can only get this via an admin data export, which is audited.

This separation matters: an admin can see that a user is heavy without being able to read their content. Reading content requires a formal export action that leaves a admin.users_exported audit trail.

Audit log retention

Configurable per organization. Default 365 days. Allowed range 30 to 3650 days. Configured under Organization settings → Defaults → Audit & data retention → Audit log retention. This control is gated by the canManageCompliance permission (Owner-reserved), so an admin who can see Org Settings but lacks that permission will not see it.

Entries older than the retention window are hard-deleted nightly by cleanupAuditLog. There is no recovery once they are swept. Set the value to match your compliance posture before any cleanup runs.

Chat retention

Two separate retention controls govern conversation lifetime:

• chat_retention_days (per org) — when a user soft-deletes a chat, it disappears from their view but stays in the DB so admin exports include it. After this many days the row is hard-deleted by purgeExpiredDeletedChats (hourly). Blank = keep forever.
• message_archive_after_days (per org, default 90) — messages older than this are moved from messages to messages_archive (columnstore-indexed, cheaper to store).
• message_cold_after_days (per org, default 730) — archived messages older than this are moved out of SQL Server entirely into Azure Blob Storage as a single JSON blob per conversation.

Cold-store retrieval is on-demand and adds latency; conversations are still readable but the platform fetches the blob on first read.

Client note: even with cold storage, a chat is still readable as long as it exists. Cold storage is a cost-optimization, not deletion.

Encryption at rest

See Security overview for the full table. Summary:

• Database connection passwords (personal and org): AES-256-GCM.
• Bring-your-own Foundry API keys: AES-256-GCM, never displayed back.
• Identity PII (user, session, and invite emails and names): AES-256-GCM field-level encryption — the database stores ciphertext, and lookups by email use an HMAC blind index instead of plaintext.
• SCIM bearer tokens: SHA-256 hash; plaintext shown once.
• Extension OAuth tokens (Microsoft Graph etc.): encrypted per row in extension_tokens.

Microsoft SSO tokens used to derive sessions are exchanged at sign-in and not persisted — only the resulting Strata session token is stored.

Data residency

Every Azure resource (App Service, SQL Database, Blob Storage, Communication Services, AI Foundry) is in a single Azure region per deployment. Region selection is part of your contract with Kronisys.

AI inference happens in the region of your organization's own Azure AI Foundry — which may be a different region than Strata's app server. The application data (conversations, settings, audit log) still lives in the platform region; only the AI calls cross to your Foundry's region.

Connecting the Jira or Confluence extension adds a region Strata does not control. Atlassian Cloud pins your data — for both products, since they share one site — to the region chosen in Atlassian when the site was created; Strata's platform database and your Azure AI Foundry are separate systems in their own regions. The three are not guaranteed to be co-located, and Strata cannot move Atlassian data out of Atlassian's region. An Atlassian question therefore crosses regions by design: the issue or page text Atlassian returns passes through Strata's application region and is sent to your Foundry deployment for inference.

Sub-processors

The third-party services Strata depends on at runtime:

The set of model providers that receive data depends on which models your organization enables from the catalog. All AI inference routes through Azure AI Foundry — your organization's own Foundry, in your own Azure tenant. Foundry is a Microsoft service; the underlying model provider's API contract applies. No prompts or completions are used to train any provider's models.

The legal sub-processor disclosure lives at the Privacy Policy.

Right to erasure (GDPR-style)

For an individual user:

• Wipe memory — admin action from the user-manage modal. Clears all memory entries.
• Delete all conversations — admin action. Hard-deletes the user's conversations and messages.
• Delete user — admin action. Removes the user row plus every cascading record.
• Personal data export — user-initiated from their own Settings → Privacy. Strata builds a ZIP of their conversations, messages, settings, and memory and emails them a 24-hour download link.

For an entire organization, see Organization deletion.

What can go wrong

See Security overview for the broader posture, Admin data export for the org-wide export, Organization deletion for full removal, and Legal and policies for binding terms.

Related

• Security overview
• Legal & compliance
• Models — the Model Catalog and how the available set is chosen
• Bring your own Azure AI Foundry