Security & governance
What an AI agent can reach, and what it cannot
Connecting an autonomous assistant to production data is a real decision. Here is exactly how Dataki bounds it — written for whoever has to approve it.
Your credentials never leave Dataki
Database passwords and service-account keys are encrypted with Google Cloud KMS and decrypted only inside our backend, for the duration of a single query. An AI assistant connected to Dataki receives query results. It never receives a connection string, and there is no tool that would hand it one.
-
Warehouse credentials encrypted at rest with Cloud KMS - OAuth for Google and Supabase — no passwords stored where we can read them
- No tool in the MCP server exposes or exports a credential
An agent inherits its user's access, and nothing more
Every API key acts as the person who created it. It can never reach a data source that person could not already open, and every request runs the same permission checks a browser session goes through — including the checks inside the agent's own tool loop, because a model can invent a source id and the conversation history is client-controlled.
- Keys are scoped: seeing sources, querying, reading dashboards, writing dashboards and running the agent are separate permissions
- A key can be restricted to one team even when its owner belongs to several
- Keys cannot create other keys, invite users, link cloud projects or store OAuth credentials — those need a signed-in person
Every query is recorded
Each query is logged with who or what ran it, which key, the SQL, how many rows came back and how long it took. Failures are logged too — a run of them is what a misbehaving agent looks like, and it is invisible if only successes are recorded.
- Per-query attribution down to the individual API key
- Readable and exportable by workspace administrators
- Retained independently of the key, so revoking one does not erase its history
An agent cannot spend without limit
An autonomous assistant holding a warehouse connection is an unbounded bill unless something stops it. Every key carries a daily ceiling on queries and on bytes scanned. When a key reaches it, further queries are refused with a message the assistant can report to its user, and the ceiling resets at midnight UTC.
- Daily caps on query count and bytes scanned, per key
- Enforced in the query path, not by a nightly reconciliation
- Set per key, so a shared production key and a personal experiment are not the same risk
Revocation is immediate
Revoke a key and it stops working on the next request. Nothing is cached, and there is no window in which a revoked key still resolves. The record survives revocation so audit entries pointing at it still resolve to a name.
- Takes effect on the next request, with no propagation delay
- Keys can be given an expiry date at creation
- We store a one-way hash of every key — a copy of our database yields no usable credentials
Read the details
The full key model — scopes, storage, error codes, and what each route accepts — is documented alongside the code.