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.
01
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 - Google projects and Supabase databases are found by signing in, not by pasting keys; a database password you type is encrypted with Cloud KMS like every other credential
- No tool in the MCP server exposes or exports a credential
02
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
03
Your people sign in with their company account
Teams on Microsoft Entra ID sign in through their own tenant. The password, the MFA prompt and your Conditional Access policies all happen on Microsoft's side, against your directory, and you decide there who may use Dataki. Each person lands in your team, recognised by the IDs in a token your tenant signed — never by an email address alone.
- Set up per team: you register Dataki in your own Entra directory and we connect it to your team; its client secret is encrypted with Cloud KMS
- Returning people are matched on their tenant and object IDs, which never change
- An email address counts only on the domains your team lists, so a tenant can speak only for its own people
- Each sign-in can be completed once, only in the browser tab that started it, and within ten minutes
04
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
05
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
06
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
Want the details?
The full key model — scopes, storage, error codes, and what each route accepts — is written up in full. Ask, and we will send it or answer the question directly.