Security, Privacy & Governance at Factal
Factal is built to sit in front of an organization's real data — the kind of data that comes with real obligations attached: student records, patient information, financial detail, anything an organization would be liable for if it leaked. That shapes every part of how the platform is built, not just a policy layered on top of it. This page describes how.
Data Isolation & Access Control
Every organization on Factal gets its own isolated workspace. Within that workspace, each connected data source — a data warehouse, a CRM, an analytics platform — can be configured as organization-scoped or user-scoped:
-
Organization-scoped connections are shared across a team, useful when a data source should be broadly available inside an org.
-
User-scoped connections are tied to one person's own identity. Queries run using that person's own credentials and permissions against the underlying source — the same access they'd have querying it directly. Factal does not sit behind a shared service account that quietly has broader access than the people using it. If someone is added to an organization in Factal, that alone grants them nothing against a user-scoped source; access to the underlying data is a separate, explicit step. Factal is never a backdoor around a data source's own permission model.
Encryption & Secrets
Credentials for connected data sources are encrypted at rest using AES-256-GCM, with a unique key and initialization vector generated per credential. Application secrets — API keys, OAuth client secrets, and the like — are managed through a dedicated secrets management service rather than stored in application code or configuration files.
AI That Never Sees Your Raw Data
Factal uses large language models to interpret natural-language questions and generate answers, and the architecture is built so that raw data never needs to reach a model in the first place:
-
When Factal plans how to answer a question, the model works from your database's schema — table and column names and types — never actual rows.
-
When Factal drafts and formats an answer, the model works from a summary of the query that ran: row counts, field names and types, and the executed SQL — never the underlying values.
-
If a formatting step needs to self-correct, it works from that same schema-level summary and a generic error description, never from the data itself.
On top of that architectural guarantee, our LLM providers are configured so that prompts submitted through Factal are not used to train their models.
Governance: Scopes and Rules, Enforced at Query Time
For organizations that need to extend access to a large number of people with different levels of visibility, Factal includes a governance layer that sits between every person and every query — enforced automatically, not just documented as policy. A query that can't be proven compliant with the active policy is blocked by default: access is denied unless it's affirmatively allowed.
Rules can be expressed at exactly the precision an organization needs:
-
Row-level access — restrict a role to only the records that belong to them (their team, their region, their cohort), defined once and applied automatically to everyone with that role.
-
Hierarchical access — scopes naturally compose up an org chart, so a manager's visibility can be defined as the union of everyone reporting to them, without hand-writing a rule per person.
-
Table-level access — restrict an entire table or dataset to specific roles, independent of any row-level filtering.
-
Column-level access — mask specific fields (names, identifiers, anything sensitive) from a role even while that role retains row-level access to the rest of a record.
Provisioning at scale. Administrators can bulk-assign access rules via CSV upload rather than configuring people one at a time, and can pre-provision access for people who haven't yet created an account — assignments made against an email address activate automatically the moment that person joins.
Audit Logging
Every sign-in, data access, and governance decision is recorded in an audit trail: who did what, when, against which resource, and whether it was allowed or denied. This gives an organization a complete record of how access was governed over time, not just a snapshot of what data exists.
Data Retention & the Right to Be Forgotten
Organizations can configure how long generated data — conversation history, cached results — is retained, with automatic enforcement rather than manual cleanup. When a data-subject deletion request comes in, Factal supports a formal erasure workflow: personal data is removed from active records, and historical audit entries referencing that person are pseudonymized rather than left identifiable indefinitely.
Built on Enterprise Cloud Infrastructure
Factal is built on Google Cloud, using the same infrastructure — data warehousing, secrets management, and identity — that enterprises already trust for their own systems. We're not asking an organization to trust a new set of infrastructure primitives; we're asking them to trust a governance layer built carefully on top of ones they likely already rely on.