Every capability is an API before it's a screen.
The web UI, the Python SDK, the dbt adapter, and every agent on the platform are clients of the same governed REST API. Nothing is console-only, nothing is agent-only — and nothing skips governance on the way through.
One governed surface for humans, pipelines, and agents.
A FastAPI REST service covering the whole platform — queries, natural language, connections, pipelines, lineage, governance, agents, billing. Same endpoints, same policy chokepoint, whoever's calling.
REST, described by OpenAPI
A FastAPI service with a generated OpenAPI spec for every endpoint — queries, natural-language asks, connections, pipelines, lineage, governance, agents, billing. If the UI can do it, the API can do it, because the UI is just another client.
Auth that meets you where you are
API keys via the X-API-Key header, or dbt-style Authorization: Bearer tokens — both authenticate against the same path, so your existing HTTP tooling works unchanged. Agents get their own scoped credentials, distinct from human users. SSO via OAuth 2.0 / OIDC and user provisioning via SCIM for the enterprise side.
Governance you can't route around
Every request — human, SDK, dbt, or agent — passes through the same policy chokepoint. Role-based masking is computed over the columns a query actually returns (SELECT * included), and every read and action lands in the audit trail. There is no side door that skips it.
Metered per action
Usage is metered at the granularity agents operate at: per tool call, per query, rows scanned, LLM tokens. Cost attribution works per agent and per workspace — so autonomous consumption is billable and budgetable, not a mystery line item.
# Run a governed query — API key or Bearer token, both work
curl -s https://api.eisbergdata.com/v1/queries \
-H "X-API-Key: $EISBERG_API_KEY" \
-H "Content-Type: application/json" \
-d '{"sql": "SELECT region, sum(amount) AS revenue
FROM sales.orders GROUP BY 1"}'
# Same call, dbt-style auth
curl -s https://api.eisbergdata.com/v1/queries \
-H "Authorization: Bearer $EISBERG_API_KEY" \
-d '{"sql": "SELECT count(*) FROM sales.orders"}'from eisberg import connect
client = connect("https://api.eisbergdata.com",
api_key="ek-...")
# Governed SQL — masking applied per your role
result = client.query(
"SELECT * FROM customers LIMIT 10")
df = result.to_pandas()
# Or just ask — grounded in the learned
# business ontology, not schema guessing
nl = client.ask(
"top 10 customers by revenue this quarter")
print(nl.answer)Built for agents, not just humans.
Most platforms bolt an API onto a human product and call it agent-ready. Eisberg assumes AI agents are primary users: they get real identity, real limits, real audit — and the platform stays governable at machine speed.
Agents are first-class identities
Every agent carries a birth certificate — a signed identity declaring who created it, what it's scoped to touch, and which actions it may take. Enforcement happens at the platform layer, not by convention: an agent without the right cert doesn't get the data.
Blast radius before execution
Consequential actions are gated by impact analysis: the platform predicts what an action would touch downstream and stops it — or routes it to a human — before it runs. Autonomy with brakes, not autonomy on faith.
Audit trails built for autonomy
Agent activity is logged with the same rigor as human activity: which agent, on whose behalf, which data, what it did, what it cost. When an agent acts at 3am, the morning-after question “what happened and why” has a queryable answer.
Engineered to agent latency budgets
Agents make thousands of small calls where a human makes one big one, so the hot paths — metadata, catalog, governed micro-queries — are engineered to sub-100ms response targets, with an embedded engine handling millisecond-cold-start micro-queries and distributed SQL handling the heavy work.
Any MCP agent becomes an Eisberg user — with governance still on.
Eisberg ships a native Model Context Protocol server, not a wrapper. Claude, or any MCP-compatible agent, gets tools for querying, classification, lineage, business context, and closed-loop actions — and every tool call is authenticated, role-masked, rate-limited, metered, and audited exactly like an API call, because underneath it is one.
Tools the server exposes today — a sample
Beyond the built-ins: connector tools to register and introspect data sources, workspace-defined custom tools, and reusable prompts for common analyses. Action tools like slack.post_message are how an agent closes the loop — it doesn't just answer, it acts, inside the same governance gates.
Meet developers in the tools they already use.
Python SDK
Sync and async clients over the same REST API: run governed SQL, ask in natural language, load data, browse schemas — results straight to pandas. Plus a CLI for the terminal-first.
dbt adapter
A dbt adapter that runs your models on Eisberg compute against Iceberg tables — your existing transformation workflow, pointed at storage you own, with Eisberg's governance underneath.
OpenAPI spec
The generated spec is the contract. Build against it in TypeScript, Go, Rust, or anything with an HTTP client — the Python SDK is a convenience, not a requirement.
Standards you can leave with.
Zero lock-in isn't a tagline; it's an architecture constraint. The formats and protocols underneath Eisberg are the open ones — so your data, your policies, and your integrations outlive any vendor decision, including choosing us.
Apache Iceberg
The only storage format. Your tables live in open Iceberg on your own object store — readable by any engine: Spark, the warehouse you already run, anything Iceberg-compatible.
MCP
The Model Context Protocol is how agents plug in. Any MCP-compatible agent becomes an Eisberg user — no bespoke integration.
OpenAPI
The full REST surface ships as a generated OpenAPI spec. Codegen a client in any language, or point your API tooling straight at it.
OAuth 2.0 / OIDC
Enterprise SSO against your identity provider — the platform federates to your IdP rather than becoming one.
SCIM
User and group provisioning from your directory, so access follows your org chart instead of a spreadsheet.
Policy-as-code
An open policy engine is the single source of authorization — one policy language across the platform, not per-service RBAC snowflakes.
Straight answer on engines: query execution today runs on proven open-source engines — distributed SQL for heavy work, an embedded engine for millisecond micro-queries. GPU-accelerated execution is on the roadmap, not in the product — when we publish speedup numbers, they'll be benchmarked ones.
Ready to ship against Eisberg?
Demo, design partnership, or an MCP integration for an agent you're building — we'll set you up with credentials, the OpenAPI spec, and a worked example against real data.