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 what Kirality protects, because "we take security seriously" is not a control.

Isolation: one customer's data never reaches another

"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 that accidentally shows Customer A's records to Customer B.

The wall worth paying for is one that holds even when a single piece of code is wrong. With Kirality, each business's data is isolated from every other business's, so another customer cannot read your records, credentials, financial data, or any sensitive personal information.

This is the difference between a checklist item and a real control. "We're careful" is a promise; isolation that is tested before every release is a control. Ask any vendor which one they are offering, and how they would know if it broke.

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.

On Kirality's Pro plan you 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 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 kept per business and encrypted, 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: by default, nothing fires without a human click. With Kirality, the AI does real work in your stack and then proposes concrete actions — send this email, update this CRM record, open this pull request — that a person reviews and approves. By default, the model can draft and recommend; it does not 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 let specific low-risk, routine actions run on their own — 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 that holds even when one piece of code is wrong, BYOK so the model path is yours, least-privilege connectors, and human approval as a hard gate. Turn each into a question. How is tenant isolation enforced, and how do you test it? 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, reaches your tools through narrow permissions, and by default never takes a consequential action without your sign-off — and on Pro, it flows to the model on a key you control. That's what "safe" should mean — and what you should hold every vendor to.