Skip to content

Security that runs inside your network

DeltaForge is software you install and operate on your own infrastructure. There is no external control plane to trust. Your data, your keys, your network perimeter: DeltaForge enforces access inside it.

RBAC with GRANT/REVOKE, plus row-level security and column masking
Storage credentials in OS Keychain or Azure Key Vault, never in config files
Audit log: every query, every authorization decision, every schema change
Identities admin ADMIN analyst READ etl_svc WRITE viewer VIEW QUERY Policy Engine RBAC GRANT SELECT ON schema.* Credential Vault Keychain / Key Vault Audit Log every decision logged TLS in Transit all connections encrypted ALLOW DENY Resources orders customers finance analytics pii_data Audit Trail [10:32:01] ALLOW analyst SELECT orders [10:32:03] DENY viewer SELECT finance [10:32:05] ALLOW analyst SELECT customers.email

Your network, your posture

Because DeltaForge runs on infrastructure you control, it inherits the network controls you already have in place. VPC isolation, firewall rules, private endpoints: these apply to DeltaForge the same way they apply to anything else in your environment.

No external control plane

The control plane runs on your VMs or on-premises. No traffic leaves your network to reach a DeltaForge-managed service. You operate the software; you control the perimeter.

Credentials stay in your vaults

Storage credentials and connection secrets are stored in OS Keychain (for desktop) or Azure Key Vault (for production). The catalog stores references only. The GUI never touches credentials directly; all operations go through the control plane HTTP API.

TLS on every connection

All connections between components (GUI to control plane, ODBC driver to compute node, compute node to object storage) run over TLS. There is no plaintext path.

RBAC, row-level security, and column masking

Standard SQL access control enforced by the engine before any read or write reaches the data, on Delta Lake and Iceberg tables alike.

Privilege types

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, ADMIN. Granted per object at zone, schema, table, view, or column granularity. REVOKE takes effect immediately.

Roles

Built-in administrative roles plus custom roles you define. Role hierarchy with inheritance. Multiple roles per identity. Grants cascade downward: a schema grant covers all tables in that schema.

Service accounts

Named identities for automation and pipeline runs. Scoped tokens with explicit tool allow-lists for MCP agent sessions. Token expiry and revocation from the control plane.

Row-level security

Row filters constrain which rows an identity can read from a Delta Lake or Iceberg table. The filter is applied inside the engine on every access path, so there is no view layer to bypass and no per-tool configuration to keep in sync.

Column masking

Masking is implemented as pseudonymisation rules with per-principal exempt lists. Identities not on the exempt list see redacted, hashed, or generalised values; exempt roles and users read the raw column.

One enforcement point

The same RBAC engine governs SQL queries, ODBC connections, MCP tool calls, and the desktop GUI. There is no second permission system to keep aligned with the first.

Audit log

Every authorization decision, every query, every schema change: all recorded with identity, timestamp, and outcome.

What is logged

Authentication events, ALLOW and DENY decisions, data access (read/write), DDL operations (CREATE, ALTER, DROP), permission changes (GRANT, REVOKE), and configuration changes.

What each entry contains

Timestamp with timezone, user identity and session, source IP, action and resource, success or failure status, and the SQL or API call that triggered the entry.

Export and retention

Configurable retention policies. Log export for SIEM integration. MCP tool calls from AI agents land in the same log as human queries so you have a unified record of all access.

Compliance evidence

The audit log is designed to support SOC 2, HIPAA, and GDPR evidence gathering. For GDPR column protection see pseudonymisation; for HIPAA-aligned clinical data work see healthcare formats.

Governed access for AI agents

Agents are identities like any other. The governance that applies to a human analyst applies, unchanged, to an AI assistant calling tools.

Same rules as humans

The MCP server enforces RBAC, row filters, and column masks on every tool call. An agent cannot read a row or column that its identity could not read through SQL.

Scoped tokens and tool allow-lists

Agent sessions run under service accounts with scoped tokens and explicit tool allow-lists. Tokens expire and can be revoked from the control plane at any time.

One audit trail

Every tool call an agent makes lands in the same audit log as human queries, with identity, timestamp, and outcome. Reviewing agent activity is the same workflow as reviewing user activity.

Further reading

Hands-on guides where these controls do real work

GDPR Right to be Forgotten on Delta Lake, in SQL

A deletion workflow end to end: pseudonymisation rules for day-to-day exposure, physical erasure for Article 17 requests, and the audit log as evidence.

Security that lives where your data does

Install DeltaForge inside your network. Apply your existing perimeter controls. Govern access with standard SQL GRANT and REVOKE.