This page describes how Asemic protects customer data. It is written to be checked against how the product actually works, not taken on trust: the data model and query behavior referenced below are documented throughout these docs. Everything here is in place today. A few capabilities are configured per deployment where a team needs them, and those are called out as such.

The assistant never writes SQL

This is the most important thing about the architecture, and it removes the largest risk in AI-driven analysis.

An AI assistant connected to Asemic does not author queries. It selects from a governed catalogue: a request names metric and dimension ids, an axis (date or cohort_day), a time grain from a fixed list, a date range, filters, and a row limit. There is no free-text SQL field anywhere in the interface. Those ids are resolved against the project’s semantic layer, an id that does not exist is rejected before anything reaches the warehouse, and the SQL is produced by the query engine deterministically, the same way it is for a chart clicked in the UI.

This constrains the form of a request, not its range: the parameters are the same ones the product’s own charts submit, so anything the UI can answer, an assistant can ask. The consequences:

No SQL injection surface from the model. The model cannot express SQL, so it cannot express malicious SQL.
The query surface is bounded by the data model, not by the assistant. If a table or column is not in the semantic layer, no request can reach it.
Every query is reproducible and reviewable. The same inputs always compile to the same SQL.

Analytics queries are read-only, and the engine runs them with a short-lived, project-scoped token whose permitted actions are derived from the caller’s role. This is the same guarantee described in the AI chat documentation.

Where your data lives

Asemic does not warehouse your data. Queries execute inside your own warehouse and results are returned for display. Your event and user data is not copied, replicated, or retained. The materialized tables Asemic builds to make queries fast are created in your warehouse, under your control, and are removed with it.

What Asemic stores in its own database is configuration and metadata:

dashboard and chart definitions (which metric and dimension ids to plot, never the values);
your semantic-layer definitions (events, properties, metrics);
annotations, tags, and other content your team authors;
user, workspace, and role records.

Two exceptions are worth stating plainly:

Aggregated results pass through the service to be rendered. A chart has to reach the browser. Those results are not persisted.
Tracking-health monitoring stores per-event daily counts (a row count and a last-seen timestamp per event per day) so Asemic can alert you when tracking breaks. That is volume metadata: no user records, no property values.

Scheduled report emails contain rendered figures and go to the recipients you configure, through the email provider. That path is opt-in per dashboard.

Encryption

Warehouse credentials are encrypted at rest with Google Cloud KMS (envelope encryption) before storage. They are never returned to the browser: the connection dialog receives a redacted placeholder, and all credential handling is proxied server-side, so the OAuth client secret never reaches the client either. See Connect your warehouse.
Every connection is encrypted in transit, without exception: browser to application, application to query engine, query engine to your warehouse (BigQuery and Snowflake over their providers’ encrypted transports), and application to its own database.
The internal database connection is not merely encrypted but enforced: the instance refuses unencrypted connections outright, and the client verifies the server’s certificate chain, so the guarantee does not depend on a client remembering to ask for TLS. That database is reachable only on a private network with no public IP, and holds no warehouse data.

Access control and isolation

Tenant isolation. Every request resolves the target project against the caller’s own workspace and returns a uniform “not found” otherwise, so it is not possible to probe for the existence of another tenant’s data.
Role-based access. Four roles (Viewer, Editor, Data modeler, Admin) at workspace level, with per-project overrides. Enforcement is server-side on every endpoint: the UI reflects permissions but never grants them. The roles are described in Roles and permissions.
Credentials never reach the browser. Credential management is proxied server-side, and stored credentials are redacted from any response.

Access can also be narrowed below the project level. The same mechanism that enforces project access expresses finer grants, so a role can be restricted to a subset of metrics or dimensions, or to a slice of the underlying rows (one title, one region, one publisher’s cohort), configured for a deployment that needs it.

Row-level limits are worth a specific note. Because every query is compiled centrally from the semantic layer and no caller, human or assistant, submits SQL, a mandatory row filter is applied where the query is built and cannot be bypassed by the requester. That is a stronger guarantee than row-level security added to a system where users write their own queries.

Authentication

Google SSO is the primary path. Email and password accounts must prove the address before they can be used or inherit any access: an unverified account cannot read data through any surface, including the API.
AI assistant connections use OAuth 2.1 with PKCE and public clients (no shared secret), with an explicit consent screen listing exactly what is being granted. Programmatic access uses revocable per-user tokens.
Deprovisioning. Removing someone from a workspace immediately revokes their long-lived credentials, both API tokens and OAuth connections, not only their session.

Deployment

The standard deployment is multi-tenant, with isolation enforced in the application: every request resolves the target project against the caller’s own workspace, warehouse credentials are separate per workspace, and no query can name a data source outside your own semantic layer.

Where policy calls for infrastructure separation rather than logical separation, Asemic can run as a dedicated deployment: a separate application, its own database, its own query engine, and its own credentials, on your own subdomain, sharing no infrastructure with any other customer. It is operated through the same pipeline, monitoring, and release process as the standard product, so the isolation does not come at the cost of an environment that is maintained separately.

Auditability

Workspace administrators can see an audit trail covering membership changes, role changes, workspace settings, data exports, and any support-side access to their workspace. Support access to a customer account is recorded in that customer’s own audit trail, not only internally.

Query cost and limits

Result sizes are bounded on every query: there is a hard cap on returned data points and rows, and oversized results are truncated with an explicit signal rather than streamed without end. Because the query surface is limited to the semantic layer, assistants cannot construct arbitrary scans of raw tables. A per-query bytes-billed limit can also be set on a warehouse connection, so the warehouse itself refuses a query that would exceed it rather than running and billing it.

Platform

Google Cloud Run, with the application database on private networking and no public IP.
HTTPS only, with HSTS, a Content-Security-Policy, and Secure / HttpOnly / SameSite session cookies.
Object storage for customer media, with uploaded SVGs sanitized before storage.
Errors and anomalies monitored centrally.
Subprocessors: Google Cloud (hosting, storage, KMS) and the email provider for scheduled reports.

Certifications and assurances

Asemic is not currently ISO 27001 or SOC 2 certified. What stands in for a certificate is the architecture itself: your data stays in your warehouse, the query surface is bounded by a semantic layer you can read, and the claims on this page can be checked against how the product works in the rest of these docs rather than taken on faith. We are glad to complete a security questionnaire, walk through the architecture with your team, and scope a pilot with whatever access limits you require.