- Building a company AI brain is six steps: connect sources, keep permissions, redact sensitive fields, open an MCP endpoint for agents, log every access, then expand from read-only.
- Do not copy your data into a new index. Keep it where it lives so existing permissions stay intact; copying is the most common way enterprise AI knowledge base projects leak.
- Govern agents like people: the same permission checks, plus limits, human-in-the-loop, and a kill switch, because agents act faster and at larger scale.
- Proof is the deliverable. A content-blind, tamper-evident audit, optionally anchored on-chain, turns 'trust us' into evidence security can verify.
- You can stand up a working brain with one command: npx @aivm/brain init, free to start, with your own model key.
To build a secure company AI brain, connect your existing sources without copying the data, keep each source's permissions intact, redact sensitive fields rather than whole files, expose an MCP endpoint so AI agents can query it under the same rules, and log every access in a tamper-evident, content-blind record. Start read-only, prove it is safe, then grant write-back and agent autonomy.
What you need before you build a company AI brain
Before building a company AI brain, you need three things: a list of the sources that hold your knowledge (Slack, Google Drive, GitHub, Notion and the like), a single sign-on identity so the brain knows who is asking, and a model key. You bring your own model, so any model (Claude, OpenAI, Gemini, or your own) works, and nothing you connect trains it.
Identity is the foundation everything else rests on. AIVM Brain uses WorkOS single sign-on with user sync, so the people and groups in your directory map straight into the brain, and each company gets its own isolated Postgres tenant. If you want the concept before the procedure, the canonical explainer of what an AI brain is covers it first.
Step 1: Connect your sources without copying the data
Connect the brain to the tools where your knowledge already lives instead of bulk-exporting everything into a new store. AIVM Brain connects to Slack, GitHub, Google Drive, Notion, Box, Confluence, Salesforce, and Telegram with their permissions intact. Copying data into a fresh index is the single most common way an enterprise AI knowledge base leaks, because the copy loses the access rules that protected the original.
The safest place for a document is where it already sits, with the sharing rules it already has. Connecting rather than copying also means the brain stays current: when a file's permissions change at the source, the brain respects the new rules on the next query instead of serving a stale snapshot.
Step 2: Keep each source's permissions intact
Map each source's existing access rules into the brain so the answer respects them. A trustworthy brain checks the asker's identity against those rules (RBAC or ABAC) before it retrieves anything, so a confidential file never lands in an unauthorized person's or agent's answer. This permission-aware retrieval is the difference between a brain you can turn on and one that stalls in security review.
This is AI access governance in practice: enforcement happens per request, per identity, at the moment the brain retrieves knowledge to answer. Relevance still ranks the results, but only within the set the requester is already cleared to read. Permission-aware retrieval, sometimes called governed RAG, is what keeps a single answer box from rebuilding your oversharing problem inside the AI.
Step 3: Redact sensitive fields, not whole files
Access is rarely all-or-nothing. Instead of blocking an entire document, redact only the sensitive part, one salary column or one unreleased number, and leave the rest answerable. Field-level redaction keeps the brain genuinely useful while keeping secrets secret, which is what stops people from routing around it.
Blocking whole files is a hidden failure mode. When a brain refuses an otherwise useful document because of one sensitive line, the team copies the data somewhere ungoverned to get their work done, and you have lost the control you were trying to keep. Withholding the single field that needs protecting, and serving the rest, is what makes a secure brain something people actually use.
Step 4: Give AI agents a governed MCP endpoint
Expose the brain over an MCP endpoint so AI agents can query it directly, and govern those agents exactly like people: the same permission checks, plus limits, human-in-the-loop on sensitive actions, and a kill switch. Agents act faster and at larger scale than people, so the governance has to cover them too.
Give each agent an identity, not a shared key. ERC-8004, an Ethereum standard for trustless agent identity, lets each agent carry a verifiable identity the brain can resolve and check, so you know which agent asked for what. With identity, permissions, and a kill switch in place, letting agents read the brain is a controlled step rather than a leap of faith.
Step 5: Log every access so it is provable
Write every question, retrieval, and answer to a tamper-evident, content-blind audit log. Content-blind means the record proves what happened without storing the content itself, so it is safe to share with auditors and no vendor can read your data through it. AIVM Brain can verify this log offline and optionally anchor on-chain a record of exactly what the model answered over.
Provenance rounds out the proof. AIVM Brain carries C2PA content provenance, the standard published at spec.c2pa.org for recording where content came from, so each source and answer has a verifiable origin. Together, a content-blind audit and provenance turn the question 'can you prove nothing leaked' into 'yes, here is the record', which is the answer security and legal are actually waiting for.
Step 6: Start read-only, then expand
Turn the brain on read-only first: let people and agents ask questions but not change anything. Once the permission model and audit hold up in practice, grant write-back and broader agent autonomy. This order earns trust before it grants power, and it gives security a clean before-and-after to review.
Build in deletion from the start. AIVM Brain supports provable right-to-be-forgotten, so you can delete a record, propagate the removal across indexes and agents, and produce proof it is gone. That is the realistic answer to GDPR Article 17 at the knowledge layer, where erasing a record is tractable even though unlearning it from a trained model is not.
How do you prove what the AI accessed, and how long does this take?
You prove access with the audit log: a tamper-evident, independently verifiable record of every question, document retrieved, and agent involved, optionally anchored on-chain so no party can alter it after the fact. Setup is fast: npx @aivm/brain init stands up a working brain, and it is free to start. The slow part is usually deciding policy, not installing software.
Plan the schedule around people, not code. Connecting sources and turning on governance takes minutes per connector; agreeing on who should see what, and getting security comfortable, is where the real time goes. Starting read-only with full audit from day one shortens that conversation, because every claim about access comes with a record anyone can check.