Is Your Company Data Safe With an AI Assistant?

Yes, an AI assistant can be safe with your company data, but safety comes from architecture, not promises. The safest assistants are read-only by default, keep your data inside the tools you already use instead of copying it into a separate database, require one-tap confirmation before any message is sent, and encrypt access tokens at rest. Here is what to verify before you connect anything.

The real fears: training, exfiltration, and third-party sharing

When people ask "is an AI assistant safe," they usually mean three specific worries, and it helps to separate them.

• Training on your data. Will my emails, contracts, and Slack threads be used to train a model that other companies can then query? This is the biggest fear, and a fair one.
• Exfiltration. Could the assistant copy sensitive data out of my tools and store it somewhere I cannot see or control?
• Third-party sharing. Does the vendor pass my data to sub-processors, advertisers, or partners I never agreed to?

These are legitimate questions, and the honest answer is that not every AI product handles them well. The difference between a safe assistant and a risky one comes down to a few concrete design choices you can actually check. Below, each fear maps to a specific safeguard.

Read-only by default: what the AI can and cannot touch

The single most important safety property is read-only access. A read-only AI can look at information to answer your questions, but it cannot change, move, or delete anything on its own.

That means Holka can read across your connected tools to answer "which customers churned last quarter and why," but it cannot silently reply to an email, edit a Notion doc, close a deal in your CRM, or delete a file. Reading is reversible and low-risk; writing is not. Making read the default removes an entire category of accidents.

If a vendor cannot clearly tell you what the assistant is technically prevented from doing, that is a signal to slow down.

One-tap confirmation before any email or Slack is sent

Read-only does not mean the assistant is useless for action. It means writes are handled differently. When you ask Holka to reply to a customer or post an update, it prepares a draft and shows it to you. Nothing leaves your account until you approve it with one tap.

This keeps a human in the loop for every outbound action. You see the exact recipient, the exact wording, and the exact channel before anything happens. There is no "the AI sent something on my behalf that I did not see." Drafting into Slack or Gmail works this way by design, so the assistant stays helpful without ever acting unilaterally.

Access tokens encrypted at rest, and why that matters

To read across your tools, an assistant holds access tokens: the credentials that let it connect to Gmail, Notion, HubSpot, and the rest. How those tokens are stored is a real security question.

Holka encrypts access tokens at rest. In plain terms, the credentials are kept in a scrambled form that is useless without the decryption key, so a snapshot of the database alone does not expose your accounts. This matters because tokens are the keys to the building. If they were stored in plain text and the storage were ever exposed, someone could use them directly. Encryption at rest is a baseline you should expect from any vendor, and you should ask exactly how it is implemented.

"Your data stays in your tools": no bulk copying

Many search and knowledge tools work by indexing: they crawl all your systems and copy the contents into their own database so they can search it fast. That copy is convenient, but it creates a second home for your most sensitive information, one more place that can be breached, mismanaged, or retained after you leave.

Holka takes the opposite approach. Your data stays in your tools. When you ask a question, it reads what it needs from the source at that moment and answers, rather than maintaining a bulk mirror of everything you own. Fewer copies means a smaller attack surface and less to worry about if you ever disconnect. This "read from the source" model is a meaningful difference from index-everything competitors like Glean and Dashworks, which typically build a central index.

Practically, this also answers "does the AI store my data?" The goal is to store as little as structurally possible, not to hoard a searchable copy of your company.

How OAuth scopes limit what is ever accessible

OAuth is the standard "connect with Google" or "connect with Slack" flow, and it does more than log you in. It defines scopes, the specific permissions you grant. Scopes are a hard boundary: the assistant can only ever reach what the scope allows.

A few things worth knowing:

• You connect each tool individually, so you decide which systems the assistant sees and which it does not.
• The tool you are connecting to (Google, Slack, and so on) enforces the scopes on its side, independent of the AI vendor.
• Connecting one tool grants nothing about another. Approving Google Drive says nothing about your Stripe data.

This is why per-tool OAuth is safer than handing over a master password: the permission is narrow, visible, and enforced by the source system. You can browse the full list of supported integrations and connect only what a given team needs.

Revoking access anytime, per user

Consent should be reversible. With OAuth, you can revoke access at any time, either inside Holka or directly from the connected tool's own security settings (for example, the "third-party apps with account access" page in Google or Slack).

Because access is granted per user and per tool, revoking is precise. One person leaving the team, or one tool you would rather disconnect, does not force an all-or-nothing decision. And because your data was never bulk-copied into a separate index, disconnecting actually means the assistant stops being able to read that source, not that a hidden copy lingers. This per-user control also makes the assistant a better fit for operations and IT leads who need to manage access cleanly.

Questions to ask any AI vendor before you connect

Use these to cut through marketing language. The good answers are specific.

• Do you train your models on our data? You want a clear no.
• Is it read-only by default, and what exactly can it write? Look for an explicit list and a confirmation step.
• Do you copy our data into your own index, or read from the source? Fewer copies is safer.
• Are access tokens encrypted at rest? This should be a plain yes with a short explanation.
• How is access granted and revoked? Per-user, per-tool OAuth with self-serve revocation is the standard to want.
• Who are your sub-processors, and is our data shared with third parties? Ask for the list.
• What data is retained, for how long, and can we delete it? Vague answers are a red flag.

Be cautious of anyone who answers with certifications instead of mechanics. A logo does not tell you whether the assistant can send email without asking you first.

A checklist to forward to your CEO or IT lead

Copy this straight into an email or ticket.

• Confirmed the assistant does not train models on our data
• Confirmed read-only by default, with a written list of any write actions
• Confirmed every send (email, Slack, and so on) requires one-tap human confirmation
• Confirmed access tokens are encrypted at rest
• Confirmed data stays in our tools with no bulk index copy
• Confirmed connections use per-tool OAuth scopes
• Confirmed access can be revoked anytime, per user
• Reviewed the vendor's sub-processor and retention policies
• Started with one low-risk tool before connecting sensitive systems
• Reviewed transparent, no-seat-minimum pricing so cost does not pressure over-connecting

Safety with an AI assistant is not a leap of faith. It is a set of design decisions you can inspect one by one: what it can touch, whether a human approves each action, where your data lives, and how easily you can pull the plug. When those answers are read-only, confirmed, in-your-tools, and revocable, connecting an assistant becomes a controlled, reversible step rather than an irreversible handover. Start narrow, verify each safeguard against the checklist above, and expand only as trust is earned.