內部知識助理的唯讀權限只是審查起點

Read-only sounds safe. For an internal knowledge assistant, it is a good start, not an answer.

Here is a hypothetical example, not a client story. Say a team connects an assistant to its shared wiki and ticket history. The goal is simple: new staff ask how a process works and get a short answer with sources. The connection is read-only. Nothing can be edited or deleted.

Does that settle the question? Not quite.

What read access still allows

Read access controls what the tool can change. It says nothing about what the tool can see, or who gets to see it through the tool.

Three things are worth a look:

• Whose view is it? If one service account does the reading, every user inherits what that account can see. A new hire may get answers drawn from pages they could never open themselves.
• What comes back? A summary, a snippet or a citation can carry content from a page the person was never meant to read.
• Where does it go next? Answers get pasted into chats, tickets and emails. A read can turn into a copy.

None of this is exotic. It is the ordinary gap between "can the tool write" and "should this person see this."

A small test you can run

Pick one bounded workflow. A lookup that answers "how do we handle a refund exception?" is a good size.

1. Sign in as a user with narrow access.
2. Ask questions that pages outside their access would answer well.
3. Read the sources in each answer, not just the answer text.
4. Check what the logs record: who asked, what was retrieved, what was returned.

If the answer quotes something that user could not open directly, the permissions are not being applied where the assistant searches. That is worth fixing before anyone relies on it.

If the workflow uses MCP

Some assistants reach their data through MCP servers. If yours does, the same questions apply to each server: which credential it uses, which tools it exposes, and what scope each tool carries. Not every workflow uses MCP, and not every team needs a formal audit. Start by writing down what the assistant can reach and under whose identity.

The handoff

Whoever owns the workflow should get one page. It lists what the assistant reads, which identity it uses, what the test showed and what to check again when the content changes.

Non-regulated work still carries privacy and security duties. Internal pages hold salaries, customer names and unfinished plans. "Read-only" is a useful property. It just shouldn't be the last question anyone asks.

This is the kind of check we review for one workflow at a time.

I'm Jonathan Melton. I run FusionAL, focused on reviewing and integrating lower-risk internal AI workflows, one bounded workflow at a time.