Which collection should a support assistant consult?
The fictional support policy grants the assistant the product handbook and approved troubleshooting notes for internal support questions. It does not grant every company folder. Open the policy excerpt to inspect the assigned collection and purpose, then compare the separate out-of-scope acquisition example. This demonstrates task scope rather than a company-wide permission grant or a live policy configuration.
Support assistant scope policy
Source excerpt · Support assistant scope policy
Permitted collection: product handbook and approved troubleshooting notes. Purpose: answer internal support questions.
An AI governance platform needs a clearly defined job
An AI governance platform helps an organization manage how AI uses its information. In Brain’s scope, governance centers on connected knowledge, workspace access and reviewable evidence; it does not replace every organizational AI risk control.
An AI governance platform can cover several different jobs. Brain focuses on access to knowledge: which people and agents can consult which information, under which rules, and what record describes the activity. That scope is different from maintaining a model inventory, evaluating bias or approving a high-risk AI system. Defining the job first makes it easier to assess the product against a real governance requirement.
Start with identity. A request should belong to a person or a particular agent rather than an anonymous shared credential. Then define scope: the approved collections, folders or sources that identity needs for its task. A support agent answering product questions has a different purpose from an assistant preparing a finance review. Giving both the same broad collection makes the policy harder to explain and the consequences of a mistake larger.
Policy turns the scope into a decision at the access boundary. A written rule saying “use only approved documents” is useful guidance, but a connected workflow also needs settings that limit what can be retrieved. Use a representative allowed question and an out-of-scope question to test the boundary. When a source or membership changes, repeat the test instead of assuming the original result still describes the new configuration.
Records make those decisions available for review. Brain’s activity records can help reviewers examine access decisions. They are not a guarantee that stored records exclude content. Retain the relevant policy state and interpret the record in context. Such evidence can support internal oversight and record-keeping work; it is one part of a broader program, alongside legal classification, risk management, human oversight and the obligations that apply to your specific AI use.
Connect. Ask. Govern.
From scattered documents to a shared answer
01
Connect the agent’s approved collection
Give the support handbook and troubleshooting notes a clear owner. Record why the support assistant needs them and which folders, such as acquisition planning, fall outside its assigned purpose.
02
Ask within and beyond the scope
Use the identified assistant to ask a permitted support question, then test an out-of-scope request with synthetic material. Compare the returned source evidence and access decision rather than relying on a policy label.
03
Govern changes with reviewable evidence
Narrow the source scope, repeat a fresh request and inspect the activity record with the applicable policy state. Keep the review tied to the actual configuration and decide which evidence your wider program needs.
See the idea in action
ai governance platform: questions with evidence
Fictional examples. These interactions do not query your Brain or test real permissions.
The fictional support policy grants the assistant the product handbook and approved troubleshooting notes for internal support questions. It does not grant every company folder. Open the policy excerpt to inspect the assigned collection and purpose, then compare the separate out-of-scope acquisition example. This demonstrates task scope rather than a company-wide permission grant or a live policy configuration.
Support assistant scope policy
Permitted collection: product handbook and approved troubleshooting notes. Purpose: answer internal support questions.
The fictional acquisition planning folder is outside the support assistant’s assigned collection. Under limited access, both the answer and source excerpt are withheld. Naming a document in a question does not give the asker a right to retrieve it. A real pilot should test that boundary using approved synthetic material and the actual agent identity.
Restricted acquisition planning folder
Private project folder: preliminary acquisition assessment and negotiation notes.
The fictional access summary identifies the support assistant, the handbook object and the allowed read. It contains no handbook quotation. A reviewer can compare that activity with the assigned policy and ask whether it matches the task. Actual exports and record coverage must be evaluated in the product rather than inferred from this illustration.
In the fictional before record, support-assistant can read archived troubleshooting notes under scope v2. The support governance owner removes that archive in v3. The next fresh request for the same archived object is denied, while the current handbook remains allowed. These paired synthetic records illustrate the outcome; this page changes no live policy and does not retract previously generated answers.
Fictional support policy: before change
2026-09-24T10:00Z — policy owner: support governance lead. Active scope support-collection-v2: current handbook and archived troubleshooting notes. Fresh request by support-assistant for archived-troubleshooting: allowed.
Fictional support policy: after change
2026-09-24T10:05Z — support governance lead activates support-collection-v3: current handbook only. 2026-09-24T10:06Z — fresh request by support-assistant for archived-troubleshooting: denied under v3. Current-handbook request: allowed. Earlier outputs remain separately reviewable.
Open a question, then inspect its source excerpts.
Brain is a knowledge layer reached through MCP, the Model Context Protocol. Claude, Cursor and Codex are examples of compatible clients in the existing product. Client support and setup differ, so check the current connection instructions rather than assuming every assistant has the same capabilities.
The current public setup describes Google Drive and Notion as connected sources, alongside documents you choose to add. Start with a focused collection and inspect the actual connection screen for availability. A tool appearing in a roadmap or illustration does not mean its connector is ready for your account.
Google Drive
Connect the documents your workspace needs.
Notion
Bring approved pages into a shared knowledge layer.
Your documents
Add a focused set of knowledge you own.
Keep access intentional
AI agent governance connects policy with an access review
AI data governance needs ownership of the source as well as a boundary for the asker. Review the identity, collection scope, access outcome and relevant policy state together. An AI audit log or audit trail can contribute evidence within its recorded coverage; it does not replace all AI compliance work. Compare AI governance tools by the responsibilities they actually cover, including model evaluation and legal classification where relevant. Query records may store query text, and activity metadata may contain content. Review these storage categories separately from actor, object, action and outcome fields. The content-free examples on this page do not establish that all stored records are content-free.
Fictional content-blind access record
Actor
Example policy reviewer
Object
demo-object-01
Action
Read
Scope rule
Included in the example collection
Outcome
Allowed
No document content appears in this illustration. It is not a record from your account or proof of live enforcement.
A support assistant may need one approved troubleshooting passage, rather than an archive of unrelated company material. Measure the input supplied for representative permitted tasks and check answer quality. Governance should not be weakened to chase a smaller token count: retain necessary exceptions, source evidence and the cost of retrieval, model outputs and Brain when evaluating the workflow.
Establishes approved purposes, ownership and responsibilities. It needs practical configuration, training and review to become part of a workflow. Keep the policy, and connect its access rules to controls that can be tested.
Model governance platforms
May cover model inventories, evaluation, approval and lifecycle risks. Those are valuable responsibilities with a different emphasis from source access. A knowledge-access layer can complement that program rather than replace all model governance.
DLP and endpoint controls
Can address sensitive-data movement and activity at other boundaries. Their coverage depends on deployment and configuration. Evaluate them alongside source scope, because controlling an endpoint and deciding which document an agent may retrieve are related but distinct jobs.
Brain knowledge-access governance
Focuses on people and agent identities, approved source scope, access policy and activity records. Test the workflow against your requirements and retain the supporting evidence. It does not replace legal classification or every obligation of a wider AI governance program.
ai governance platform: frequently asked questions
What is an AI governance platform?
An AI governance platform helps an organization manage defined controls around AI use. Different products emphasize different responsibilities. Brain focuses on knowledge access: people and agent identity, source scope, policy and activity records. Establish which governance requirement you need to satisfy before comparing products, rather than treating one broad label as a complete capability list.
What is the difference between AI access governance and model governance?
Access governance concerns who or what can retrieve particular knowledge and the evidence of those decisions. Model governance concerns responsibilities such as model inventories, evaluation, approval and lifecycle oversight. Organizations may need both. Brain’s knowledge-access scope can support a broader program without claiming to replace bias testing, model validation or every regulatory obligation.
How does Brain enforce AI policy?
Brain’s published access model connects people and agent identities with permitted source scope and governance controls. Translate a written requirement into a specific collection and access setting, then test allowed and out-of-scope requests. Review the actual product behavior after changes; a policy statement or fictional demonstration alone is not proof of enforcement in your environment.
Can we govern AI agents as well as people?
Brain’s published model treats agents as identifiable participants with assigned knowledge access, rather than relying only on a shared human credential. Give each agent a task-appropriate scope and review its activity. Verify the controls available for your client and account, including access changes and credential retirement, before expanding a pilot to more agents.
What does the audit record prove?
A record can provide evidence of a recorded activity and its context, subject to the actual fields, coverage and integrity checks available. It does not prove every possible downstream action or automatically establish regulatory compliance. Inspect a known request and relevant policy state, then assess whether that evidence meets your investigation or oversight requirement.
How does Brain support EU AI Act record-keeping?
Activity records can contribute evidence about knowledge access within an AI workflow. The EU AI Act addresses record-keeping for covered high-risk systems, but an access log alone does not satisfy every applicable requirement. Determine your system’s classification, role and obligations with qualified advice, and assess the evidence alongside the rest of your governance program.
Does access governance make a deployment GDPR compliant?
Access limits and records can support privacy controls, but compliance also depends on purpose, data categories, legal basis, contracts and the services processing the data. Review Brain’s current privacy policy and the terms applying to your deployment. Connecting approved knowledge does not automatically authorize every subsequent use of personal information or international transfer.
Turn an access rule into a testable workflow
Name one agent, choose its approved collection and compare an allowed request with an out-of-scope request. Review the resulting evidence before extending the policy to the next team.
