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 Extension output in history and each member's Keep my extension-data chats in history, and an audit row for every Jira and Confluence write.

Privacy toggles

Two layers of toggles govern data saving:

Organization defaults

Configured under Organization → Member defaults:

• Memory — Strata remembers facts users share between conversations.
• Conversation history — persist chat history.
• Extension output in history — whether a turn that used an extension (SQL, files, email, knowledge base) is written to chat history at all. This one is an org-wide ceiling: members can only narrow it for themselves.
• Response feedback — show thumbs-up/down on responses.
• AI conversation mode — let each member choose a mode, or lock every chat into one.

Padlocks

A lock is a padlock on the row of the setting it pins, not a page of its own — so an admin reads a value and the decision to freeze it together, and there is no separate screen to keep in step. When a padlock is closed, members cannot change that setting in their personal Settings page: they see a padlock badge beside it reading Managed by your organization's name.

• On Member defaults: Memory, Conversation history, Extension output in history, Response feedback, Web search, the rate limit, and the database permission (when SQL Server is enabled).
• On Profile → Member profiles, as switches rather than padlocks: Let members change their display name, Let members change their profile picture, and Let members set their own timezone.
• On Extensions, as a choice rather than a padlock: How members get an extension — Ceiling or Menu — at the head of the extension list it governs.
• On Agents, as a switch: Freeze agent changes, under Rules for everyone, effective now, above the quotas it overrides.

Web search is the one whose member end is not a greyed-out row. There is no web-search switch in personal Settings — the member's switch is in the chat composer — so this padlock is enforced when the answer is generated. The composer switch stays visible and still moves; while the padlock is closed, Strata ignores it and the organization's default decides. Close it with the default off when no part of a question may leave your tenant.

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 AI responses to history — when off, nothing is kept: once you leave or refresh, the conversation's messages are gone.
• Keep my extension-data chats in history — when off, a turn that used an extension (SQL, files, email, knowledge base) is saved blank: both your message and the reply, not only the query results or file contents. You can only make this more private than your organization's setting.
• Help us improve Strata — when off, your thumbs-up/down ratings are not recorded and nothing is sent to Kronisys. When on, after a rating you may send Kronisys your note with diagnostics of that answer (the model, timings, token counts, the tools it used); the conversation only where your organization allows it and you tick Include this conversation. See What can leave your organization.

Memory has its own section: Allow Strata to access memory under Settings → Memory — when off, no memory entries are written.

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 → Models → Manage models (View models for an admin without the "Manage AI models" permission) 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 Organization → Users → (manage user) → Access → 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 → Data and privacy → Audit log → Keep audit entries for (90 days, 1 year, 3 years, 7 years, or a custom number of days). Shortening it asks for confirmation first, with a count of the entries that would be deleted. This control is gated by the canManageCompliance permission (Owner-reserved), so an admin who can see the organization's 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

Three controls under Organization → Data and privacy → Retention govern conversation lifetime:

• Purge deleted chats after (chat_retention_days, per org, 1 to 3650 days) — 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.
• Archive messages after (message_archive_after_days, per org, 7 to 3650 days, default 90) — messages older than this are moved from messages to messages_archive (columnstore-indexed, cheaper to store).
• Move archived messages to cold storage after (message_cold_after_days, per org, 30 to 3650 days, 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.

A fourth control in the same group, Delete generated files after (artifact_retention_days, 1 to 3650 days), deletes generated PDF, Word, Excel and PowerPoint files once they reach that age, in active chats too. Blank keeps them.

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, names, and avatar URLs): AES-256-GCM field-level encryption (penc:v<n> versioned envelope) — 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.
• MCP connector auth secrets and OAuth tokens: AES-256-GCM, encrypted per row in mcp_servers; the policy hook shared secret is stored the same way and is write-only.

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.

Other optional features reach third parties in their own regions, mostly the United States: Brave Search (web search queries), Mapbox / Google Places (address and place text for maps and place cards), Stripe (billing metadata), and the IP geolocation fallback chain (a truncated sign-in IP). Any MCP connector an admin adds sends content to whatever region that connector's provider uses. None of these are co-located with your platform region or Foundry, and each is engaged only when the corresponding feature is used. See the sub-processor list for what each one receives.

Sub-processors

The third-party services Strata depends on at runtime. The authoritative, always-current list — with locations and change-notice terms — is at strata.kronisys.com/legal/subprocessors (last updated 2026-08-22); the Privacy Policy and Annex II of the DPA reproduce it.

Not every sub-processor is engaged for every organization. Several are engaged only when you use the feature that needs them (web search, maps, billing, an Atlassian or MCP connector), and some are reached through your own tenant or account rather than through Kronisys.

The set of providers that actually receive data depends on which models, extensions, and features your organization enables. All AI inference routes through Azure AI Foundry — your organization's own Foundry, in your own Azure tenant. No prompts or completions are used to train any provider's models.

Note

With a DLP policy hook configured, each prompt's text and image inventory (never raw file or image bytes) is POSTed to the endpoint or DLP vendor your organization runs before inference. That endpoint is a processor you control, not a Kronisys sub-processor.

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 everything it keeps about them (conversations, messages, settings, memory, files, agents, usage and more) and emails them a link that works only while they are signed in, for 24 hours.

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
• Data-loss-prevention policy hook
• Models — the Model Catalog and how the available set is chosen