Skip to content
Sovereignty by architecture

Your data stays home. That's not a policy — it's the architecture.

Most compliance SaaS asks you to ship customer data to their cloud. KeplerAI is built the other way around: the compute comes to your data, and only safe artifacts ever leave.

Six guarantees, enforced by design

Data plane on-premise

Your raw data, database credentials and trained model weights live only inside your Runner — on your infrastructure or private cloud.

Outbound-only connectivity

The Runner opens a connection out to the SaaS and pulls jobs. No inbound port, no firewall exception, no reverse tunnel into your network.

Credentials never leave

Source credentials stay in the Runner. The SaaS only stores a logical connection reference — never a secret.

mTLS + per-tenant tokens

Mutual TLS and revocable, tenant-scoped tokens. A token only grants access to its own Runner’s jobs — no cross-tenant reach.

Agents see metadata only

The AI agents reason over schema, column statistics and optional anonymized samples. Generated code runs in your data plane; only aggregates return.

Isolation tiers

From standard (metadata may transit) up to 100% local — where even metadata never leaves and a local model does the code generation.

Outbound-only, explained

No inbound port — so how does the Runner get its work?

It pulls, it isn't pushed to. The Runner phones the SaaS to ask for work, instead of the SaaS phoning your network. Your firewall only ever allows the outbound call — like a browser loading a website.

Pull-based job protocol The Runner long-polls the SaaS job queue over an outbound connection, executes each job near the data, and posts back aggregated results. No inbound port is opened on the client side. SaaS job queue queued → running → succeeded / failed lease + reclaim on timeout idempotent by job_id Runner (client) sandboxed execution on local data (NVMe) firewall stays closed heartbeat every ~15s long-poll: GET jobs/next job payload (code) ↓ POST result: metrics only ↑

The Runner initiates

It opens an outbound HTTPS (443) connection to the SaaS and long-polls “any job for me?”. The order comes back inside the response — no connection is ever opened into your network.

What a firewall cares about

Only who starts the connection. Outbound is allowed by default; inbound is what you’d have to open — and there is none. No listener, no port-forward, no reverse tunnel.

Proven model

Exactly how self-hosted GitHub Actions runners, CI agents and message-queue consumers work: they reach out to fetch work. Results (aggregates only) are posted back the same outbound way.

A persistent variant (WebSocket/gRPC over 443) works the same way: the Runner dials out once and keeps the channel open, so jobs can stream down a connection it opened. The initial handshake is always outbound.

The boundary

Exactly what can and cannot cross

The confidentiality boundary Metadata and code flow down to the data plane; aggregates and metrics flow up to the SaaS. Raw rows, credentials and trained model weights are blocked at the boundary. SaaS · Control plane Client · Data plane boundary schema · column stats · code ↓ aggregates · metrics ↑ raw rows DB credentials model weights agents reason over metadata only

Data security

Defense-in-depth around your data

Because raw data stays inside your environment, most of the attack surface a typical compliance SaaS creates simply doesn't exist. What remains is protected in layers.

Defense-in-depth around your data Concentric security layers protect raw data: your infrastructure boundary, a non-root Runner sandbox with restricted filesystem, mutual TLS with revocable per-tenant tokens, and locally-held credentials encrypted at rest. Raw data never leaves Your infrastructure boundaryRunner sandbox · non-root, restricted FSmTLS + revocable per-tenant tokenLocal credentials · encrypted at rest
Encryption in transit
All control-plane ↔ data-plane traffic is mutually authenticated (mTLS) and encrypted. Metadata and results are never sent in the clear.
Encryption at rest
Your data and credentials sit in your environment, encrypted at rest under your keys. The control plane stores only metadata.
Least-privilege access
RBAC with business roles (manager, controller, analyst, auditor). Column- and table-level access mapping controls what each use case can even see.
Sandboxed execution
Agent-generated code runs in a non-root Runner sandbox with a restricted filesystem and controlled egress — near the data, isolated from it.
Tenant isolation
A per-tenant, revocable token only grants access to that tenant’s Runner jobs. No shared memory, no cross-tenant reach.
Auditability
Every scenario, decision and agent action is traceable, with SHAP explanations and model-drift tracking for model risk management.

Data lifecycle

Where your data is at every step

Follow a record through the platform — it never leaves the box on the right.

1

Ingested

From your source into the Runner, in your environment.

2

Profiled

Schema & column stats computed locally; only metadata is shared.

3

Modeled

Training & scoring run in the sandbox, on local data.

4

Reported

Aggregated metrics surface in dashboards; raw rows stay home.

Isolation tiers

Choose your residency level

Match the level of data movement to your regulatory posture — contractually and technically.

1

Standard

Metadata (schemas, column stats, aggregates) transits to the SaaS. Best code quality via Claude. Raw data never moves.

2

Restricted

Only tightly-scoped metadata and anonymized/synthetic samples transit, per a contractual data-sharing matrix agreed with you.

3

100% local

Even metadata stays inside your data plane. A local model performs code generation (degraded quality) — maximum residency for the strictest environments.

Aligned with how banks think about risk

GDPR and data-residency ready, model governance (SHAP explainability, drift monitoring) and audit trails — the controls regulators expect, without moving your data.

GDPR / data residencymTLSPer-tenant isolationSHAP explainabilityAudit trailRevocable tokens

See the sovereignty model on your own stack.

We'll walk your security team through the boundary, the Runner and the token model.