Skip to content

Security and governance

What we actually do, and what we do not claimWhat we actually do, and what we do not claim

“Governed” is a word vendors use without saying what it changes. This page says what it changes, control by control, with the mechanism that enforces each one — because the useful version of a security page is one you can check.

The short answers

Everything below is the same answers with the enforcement mechanism attached.

Access and permissions

Scope is resolved before a question is interpreted, so a question cannot be planned against data the person asking could not see.

Permission-aware by construction

Access is granted per organization and then per person, per dataset. Resolving a question starts by assembling the set of datasets that person may query; everything else is invisible to the planner rather than filtered out of the result. That distinction matters — a filtered result can still leak the existence and shape of data through row counts and error messages.

How it is enforced

Row-level security in the database, plus a required per-user grant on top of the organization grant.

Definitions degrade rather than leak

A metric is only offered to a question when every table it depends on is inside that person's scope. A cross-dataset definition simply stops being available to someone without full access, instead of half-answering or revealing that the other data exists.

How it is enforced

Metric dependencies are declared in the semantic catalog and intersected with the permitted table set at scope time.

Changes take effect on the next question

Granting or withdrawing access is a change your administrators make. There is no cache to expire and no release to wait for — the next question is scoped against the new state.

How it is enforced

Scope is assembled per request, not per session.

Role separation in the product

Ordinary users, organization administrators and platform operators are distinct roles with distinct surfaces. Administrative routes are checked before the page renders, not inside it.

How it is enforced

Role checks in the request proxy, backed by row-level security on every administrative table.

What a question is allowed to do

Three independent layers stand between a generated query and your data. Any one of them failing is caught by the next.

Generated SQL is validated before execution

Every query is parsed into a syntax tree and checked: exactly one statement, read-only select trees only, every referenced table inside the permitted set, and within complexity and length bounds. Policy is reject, never repair — a query that fails goes back for regeneration rather than being patched into something that passes.

How it is enforced

A dedicated validator between generation and execution. Data-modifying constructs that Postgres permits inside a WITH clause are rejected explicitly.

Execution runs without write privileges

Validated SQL executes under a reduced-privilege database role with no write grants, restricted to the warehouse schemas, with a locked search path and a statement timeout. Privileges are dropped for exactly the one statement and restored when the transaction ends.

How it is enforced

A read-only `query_executor` role applied inside the transaction, so the guarantee holds even if the validator were wrong.

Figures are verified against the rows that came back

Before an answer is shown, every figure in the draft is checked against the actual result cells. Values that match are marked verified and anchored to the exact cell; anything that does not reconcile is flagged rather than published. Derived figures carry their formula and assumptions instead.

How it is enforced

Server-side matching against stored result sets. Verification state is never taken from the model's own output.

Nothing writes back

There is no configuration, tier or licensing arrangement in which a question becomes a change to a system of record. DeepGarden reads.

How it is enforced

The absence of write grants, at the database role.

Evidence and audit

The record is written in the same run as the number, so it is still true months later.

Every execution is recorded

Success or failure, every query execution writes a row: the SQL, the dataset, the tables touched, the row count, the duration, the status and the timestamp. Failures are recorded too, which is what makes a citation resolvable rather than a dead link.

How it is enforced

A query-run record written by the executor, not by the model.

Answers are traceable to their queries

Each factual claim in an answer is bound to the execution that produced it. The model cannot mint a reference — the pipeline rejects any citation that does not correspond to a run actually executed for that answer.

How it is enforced

Citation identifiers are validated against the run set for the answer.

Administrative actions are logged

Permission changes, dataset changes and other administrative mutations write an audit entry with the actor, the action, the target and a timestamp. A failed audit write fails the operation rather than proceeding quietly.

How it is enforced

An append-only audit log written through a privileged path.

The audit trail and the adoption record are the same artifact

Every question is logged with who asked it and when. There is no separate usage telemetry to reconcile against the audit log, because they are one record.

How it is enforced

Conversation and query history stored per user, per organization.

Data handling

Where your data is, what leaves, and what we do not do with it.

Your data is not used to train models

No customer data is used to train, fine-tune or improve any model, ours or a vendor's. Model providers are used for interpretation and generation, not as a store.

How it is enforced

Contractual and configuration-level. Ask for the specifics of the current model vendors on a call and we will name them.

Figures come from your systems, not from a model

The model writes a query; the database produces the numbers. This is a security property as much as an accuracy one — the value of a cell is never something the model asserted.

How it is enforced

Deterministic execution against your sources, verified afterwards.

Encryption in transit and at rest

All traffic is TLS. Stored data — including query results retained for evidence — is encrypted at rest by the managed database and object storage layers.

How it is enforced

Platform-level encryption. Key management is the provider's.

Sensitive columns are declared

The semantic model marks which columns carry personal or sensitive data, so handling rules and suppression thresholds can be applied consistently rather than remembered per report.

How it is enforced

A sensitivity flag per column in the semantic catalog.

Result retention is bounded and visible

Stored result previews are capped, and what is retained is exactly what the evidence panel shows you. There is no shadow copy of your data beyond the query results kept to make citations resolvable.

How it is enforced

Row caps on stored results; retention is currently a platform default.

Operational security

The unglamorous parts, stated rather than implied.

Abuse and rate controls

Question execution and public form submission are rate-limited per identity and per address, and automated-traffic protection sits in front of the question endpoint.

How it is enforced

Per-key rate limits and bot protection on the relevant routes.

Environment separation

Development, evaluation and production run against separate databases and separate credentials. Production credentials are not present in development environments.

How it is enforced

Separate projects and separate secrets per environment.

Query performance is bounded

A statement timeout and a row cap apply to every execution, so a badly shaped question degrades into a clear failure rather than into a load event on your systems.

How it is enforced

Role-level and transaction-level timeouts, plus a hard row limit.

Incident handling is a baseline obligation

Incident intake, defect handling, service restoration and security escalation apply to every customer at every commercial level. What varies by agreement is coverage hours, contractual response and restoration targets, and escalation paths — never whether we take a broken thing seriously.

How it is enforced

Stated in every agreement. See the engagement models page.

Certifications: what we hold today

DeepGarden does not currently hold SOC 2, ISO 27001 or HIPAA certification, and we do not describe ourselves as compliant with frameworks we have not been audited against. Any vendor page that implies otherwise before an audit has happened is telling you something useful about the vendor.

What we can do today is complete your security questionnaire, walk your reviewers through the controls above with the implementation in front of them, and agree contractual commitments about handling, retention and notification. For deployments involving protected health information, the arrangement — including whether a business associate agreement is required and what it would cover — is scoped explicitly during contracting rather than assumed.

Formal certification is on the roadmap and will be announced when it exists, not when it starts.

What is not built yet

Controls a serious review will ask for that we do not have yet. Listed here rather than left for you to discover in a questionnaire.

Single sign-on (SSO)

In development

SAML and OIDC against your identity provider, so account lifecycle follows your directory rather than being managed separately.

Directory sync (SCIM)

Planned

Automated provisioning and deprovisioning from your identity provider, including group-to-scope mapping.

Configurable audit retention and export

Planned

Retention periods set per customer, with a supported export path for compliance archives.

Private networking and dedicated deployment

Planned

Isolated infrastructure and private connectivity for customers whose review requires it.

Customer-specific model and security policies

Planned

Per-customer constraints on which model vendors may be used and under what terms.

SOC 2 Type II

Planned

Formal audit. Not started; will be announced on completion rather than on commencement.

In development
Being built now. We will tell you where it stands and what it does today rather than what it will do.
Planned
Committed direction, not yet started. Do not buy on the basis of this.

Reviewing us?

Send us your questionnaire, or bring your reviewers to a session and we will walk through the controls with the implementation in front of us.