How Bohari AI protects sensitive information when you use the assistant: what gets masked before a message leaves the platform, who can turn AI on, and how every interaction is logged.
The assistant answers from your company's own documents and, where a tool exists for it, your company's own records. That's still worth protecting carefully. Your knowledge base can contain financial and personal details, and anything you type into a chat could too. Bohari handles this in three layers: AI is off until you switch it on, sensitive-looking values are masked out of prompts before they reach a model provider, and every prompt and response is recorded so you can review what happened. This article walks through each layer and where to find the controls.
AI is off until you enable it
Nothing goes to an AI provider unless AI is enabled for your company. Enablement is checked on every request, in this order:
- Platform switch. If a platform administrator has disabled AI across the whole platform, every AI request is rejected. Nothing reaches a provider.
- Company switch. Your company's AI Enabled toggle (in AI Settings) must be on. It ships off by default.
- Feature switch. The specific feature you're using must be in your company's enabled-features list. Today the chat itself offers a single feature, General Chat, so this mostly matters for whether AI is available to you at all.
So a single request has to clear three gates before it ever calls a model. Turning off the company toggle stops everything at once.
Three permissions govern who controls this:
| Permission | What it allows |
|---|---|
view_ai | View AI settings, usage, and audit logs |
manage_ai | Change AI settings: enable/disable AI, pick provider/model, edit redacted-field settings, set budgets |
use_ai_chat | Use the chat itself |
What gets masked before a prompt is sent
When redaction is on (and it's on by default), Bohari scans your message, your conversation history, and anything a tool looks up for sensitive-looking patterns, and masks them before the text is sent to the provider. The model never sees the original value. It sees a placeholder like [ID NUMBER REDACTED] instead.
Redaction is pattern-based. Each field type Bohari knows how to detect:
| Field | What it matches | Replaced with |
|---|---|---|
bank_account | Digits following a label like account:, acct, a/c | [BANK ACCOUNT REDACTED] |
tax_id | Tax-identifier-style formats, including a KRA PIN pattern | [TAX ID REDACTED] |
id_number | National ID / passport style codes | [ID NUMBER REDACTED] |
credit_card | 15 to 16 digit card numbers | [CARD REDACTED] |
phone | Phone numbers | [PHONE REDACTED] |
email | Email addresses | [EMAIL REDACTED] |
date_of_birth | Dates labelled DOB / "date of birth" / "born on" | [DOB REDACTED] |
Your company chooses which of these are active, in the Redacted Fields setting in AI Settings. A core set covering IDs, tax numbers, bank details and monetary figures is on by default. You can add or remove field names (comma or newline separated). Only field names with detection rules behind them have any effect.
Bank-account matching is deliberately conservative
Bank account numbers are only masked when they follow a label such as account: or acct. A bare run of digits is not treated as a bank account, because an earlier rule that matched any 8-to-17 digit string flagged reference numbers and phone fragments as bank accounts. If you want a raw account number masked, write it with its label.
Structured data from tools is scrubbed too
When the assistant runs in agentic mode and calls a tool that returns records (a compliance document lookup, for example), the result is deep-scanned before it goes back to the model. On top of the pattern matching above, any field whose name is a known identifier is masked by name regardless of how its value looks. That's a second line of defense, so a value never slips through just because its format was unusual.
Two places where redaction always runs
- Document indexing. When Knowledge Base documents are indexed so the assistant can search them, identifier-style fields are stripped before the text is turned into vectors. They're not stored in the search index at all.
- The public assistant. The marketing-site assistant (for prospects, before sign-in) always redacts a fixed set of fields and has no access to any tenant data. There's no company setting to turn this off.
Answers come from your own data, and only what a tool can actually reach
The in-app assistant is grounded in your company's own records, not a shared pool. Document search, which handles policy and general questions, is filtered by your company ID on every query, so retrieved context only ever comes from your own indexed documents. The assistant cites the excerpts it used as Source 1, Source 2, and so on.
Tool calls run with your permissions and your tenant context, so the assistant can't reach another company's records. The assistant's tools reach the same records the screens do: stock on hand and movements, stocktakes and waste, variance, purchase orders, invoices and payables, suppliers, recipes, compliance documents, and company administration such as settings, users, exports and webhooks. Reaching a record through a tool is not a separate grant of access, since each call is filtered by your company and runs against your own permissions. Write or action tools of any kind only run in agentic mode, which requires the use_ai_agentic permission, and every tool the assistant can use is tagged with a risk level that decides whether it needs your explicit approval before it runs.
Every interaction is logged
Each AI request writes an entry to the AI audit log. You can review these under AI Audit (requires view_ai). Each entry records:
- Feature used, provider, and model
- The prompt text as sent (already redacted) and the response text
- Input, output, and total token counts, plus latency
- Whether sensitive content was detected, and which field types were redacted
- Status of the request
Because the stored prompt is the redacted version, the audit log itself doesn't become a new copy of the raw sensitive data.
Logs are scoped to your company and can be filtered by feature, status, user, and date range.
Where keys and provider settings live
Provider API keys are encrypted at rest. In AI Settings they're shown masked (first and last characters only), and saving a masked value never overwrites the stored key. A company can use its own keys or fall back to platform-managed keys. You can also choose which provider and model your company uses. Because the provider is configurable, the assistant always presents itself as Bohari AI rather than naming the underlying model.
FAQ
Is redaction on by default? Yes. New companies start with redaction enabled and a default set of field types active. You can change the fields or turn redaction off in AI Settings, but turning it off means raw text is sent to the provider.
If I turn redaction off, what happens? Your prompts are sent to the provider unmasked. The toggle exists for cases where you trust your provider configuration, but the safe default is to leave it on.
Does redaction guarantee no sensitive data ever leaves? No automated masking is perfect. Redaction is pattern-based and conservative by design (especially for bank accounts), so unusual formats can slip through. Treat it as a strong default safeguard, not an absolute guarantee, and don't paste raw identifiers you don't need the assistant to see.
Can the assistant see another company's data? No. Document search and every tool the assistant can call are filtered by your company ID, and tools run with your own permissions.
Who can read the audit logs?
Anyone with the view_ai permission, scoped to their own company.
Does the public website assistant see my company's data? No. It runs against platform information only, always redacts a fixed set of fields, and is explicitly instructed not to claim access to any tenant data.