Security

We never hold your keys. Or your data.

Datris is fully self-hosted. Datris.ai the company never receives, stores, or processes your data, there is no managed service, and there are no subprocessors. The rest of this page answers a security questionnaire in the order the questionnaire asks.

Request the security packet Read the source

Deployment model

Datris runs inside your perimeter: on-prem, in your cloud account, or on a laptop. Customer data stays on infrastructure you operate, plus the AI provider, destinations, and agents you choose to connect; the data-flow matrix lists where each kind of data can go and the setting that changes it. Datris.ai the company has no access path to a deployment, no support tunnel, and no hosted control plane. Most SOC 2 controls about data handling do not apply because no customer data reaches us.

Credentials

  • HashiCorp Vault brokers every credential. Source and destination secrets are stored in Vault and delivered to the tap at run time. They are never written into agent configs, prompts, or chat history.
  • Datris never hands a key to an agent. An agent asks Datris to use a secret by name; the platform never returns a secret value to an agent.
  • Scoped API keys. Each agent gets its own API key with an explicit capability bundle, and the MCP tool catalog it sees is filtered to match.
  • Single sign-on. People can sign in to the UI through your identity provider over OpenID Connect (authorization code flow with PKCE). MFA and password rules are whatever your provider enforces. Someone without a Datris user is refused unless you set a default role, and the built-in admin account can never be reached through SSO. The client secret lives in Vault. If the provider is down, password login keeps working. See single sign-on.

Isolation

  • Tap scripts, including agent-generated ones, run in a sidecar container with no platform credentials inside.
  • Private egress from the sidecar is blocked by default.
  • The Python scripts behind AI data-quality rules and AI transformations are written once when a pipeline is saved, stored, and readable before they run. They execute in their own container with no platform secrets, no view of the server’s files, no route to the databases or Vault, no internet, and no access to the Datris API. Runs make no model call.
  • Secrets are masked in logs.
  • A schedule can only run a tap script that has passed a server-side test. Editing the script, by hand or by an agent, never repoints the schedule at untested code.
Agent MCP server Agent Policy Vault Tap sidecar Destination

Every request follows this path. Policy is evaluated before Vault is consulted, and the sidecar receives only the credential the run needs.

Governance

User login, API keys, Agent Policy, and the audit log are switched on per install, with one step described in the quick start. Field protection is set per column in a pipeline.

  • Agent Policy. Per-action allow, approve, or refuse, enforced by the platform, not by a prompt.
  • Audit log. With the audit log on, every create, change, run, delete, login, and denied request, attributed to a login or API key. CSV export and SIEM mirroring.
  • Provenance. With provenance stamping on, every landed row is traceable to the pipeline, run, script commit, and source.
  • Strict mode. Both are best effort by default. Strict mode refuses a request rather than lose its audit entry, and fails a stamping run rather than load unstamped rows; XML sources are not stamped.
  • Lineage. Where data came from and where it went, per pipeline.
  • Field protection. A column marked for protection is pseudonymized, masked, redacted, dropped, or encrypted on your server before AI rules, AI transformations, previews, and destinations see it, so its raw value is never sent to a model provider. A HIPAA Safe Harbor preset classifies columns by name, with no model call. Encrypted values can be revealed only with a permission no built-in role includes, and every reveal is in the audit log. See field protection.
  • No row values to a model. One setting makes the helpers that write schemas, profiles, and scripts work from column names and types instead of sample rows. The data-flow matrix lists what it covers and what it does not.

Air-gapped operation

Datris runs with no external dependency. Local models via Ollama and bundled bge-m3 embeddings cover code generation, the AI helpers, and embeddings without a cloud provider; the chat assistants need a supported cloud provider today, so an air-gapped install runs without them. The two optional outbound requests Datris can make (the model-catalog refresh and the datris doctor update check, both described below) fail silently: the first to a built-in list, the second to a skip row. See the deployment page for the profile.

No usage telemetry

The platform sends no usage data: no beacon, no crash reporter, no license check. There is no install id or other identifier. You can verify it: clone the repo and run two greps. The first looks for any analytics, error-reporting or beacon library or vendor in the code, and prints nothing. 

git clone https://github.com/datris/datris-platform-oss.git && cd datris-platform-oss

# No analytics, error-reporting or beacon library or vendor anywhere in the code.
# Prints nothing.
grep -rniE "telemetry|posthog|sentry|segment\.(io|com)|mixpanel|amplitude|google-analytics|googletagmanager|datadoghq|newrelic|bugsnag|rollbar\.com|hotjar" \
  --exclude-dir=node_modules --exclude-dir=.venv --include='*.scala' --include='*.ts' --include='*.py' --include='*.sh' --include='*.html' . \
  | grep -vE '/tests?/|\.spec\.ts'

The second lists every datris.ai address the code calls, and prints exactly two lines: the two requests described below. Links to the documentation site (docs.datris.ai) are shown to you, never fetched. 

# Every datris.ai address the code calls. Prints exactly two lines.
grep -rnE "[\"']https://([a-z0-9-]+\.)?datris\.ai/[^\"' ]*[\"']" \
  --exclude-dir=node_modules --exclude-dir=.venv --include='*.scala' --include='*.ts' --include='*.py' --include='*.sh' . \
  | grep -vE '/tests?/|\.spec\.ts|docs\.datris\.ai'

The update check. When a person or a script runs datris doctor on the host, doctor asks https://get.datris.ai/version whether a newer release exists. It never runs from the server, never on a timer, and never from datris doctor --pre-upgrade or the installer. It sends the server version, the operating system and the CPU architecture as query parameters, and a datris-doctor/<cli version> User-Agent; nothing else: no API key, cookie, hostname or identifier. It times out in three seconds, and a failure is a skip row that never changes doctor’s exit code. Switch it off with DATRIS_UPDATE_CHECK=0 in the project .env or the environment. Nothing is written on your machine.

What Datris stores for each check: the day, the version, the operating system, the architecture, and a salted hash of the source address. The salt changes every day, so the hash cannot be reversed without the daily salt, which is never published, and cannot be joined across days. The address itself is never stored. We use it to count distinct installs per day by version.

The model catalog. When a person opens the AI configuration screen, the server fetches the current model catalog from datris.ai so the model pickers show what is recommended today. It is triggered by that screen only, cached, times out in three seconds, and falls back to a list built into the UI when it fails. It carries no identifying payload beyond the request itself, and an air-gapped install never notices it.

Adoption is measured only from things you choose to do: request logs on our own install host (get.datris.ai) and the update check above, public registry download counts, and people who subscribe to advisories.

Vulnerabilities

  • Disclosure. Report privately through GitHub security advisories, or email info@datris.ai. We acknowledge within three business days and communicate a remediation timeline within ten.
  • Upgrade checks. The installer runs a pre-upgrade self-check before it pulls anything, and the platform re-checks itself on a schedule you set, reporting to your incident webhook.
  • Supported versions. Security fixes ship in the next release and go to the latest minor version only.
  • Advisories. Published on GitHub Security Advisories and sent to advisory subscribers and commercial licensees ahead of public disclosure.
  • SBOM and scanning. A CycloneDX SBOM for each container image is published with every release. Trivy scans every pull request and the published images weekly; Dependabot covers the rest. Signed builds are provided under a commercial license.

Compliance

SOC 2: not yet. We are a small company and we would rather tell you than let you find out. Most SOC 2 trust-services criteria concern how a vendor handles customer data in its own systems. In a self-hosted deployment no customer data reaches us, so most of those controls fall on your environment, where your existing SOC 2 already covers them. The controls that do apply to us, secure development and vulnerability handling, are described above and documented in the security packet.

The company

Datris is a division of IData Corporation, New Jersey, serving financial-services clients since 1998. Insurance and business-continuity statements are available under NDA with the security packet.

Request the security packet Commercial licensing