Trust center
Security is the architecture
Every regulated team asks the same question: can we let an AI agent read our data and do real work with it? Security is the architecture that makes the answer yes.
Custody
Your data never leaves your perimeter. DataQube deploys into your own environment - on-premise, private cloud, or air-gapped - and the AI models run on infrastructure you control. Nothing is sent back to us: no data, no usage tracking, no diagnostics.
Isolation
Sessions can't see each other. Every user session runs in its own isolated environment, created on demand and destroyed afterwards - nothing shared, nothing left behind.
Authorization
Access is explicit: who may do what, to which data. An explicit denial always overrides an allow - information barriers can't be talked around - and the rules you set in the UI are the rules the system enforces.
Evidence
Everything is on the record. Every data access, tool call, permission decision, and configuration change becomes a permanent audit event - who, what, how much, and the outcome - ready for your SIEM without custom parsing.
01Your data
How your data stays yours
Letting an agent work on regulated data is safe only if three things are true. Here is how each one holds.
Data leaving your environment
It doesn't.
There is no DataQube cloud. The software, the models, and every byte of your data run on machines you operate - a disconnected environment is a fully supported way to run it, not a degraded one.
Disconnect the internet - everything keeps working, licensing and support included.
What it can change
Only what you allow.
Your databases are read-only at the source - analysis can never alter them. Where the agent does write - drafts, files, workflows in its own workspace - every capability is a grant you control per user and per workspace, and sensitive actions stop and ask a person first.
Revoke a grant - the very next run loses that capability, and any refused attempt lands in the audit log.
Who decides what it can see
You do.
Access mirrors your organisation: sign-in through your identity provider, permissions from your existing groups, and information barriers that a denial always enforces over any allow.
Try to reach a source outside your grant - the refusal lands in the audit log with the rule that fired.
02Your answers
When it does work for you
An answer no one can explain is a risk, not a result. Everything the agent produces is built to be examined.
Every number carries its evidence
Each figure links to the queries that ran, the file passages cited, the workflow runs behind it, and the access decisions along the way - and the whole chain exports for review. Below: one finding, and the chain that produced it.
Follow the chain - it is a product surface, not a report written after the fact.
An audited sessionOffice CRE is at 92% of its internal sub-limit
Office exposure of €1.95bn is 5.5% of the loan book against a 6.0% sub-limit. Aggregate CRE remains within appetite at 11.8% vs the 12.5% limit set in the board policy. Every figure carries its query, document citation, workflow run, and audit reference.
The evidence chain behind it
Scope & permissions
- Workspace: Group Riskread-only grants on the risk warehouse, document store, and workflow - governance gate passed
Recalled knowledge
- CRE segment definitioninternal taxonomy v4 - validated, last confirmed Aug 14
- Exposure aggregation templatevalidated template, 23 prior runs
- Reporting-date conventionmonth-end drawn exposure - commitments excluded per supervisory basis
Audited tool calls
- risk-dwh · query_sqlCRE exposures, 18,204 rowsevt-4c19d2
- doc-store · read_fileCRE-limits-2026.pdf · §3.2 citedevt-4c19d6
- workflow · runcre-monthly-exposure, run #38evt-4c19d7
- kernel · concentrationshares, headroom, utilisationevt-4c19d5
Computation lineage
- Exposure aggregationCRE €4.2bn = 11.8% of €35.6bn loan book
- Limit utilisationOffice 5.5% vs 6.0% sub-limit → 92% utilisation
- Policy grounding12.5% aggregate limit cited from the board document, not assumed
Consistency checks
- GL reconciliationsegment exposures tie to the general ledger within ±0.1%
- Definition currencytaxonomy v4 is the current validated version
- Workflow parityfigures match the standing monthly run within rounding
Every figure, traced
The record includes what was refused
Every action and every refusal is recorded: who, what, how much, and the outcome - so an auditor sees the negative space too, not just the happy path. The record streams to your monitoring systems, and log lines never contain personal data, credentials, or raw results - even on error paths.
Read the logs - evidence, not exposure.
03Controls
The control set, in plain language
A summary of the technical controls your security team will ask about. Full architecture documentation and a review environment are available under NDA.
Data access
- Database connections are read-only - enforced by the database itself
- Every query is capped - result-size and runtime limits enforced at the database, not in the application
- Credentials stay inside the governed connection layer - never visible to the AI model
- File citations at section level: what was read, and which passage was used
Identity & access
- OIDC single sign-on; roles resolve from your identity provider's groups at every login
- Sign-in sessions are short-lived and expire automatically; a local emergency login exists for break-glass only
- Least privilege by default - being signed in never grants access by itself
- Deployment administration is separate from organization administration, with separate credentials
Encryption & secrets
- Encrypted in transit everywhere (TLS 1.2+), including traffic inside your cluster
- Encrypted at rest for sensitive data; customer-managed keys supported
- Secrets never appear in logs, error messages, prompts, or client responses
- Cryptographically signed license files - licensing carries no secrets and phones nowhere
Operations
- Air-gapped operation: no feature requires internet access
- Software ships through your own registry, with versions pinned and verifiable
- Structured logs that plug into your existing monitoring without custom parsers
- Every change tracked, security-relevant changes flagged, and builds reproducible
04Compliance
Your SOC 2, supported by our controls
You run the infrastructure; DataQube provides the software controls your auditors will test. Audit logging, access control, change tracking, and data minimization are built into every feature - not bolted on for the assessment.
No backdoors, by policy and by construction
No bypass auth, no hardcoded credentials, no dev mode that weakens production. The audit trail includes authorization denials, so your reviewers can verify the negative space - what was attempted and refused - not just the happy path.
Data minimization in every log line
Logs never contain PII, credentials, tokens, raw queries with data, or connection strings - including error paths. What ships to your SIEM is evidence, not exposure.
Responsible disclosure
Security reports go to security@data-qube.com. We acknowledge within one business day, and customers receive advisories with fixes - never disclosures without them.
See your data answer questions - without leaving your infrastructure
Thirty minutes with an engineer: live product, deployment options, and your security team's questions answered by someone who wrote the code.