How Your Data Stays Private on a Multi-Tenant AI Platform

The real question behind "is my data safe?"

When you evaluate an AI platform that touches your business, you're really asking three questions at once. Can another customer ever see my data? Who actually holds the keys to my information? And can this thing do something to my business without me saying yes? Those are separate problems with separate answers, and a vendor that gives you one warm sentence covering all three is dodging.

This guide walks through each one in plain language. You don't need a security background to follow it. The goal is to give you the same mental model a security reviewer would use, so you can ask sharper questions of any vendor — not just us. Where it's relevant, we'll be specific about how Kirality is built, because "we take security seriously" is not a control. The mechanisms are.

Per-tenant isolation: your data is fenced off at the database, not just the app

"Multi-tenant" means many customers share the same software and infrastructure — the same way many tenants share an apartment building. That's normal and it's what keeps cloud software affordable and constantly updated. The risk people worry about is a wall between units that isn't really there: a bug in the application layer that accidentally shows Customer A's records to Customer B.

The durable fix is to enforce the wall below the application, at the database itself. Kirality uses row-level security (RLS), where every table that holds customer data carries a rule the database enforces on every single query: you can only read or write rows tagged with your own tenant. Even if a developer wrote a buggy query, or an attacker found a hole in the app, the database refuses to return another tenant's rows. The isolation doesn't depend on the application code remembering to filter — it's a property of the data store.

This is the difference between a checklist item and a real control. App-level filtering says "we always remember to add WHERE tenant = you." Database-level isolation says "the database will not hand you anyone else's rows even if we forget." We hold ourselves to the second standard: customer tables, including credentials, financial records, and any sensitive personal information, are isolated at the database layer.

BYOK: your model key, your data path

Most AI platforms route your data through their own account with the AI provider (Anthropic, OpenAI, AWS Bedrock). That means your prompts and your business data flow through the vendor's relationship and billing, and you're trusting their configuration to keep your content out of model training and their logs.

Kirality is bring-your-own-key (BYOK). You connect your own Anthropic, OpenAI, or Bedrock key, and your data travels directly on your account's path to the model you chose. Practically, that gives you three things: the provider's enterprise data terms apply to your account (the major providers do not train on business API traffic), you can see and control usage from your own provider dashboard, and you can rotate or revoke the key at any moment to cut off model access without waiting on us.

BYOK also changes the trust question in your favor. Instead of "do I trust the vendor's AI account setup," it becomes "do I trust the AI provider I already chose, on terms I already control." The platform orchestrates the work; the sensitive path to the model is yours.

Least-privilege connectors: access scoped to the job, nothing more

Kirality connects to 60+ business tools — CRM, inbox, calendar, docs, your codebase. Every connection is a place where access could be too broad, so the principle to insist on is least privilege: each connector should request only the permissions the work actually needs, and no standing access beyond that.

In practice that means scoped OAuth rather than a blanket admin grant, read access where the agent only needs to read, and write access only where you've enabled an action. Connector credentials are themselves tenant-isolated and stored as secrets, not sitting in plain view. When a connector's permissions are narrow, the blast radius of any single mistake or compromise stays narrow with it.

The question to ask any vendor: "What exact scopes does this connector request, and can I grant read-only?" A platform built on least privilege can answer precisely. One that asks for the widest grant "to make setup easier" is trading your safety for its convenience.

Human approval as a control, not a courtesy

The feature that quietly does the most for your safety is the simplest to understand: nothing fires without a human click. Kirality's agents do real work in your stack and then propose concrete actions — send this email, update this CRM record, open this pull request — that a person reviews and approves. The model can draft and recommend; it cannot act on its own.

This matters beyond preventing an embarrassing auto-sent email. Human-in-the-loop approval is a security boundary. It means a prompt-injection attack hidden in an incoming email can't trick an agent into quietly exfiltrating data or wiring money, because the consequential step still requires a person who can see what's being proposed and say no. The approval step is where intent gets checked against reality.

It also produces a record. Every proposed action and every approval is an auditable event, so you can answer "who approved what, and when" after the fact. As you build trust, you can choose to graduate specific low-risk, routine actions to run automatically — but that's your decision to make deliberately, not a default that ships turned on.

How to pressure-test any AI vendor on privacy

You now have the four pillars: isolation enforced at the database, BYOK so the model path is yours, least-privilege connectors, and human approval as a hard gate. Turn each into a question. Is tenant isolation enforced at the database layer or only in application code? Do you train on my data, or can I use my own model key? What exact permission scopes does each connector request? Which actions can the AI take without a human approving them?

Good answers are specific and verifiable. Vague answers — "enterprise-grade," "bank-level," "we take privacy seriously" — are marketing, not architecture. A vendor confident in its design will walk you through the mechanism, not just the adjective.

Privacy isn't a single feature you switch on; it's the sum of decisions made at every layer where your data lives and moves. Kirality is built so that your data stays fenced off from other customers, flows to the model on a key you control, reaches your tools through narrow permissions, and never takes a consequential action without your sign-off. That's what "safe" should mean — and what you should hold every vendor to.