一个咨询师同时挂靠三家机构接单，如果账号权限没做到机构级隔离，泄露的不是单条记录，而是一整串本不该跨机构流动的信息。
兼职咨询师和全职员工不同，一个人的账号可能横跨社会咨询机构、企业 EAP、学校辅导中心三种场景。系统若只按“这个咨询师能看他负责的来访”来做权限，忽略了“这些来访分属不同机构、彼此的数据不能互相看见”，隔离就出现了缺口。
隔离失败会泄露哪几类东西
第一类是来访身份跨机构暴露：A 机构的来访姓名、联系方式、预约记录，在咨询师切到 B 机构界面时仍然可见。第二类是历史测评档案串场——同一咨询师在 A 机构给来访做的量表结果，被带进 B 机构的会谈参考里，来访从未授权这种跨机构使用。第三类更重，是名单级泄露：咨询师借由一个账号能列出某机构的全部来访清单，等于把机构的客户名单暴露给了它的兼职合作方。此外，写给某机构内部督导的记录、机构间的转介说明，本应只在机构内可见，隔离失效后也会被跨场景读到。
这些泄露有一个共同点：来访当初只向某一家机构授权，数据却顺着“同一个咨询师账号”流到了别处。授权范围和数据可见范围对不上，就是隔离失败的本质。
账号和权限该怎么切
正确的模型是把“人”和“人在某机构的身份”分开。一个咨询师是一个自然人账号，但他在每家机构各有一份独立的成员身份，数据权限绑定在“机构加成员身份”这一层，而不是绑定在自然人上。切到 A 机构时，只能看到 A 机构授予他的来访和量表；切到 B 机构，A 的一切都不可见。橙星云这类多机构平台在设计权限时默认按机构划数据边界，兼职咨询师跨机构也各自独立，一个身份看不到另一个身份的来访、档案和名单。
除了读取隔离，还要管操作和留痕。同一账号在不同机构的每次查看、导出都应按机构分别记日志，机构管理员只能审计本机构范围内这个咨询师的行为。结束合作时，撤销的是他在该机构的成员身份，而不是删掉整个自然人账号，以免影响他在其他机构的正常工作。
值得留意的是，兼职咨询师的隔离风险不在功能缺失，而在建模时把“一个咨询师”当成了“一个数据主体”。只要权限还挂在自然人身上，无论界面怎么切，底层数据都是通的。把隔离下沉到机构成员身份这一层，跨机构泄露才真正被堵在数据边界上，而不是靠界面藏一藏。