Deployment Models

For enterprise security architects | Version 1.2 | July 2026 | Detailed information in our SOC 2 Type II report

definity instruments data pipelines with lightweight agents (a JAR or Python library) that load into the pipeline runtime (Spark, DBT, and others) and report to the definity platform server over an agent-initiated, outbound-only TLS channel. What crosses the trust boundary is metadata - pipeline and schema metadata, statistical metrics, and query/lineage metadata - plus a few row values sampled to diagnose skew and failures, which privacy mode switches off. Query text includes SQL literals, which may contain data values. Bulk data and query results never leave the pipeline runtime. definity never initiates inbound connections into a customer environment.

definity offers three deployment models. They differ in where the platform server runs and how it is reached - not in what data crosses the boundary. This document describes each model end-to-end: its architecture, its security controls, and what we need from you. For most customers we recommend the definity SaaS model (Option 1): it delivers the full platform with the least operational burden and the strongest patch posture, while keeping the same trust boundary as every other option.

1. Security Foundation (Common to All Models)

The controls below apply identically to all three deployment models; the sections that follow only describe how each model is reached. The customer's data plane is always the trust boundary: agents execute inside it and construct their payload from metadata in-process, which bounds the blast radius of any control-plane compromise to what the agent reports - metadata, query text and sampled values - never bulk customer data.

Data type	Transmitted	Notes
Pipeline metadata	Yes	Job name, start/stop, run status, DAG/task IDs
Schema metadata	Yes	Column names, types, evolution history
Metrics	Yes	Duration, counts, error rates, resource usage, column distribution statistics (opt-in per column)
Query & lineage metadata	Yes	Powers lineage & RCA; query text includes SQL literals, which may contain data values
Diagnostic row samples	Yes (default)	A few key values from the slowest tasks and the row a failed task was on; off with spark.definity.privacy.enabled
Bulk data & query results	No	Never leaves the pipeline runtime; extraction is in-process

• Outbound-only connectivity. Agents open connections outbound; definity never initiates inbound connections. No inbound ports, no firewall exceptions, no network listener inside the customer network. Your egress policy remains the single point of control over the channel.
• Bounded, predefined command set. The agent can only get a fixed, predefined set of operations from the server - it cannot send the agent new undefined instructions of its own. Control is therefore fully bounded: even if the control plane were ever compromised, it could only trigger the same predefined operations, always within the agent's least-privilege scope.
• Configurable agent capability. Two per-job switches, set only in the job's own Spark configuration and never from the server: spark.definity.privacy.enabled stops sending any value read from your rows, and spark.definity.readOnly turns off every server-requested operation (overrides, autotuning, output diversion, extra queries, stopping a run). See the configuration reference.
• Least-privilege agent. The agent runs with exactly the permissions granted to the instrumented Spark job - definity requests no special or additional permissions or credentials. We recommend running instrumented jobs under least-privilege service accounts (a documented client responsibility).
• Minimal supply-chain surface. The agent has no external third-party runtime dependencies (outside of the customer's existing Spark stack); release artifacts are checksummed (artifact signing on the roadmap) and should be scanned & hosted in your own artifact repository and version-pinned.
• Fail-safe behavior. Agents self-disable on any anomaly - uncaught exceptions, timeouts, or a measured overhead above threshold - and on any loss of communication with the control plane. In every such case, the agent folds itself out of the job immediately, and the pipeline continues unaffected. definity availability is never on the critical path of customer jobs.
• Global token kill-switch (definity-operated safeguard). All agent tokens derive from a central server secret held by definity. In an emergency - for example any suspicion of token exposure - definity can rotate that secret, which instantly invalidates every agent token; agents then lose contact with the server and fail safe by disabling themselves, while your pipelines keep running. This lets us guarantee an immediate, complete severing of all agents with no impact on your workloads, protecting the integrity of your environment - and it means a compromised server cannot pivot into your environment.
• No standing employee access to production. definity personnel do not have standing access to customer production data or environments; any support access is least-privilege, time-bounded, and logged as detailed in the company's SOC2.
• Prompt remediation. Security issues are patched promptly, prioritized by severity, and rolled out by definity (in SaaS models, transparently and without customer action) as detailed in the SOC2.
• Encryption. TLS 1.2+ in transit (mutual TLS available); AES-256 at rest.
• Why the agent cannot harm your environment. Four independent properties combine: connectivity is outbound-only (definity holds no path or credential granting ingress to you); control is limited to a fixed, predefined set of operations (the server cannot introduce new agent logic); the agent has no privileges beyond the job it runs in; and it fails safe - folding itself out on any anomaly or on loss of server contact. You retain unilateral kill switches at all times: your egress policy and credential revocation.

Client responsibilities (summary)

• Run instrumented jobs under least-privilege service accounts - the agent inherits only the job's permissions.
• Control the outbound channel through your security policy (and Private Link where used); you hold the kill switch.
• Manage user lifecycle through your IdP (SSO/OIDC).

2. Option 1 - definity SaaS (Multi-Tenant) · Recommended

The platform server is hosted and operated in definity's cloud. Agents connect outbound over HTTPS (TCP 443, TLS 1.2+). Zero customer infrastructure; definity owns operations, scaling, and patching. This is the recommended model and the standard model for POCs.

Why SaaS (advantages)

• Fastest to value & zero operational burden - no server to deploy, size, scale, or maintain; instrument a pipeline and begin in minutes.
• Strongest patch posture - definity applies security and reliability fixes promptly, prioritized by severity, and transparently; you never run an out-of-date or unpatched definity server (a common source of risk).
• Full platform intelligence - fleet-tuned optimization and agentic analysis are available in full, with no reduced-functionality trade-off.
• Same trust boundary - same egress, outbound-only, fixed command set, and fail-safe apply exactly as in every other model; SaaS does not widen what leaves your environment.
• Fast implementation - one central install, zero code changes, no infrastructure to provision - instrument all workloads and see value the same week.

Controls

OAuth 2.0 bearer tokens per agent - scoped and least-privilege, with a lifetime the admin sets when generating each token (configurable by the client*). Access is administered at the organization level by a tenant administrator, with admin / user / read-only roles and pipeline ownership today, and more granular, domain-scoped RBAC on the roadmap; SSO via OIDC (compatible with providers such as Okta) with MFA. Immutable logging of administrative actions, API requests, and agent registrations. Tenant data is logically segregated by unique tenant IDs enforced through application-layer authorization. Metadata retention: 90 days by default, configurable. Compliance: SOC 2 Type II; GDPR and CCPA aligned; annual third-party penetration testing; documented incident response; customer notification follows applicable legal and contractual requirements.

Private Link option - and why it helps

For no-public-internet mandates, agent traffic can ride Private Link (AWS PrivateLink, Azure Private Link, Google Private Service Connect) to a definity endpoint with no public IP. Private Link keeps traffic on the cloud provider's private backbone: there is no exposure to the public internet, no inbound port on either side, and reachability is constrained to an endpoint you explicitly allowlist - reducing the network attack surface to a single, customer-approved path with private DNS.

What we need from you

• Infrastructure: none. definity hosts and operates the platform.
• Network: a single egress allow rule for agents - outbound HTTPS (TCP 443) to definity endpoints (provided during onboarding). Customer egress proxies are supported, provided they do not modify the request.
• Agent: add the definity agent to the pipeline runtime (Spark JAR / Python library; Databricks, EMR, Dataproc, and Airflow integrations available). Host the agent artifact in your own repository and store the agent token in your secrets manager (injected at runtime), not in plaintext configuration.
• Optional Private Link*: a one-time approval handshake per cloud and region - you allowlist your account or VPC against definity's endpoint service and provision private DNS and a route from the data-plane subnets (for Databricks, confirm reachability from the Databricks data-plane VPC during design).
• Optional SSO*: OIDC integration with your IdP; user lifecycle (provisioning / deprovisioning) is then managed by your IdP.

3. Option 2 - Dedicated Tenant (Isolated Single-Tenant SaaS)

· (Relevant for commercial & paid POC's only)

A complete definity environment provisioned exclusively for one customer: dedicated compute, storage, and processing, per-customer encryption keys, and deployment in a customer-selected cloud region. Both agent traffic and the web application (UI and APIs) are published only through Private Link - no definity endpoint for the deployment is reachable from the public internet. All traffic flows over the cloud provider's private backbone and never traverses the public internet; there is no public attack surface to scan, firewall, or monitor, no inbound exceptions to approve, and access is governed end-to-end by your own network controls. For your security team, the entire network review collapses to a single private endpoint. This removes cross-tenant risk from the assessment entirely. The Dedicated Tenant model is not offered for free POCs; it is available for production deployments under Enterprise commercial terms.

Controls

All Option 1 controls, plus: no compute, storage, or encryption scope shared with any other tenant (no shared blast radius, no noisy-neighbor concerns); per-customer encryption keys; web UI and APIs reachable exclusively from your network via a private endpoint; deployment in your selected cloud region to satisfy data-residency requirements.

What we need from you

Everything in Option 1, plus:

• Commercial: Enterprise agreement (not available at free POC's); target cloud and region selection.
• Network: Private Link endpoints for both agent traffic and the web application; user access to the UI via your own network controls (VPN or corporate network).
• Region: the dedicated environment is provisioned in the region agreed under the Enterprise terms (custom region deployment carries an additional cost).

4. Option 3 - Self-Hosted (On-Prem / Customer VPC)

The Security Foundation controls apply identically to this model.

The definity server is deployed inside the customer network as a Helm chart or Docker Compose package. Agents reach it over the internal network and all pipeline metadata stays on-premises. A single, controlled, outbound-only path from a definity connector (a lightweight, outbound-only component that runs alongside the definity server) to the definity control plane restores definity-operated models, analysis, and updates.

An honest note on connectivity. This model keeps your data on-premises, but it is not air-gapped. Both during a POC and in production, the server needs a controlled, outbound-only path to definity - periodically - to receive fleet-tuned models, analysis, and updates. During a POC this path is time-bounded (typically opened only in week 2), restricted to specific definity-controlled endpoints, and may run over Private Link or the customer's egress proxy.

Controls on the connected path

Control	Requirement
Exposed surface	Only the specific control endpoints definity requires, enforced at the connector. Full API and web UI are not exposed.
Authentication	Mutual TLS plus scoped OAuth 2.0 tokens, with a lifetime the admin sets when generating each token. Network position never grants access.
Authorization	Dedicated least-privilege service account. No admin or user-management scope.
Audit	Every definity call over the channel is logged immutably (identity, timestamp, endpoint, outcome) and is visible to you if needed.
Revocation	You can stop the connector or revoke the credential unilaterally and immediately, with no dependency on definity.
Change governance	Any expansion of the exposed endpoint set or service role is a reviewable, approved change.

What we need from you

• Infrastructure: Kubernetes (Helm) or Docker Compose host sized per definity's spec; you own deployment, scaling, patching, and upgrades of the server. Provide a PostgreSQL 15+ database (managed, e.g. RDS/Cloud SQL, or in-cluster with persistent storage) - you own its backup, availability, and patching. An SMTP relay is required for alert delivery (cloud models use the provider's native mail service).
• Internal network: agents must reach the internal definity server.
• Connectivity (required, periodic): one outbound-only path from the connector to the definity control plane, via either (a) Private Link (AWS/Azure/GCP/OCI/IBM), or (b) allowlisted outbound TCP 443 (TLS 1.2+) to a fixed, definity-controlled set of IPs/FQDNs (provided during onboarding), optionally via your egress proxy, governed by the Connectivity Appendix (window, endpoints, revocation).
• Not required: no inbound connections, no VPN into your network, no raw data movement.

POC timeline (Estimated Two weeks)

Phase	Connectivity state
Week 1	definity server deployed inside your environment; agents instrument selected pipelines. All data internal; no external connectivity open.
Week 2	The agreed outbound window is opened (Private Link, or allowlisted outbound 443). definity performs analysis on pipeline metadata. All traffic TLS-encrypted, authenticated, audited.
POC close	Connectivity closed; credentials revoked by you; all POC data deleted per Data Retention and Deletion. Written confirmation available on request.

Post PoC deployment access will be designed together with the customer's security architects.

5. Models at a Glance

Dimension	1. SaaS	2. Dedicated Tenant	3. Self-Hosted
Server location	definity cloud (multi-tenant)	definity cloud, dedicated	Your network (VPC / on-prem)
Tenancy	Multi-tenant (logical isolation)	Single-tenant (dedicated)	Single-tenant (your deployment)
Data leaving boundary	Metadata, metrics, query text and sampled values	Metadata, metrics, query text and sampled values	Pipeline metadata, over the periodic connector path only
Connectivity	Outbound only; no inbound	Outbound only; Private Link	Outbound only; periodic connector path (Private Link or allowlisted 443)
Web UI / API	Public HTTPS + SSO/MFA	Private Link only	Inside your network
Available for POC	Yes (standard)	Only for paid POC's	Yes (two weeks)
Ops & patching	definity	definity	You

Recommendation. Choose SaaS (Option 1) by default - it is the fastest, best-patched, and lowest-maintenance path with the full platform. Select the Dedicated Tenant model where you require single-tenant isolation or in-region residency, and Self-Hosted where the server must run inside your environment. All three share the same outbound-only trust boundary.

6. Data Retention and Deletion

Data is retained no longer than necessary; deletion means secure destruction - rendering data non-recoverable, including from backups - administered under definity's Record Retention Policy, with a disposal record maintained.

Item	Commitment
Production SaaS retention	Pipeline metadata and metrics retained 90 days by default; configurable per contract.
Detailed payload logs (added)	A full payload log of every request (the metadata and metrics agents report) is retained for 30 days for incident analysis, then purged. For longer retention, definity recommends enabling audit logging in Spark and exporting the data to your organizational logging system.
Operational / audit logs	12 months.
POC data	All customer-derived POC data (metadata, metrics, derived insights, logs referencing customer identifiers) deleted within 30 days of POC close; no data kept after the POC.
Deletion on request	Available at any time; secure destruction including removal from backups.
Data resale / licensing	definity does not sell or license customer information or data to anyone.

7. Frequently Asked Questions (Security Review)

Q: What data exactly leaves our environment?

Pipeline metadata (job names, run status, DAG/task IDs), schema metadata (column names, types), and statistical metrics (durations, counts, error rates, resource usage, column distribution statistics). Query and lineage metadata is also collected for root-cause analysis, and by default a few row values are sampled to diagnose skew and failures - spark.definity.privacy.enabled turns those off. Bulk data and query results never leave. See the classification table in Section 1. A complete, field-level breakdown of every metric and metadata item we collect is published in our documentation at docs.definity.ai.

Q: Do you capture our SQL queries or transformation logic?

definity derives lineage and query-level metadata to power root-cause and impact analysis. Query text is sent with its SQL literals, which may contain data values.

Q: How do we ensure no one can use definity to take over our environment?

This is engineered as defense in depth - several independent controls, each sufficient on its own to prevent it. (1) No inbound path: connectivity is agent-initiated and outbound-only; definity never opens a connection into your network, holds no inbound credential, and runs no listener or open port inside your environment - there is simply no channel to reach in through. (2) Bounded control, not code: the agent can only get from the server a fixed, predefined set of operations; it cannot get new logic, scripts, or instructions, so even a compromised control plane cannot execute on your side undefined agent operations. With spark.definity.readOnly set, the server can request none of them. (3) Least privilege: the agent runs only with the permissions you already granted the instrumented Spark job and requests nothing more, so it can never exceed that scope. (4) Fail-safe: on any anomaly (exceptions, timeouts, excess overhead) or any loss of contact with the server, the agent disables itself while your pipeline continues unaffected. (5) Instant severing: in an emergency definity can rotate the central secret to invalidate every agent token at once, and you independently hold your own kill switches - block egress, revoke credentials, remove agent from artifactory - with no dependency on us. (6) Bounded blast radius with full audit: only metadata, query text and diagnostic samples cross the boundary (no samples with privacy mode), so the worst case of any compromise never reaches your bulk data, and every cross-boundary call is immutably logged. A takeover would require defeating all of these independent layers at once - not any single control.

Q: What happens if definity is unavailable or breached?

If the control plane is unreachable, agents pause and your pipelines continue unaffected. The blast radius of a control-plane compromise is bounded to what the agent reported - metadata and diagnostic samples, never bulk data - and all agent tokens can be invalidated instantly by rotating the central server secret - every agent then loses contact and self-disables, giving a full disconnect with no impact on your workloads, so a compromised server cannot pivot into your environment.

Q: Does definity staff have access to our production data?

No standing access. definity personnel do not hold standing access to customer production data or environments; any support access is least-privilege, time-bounded, and logged. In the Dedicated Tenant model, data does not reside in shared infrastructure at all.

Q: How quickly are vulnerabilities patched?

Promptly, prioritized by severity. In SaaS and Dedicated Tenant models, definity applies and rolls out fixes transparently with no customer action.

Q: Do you use our data to train AI models?

definity does not use customer content or personal data to train AI models. Aggregated, de-identified technical usage metadata (e.g., data volumes, performance signals, error rates) may be used to improve optimization models; this can be disabled by contract. Any third-party LLM usage is governed by no-training / no-retention terms and can be restricted per customer policy.

Q: Can we terminate definity's access unilaterally?

Yes, immediately and without dependency on definity: block the egress path (it is the only path) or revoke the credentials. definity also supports forced rotation and revocation of secrets in use.

Q: How do users authenticate?

Access is administered at the organization level (admin / user / read-only roles, plus pipeline ownership; more granular RBAC on the roadmap). SSO via OIDC (Okta and similar) with MFA. With SSO enabled, user provisioning and deprovisioning are driven by your IdP.

Q: Where is our data hosted, and can we choose the region?

Standard SaaS operates from defined cloud region(s). The Dedicated Tenant model deploys in a cloud region you select, to meet data-residency requirements. Tell us your residency requirement and we will confirm the region during design.

Q: How is multi-tenant isolation enforced in the SaaS model?

Tenant data is logically isolated by unique tenant IDs enforced at the application authorization layer, on encrypted storage, and access is scoped per tenant. Customers requiring physical isolation use the Dedicated Tenant model - dedicated compute, storage, and per-customer keys - which removes any cross-tenant surface from the assessment.

Q: What is the agent's performance overhead on our pipelines?

Negligible. Metadata is collected in-process with no additional data scans by default; measured overhead is approximately 0.5% on the Spark driver and under 0.2% of executor compute across roughly 1.5 million production task executions. Optional column-distribution metrics are opt-in per column.

Q: Do you support customer-managed encryption keys (BYOK)?

The Dedicated Tenant model uses per-customer encryption keys. Customer-held key management (BYOK) is on the Enterprise roadmap - share your requirement and we will align on the approach.

Q: Which sub-processors and AI providers do you use?

The current sub-processor list, including third-party LLM providers, is published under Vendors & Subprocessors. LLM usage is governed by no-training / no-retention terms and can be restricted or disabled to match your policy.

Q: Are you SOC 2 Type II? Can we review the report and a penetration test?

Yes - SOC 2 Type II. The report, its bridge letter and a third-party penetration-test attestation letter are in the 🔒 Security Documents; to request access, contact [email protected].

Q: How are security incidents handled?

Under a documented incident-response and breach policy. Where an incident affects customer information and notification is required by applicable law or contractual commitments, definity follows the applicable notification requirements. Urgent security contact: [email protected].

---

Next steps. Share this document with your security team, then let us scope a two-week POC.

This document is provided for security evaluation purposes and reflects definity's architecture and controls as of the version date. Formal commitments are established in the applicable agreement and appendices.