不代表。
这里很容易：
把两件事情：
混在一起。
Anthropic 说：
Claude Connector：
会沿用：
你在原本系统里的：
Permission。
例如：
你在 Google Drive：
本来看不到：
某一份文档。
透过 Claude：
也不能突然看到。
你在某个 Business System：
本来没有权限：
修改某笔数据。
Claude：
也不能凭空：
替你升级权限。
这很好。
但：
「AI 不会越过原有权限」
不等于：
「原有权限本来就设得刚刚好。」
问题往往不是 Claude 拿到太多
而是：
人本来就拿到太多。
想像一家：
5 人小公司。
老板：
以前为了方便。
把公司 Google Drive：
全部文件夹。
都分享给：
行政同事。
会计数据。
客户数据。
合约。
行销素材。
人资文档。
全部：
都能看。
以前：
这个人可能：
每天只开：
其中几个文件夹。
所以：
权限太大：
没有立刻出问题。
但 AI Connector 会改变「能看到」的实际意义
人：
有权限。
不代表：
每天真的会：
把 5,000 份文档：
全部搜索一次。
AI：
却很擅长：
跨很多数据：
搜索。
整理。
比对。
所以原本只是：
「理论上看得到。」
接上 AI 之后：
可能变成：
「一句话就能把很多地方一起找出来。」
这就是：
新的差别。
例如你只想做 Monday Brief
真正需要的可能只有：
上周 Sales。
Cash。
Overdue Invoice。
Pipeline。
Calendar。
但是：
如果连接帐号本来还能看到：
薪资数据。
员工文档。
私人客户合约。
甚至：
其他不相关项目。
那么：
Claude 没有越权。
但这个 Workflow：
仍然可能拥有：
比任务真正需要更大的数据范围。
所以「没有越权」和「最小权限」不是同一件事
第一句：
问的是：
AI 有没有突破系统限制？
第二句：
问的是：
这个 Workflow 到底需不需要拿到这么多？
两个：
完全不同。
Anthropic 对 Connector 的规则其实很清楚
Claude：
会继承：
每个人在 Source System：
原本的权限。
如果：
用户本来不能看到：
某个 File。
Channel。
Record。
Connector：
也不能：
替他取得。
这代表：
Claude 不会：
因为接上 Connector：
自动变成：
Admin。
但官方同时也直接提醒另一件事
当你连接一个 Service：
等于：
授权 Claude：
依照：
这个 Account Permission：
去：
Access。
甚至：
Modify。
其中的数据。
也就是：
原帐号权限：
本身就是：
第一道边界。
如果第一道边界：
太宽。
Connector：
只是：
照着它走。
例如一个共用 Google Account
这是小公司很常见的：
方便做法。
大家：
用同一个 Account。
Drive：
全部在里面。
Calendar：
全部在里面。
Email：
也很多人共用。
平常：
看起来：
很方便。
但一旦：
把这个 Account：
连给 AI。
AI 继承的：
就是：
这个共用帐号：
原本可以看到的范围。
所以不能只问：「Claude 安不安全？」
还要先问：
「我现在是用谁的帐号连？」
这个 Account：
本来能：
看到哪些 Drive？
哪些 Email？
哪些 Calendar？
哪些 Record？
哪些 Payment Data？
这些：
才真正决定：
AI 的数据边界。
第二个要看的：Connector 到底开了哪些 Action
数据权限：
是一层。
行动权限：
又是另一层。
例如：
Google Drive Connector：
可能：
可以读档。
也可能：
Move。
Share。
Trash。
Create。
同样都是：
Drive。
风险：
完全不同。
Anthropic 现在允许 Team／Enterprise 管理员再缩一层
可以把：
Connector Tool：
设置成：
Always allow。
Needs approval。
Blocked。
也可以：
把一个 Connector：
限制成：
只读。
例如：
可以让 Claude：
搜索 Email。
摘要 Email。
但是：
不能：
Send。
也可以：
让 Claude：
读 Drive。
但：
不能：
Create。
Edit。
或移动文档。
这一层非常重要
因为：
Source System Permission：
回答的是：
「这个人原本能不能做？」
Claude Connector Restriction：
则可以再回答：
「就算这个人能做，我要不要让 AI 做？」
例如：
老板自己：
在 QuickBooks：
当然有完整权限。
但：
Monday Brief：
只需要：
读。
那 AI：
根本不需要：
拿到：
Write。
这就是比较成熟的 AI 权限设计
不是：
照抄：
人的全部能力。
而是：
从人的权限里：
再切出：
这个 Workflow 真正需要的部分。
人：
可以做十件事。
AI 这次：
只需要：
两件。
那就：
只给两件。
第三个要看的：Approval 并不等于 Data Access 限制
这也很容易搞混。
Approval：
通常控制的是：
Action。
例如：
Send。
Delete。
Move。
Write。
真正运行以前：
先问你。
但：
它能读哪些数据
往往是：
另一层 Permission。
如果 AI：
本来就有权：
读取某份文档。
你不能因为：
所有 Write Action：
都设成：
Needs approval。
就理解成：
读取范围：
也跟着缩小。
没有。
所以「唯读」也不是完全没有风险
唯读：
确实比：
可写。
安全很多。
因为：
AI 不能：
修改。
删除。
寄出。
但是：
如果它能：
读到：
不必要的敏感数据。
仍然代表：
这个 Workflow：
拿得太多。
例如：
做 Marketing Report。
根本不需要：
员工薪资。
就不要：
让这个 Workflow：
使用一个可以看到：
全部 HR Data：
的 Account。
第四个要看：AI 可以跨 Source 组合数据
这也是：
传统 Permission Design：
碰到 AI 后：
很值得重新检查的一点。
一份数据：
单独看：
可能：
没什么。
例如：
Calendar：
知道：
客户姓名。
CRM：
知道：
交易状态。
Email：
知道：
谈判内容。
Accounting：
知道：
实际金额。
AI：
最擅长：
把：
不同 Source：
拼在一起。
每个系统都没有「越权」
但是：
组合起来：
信息密度：
可能变得非常高。
这就叫：
Data Aggregation Risk。
不用想得：
太学术。
简单说：
就是：
一个人以前要开四套系统才能拼出的东西，AI 现在一句话就能拼出来。
所以：
Connector 越多：
越应该问：
是不是：
真的都需要一起开。
第五个要看：Shared Folder 本身可能早就权限失控
很多公司的：
Google Drive。
Notion。
Slack。
用了：
三年。
五年。
人员：
进进出出。
文件夹：
一直 Share。
最后：
没有人记得：
谁还看得到什么。
这时：
Claude 如果：
忠实继承既有权限。
反而可能：
把原本看不见的：
Permission Debt：
暴露出来。
也就是问题不是 AI 创造的
AI 只是：
让原本：
很少被使用的：
过度权限。
突然：
变得更容易被真正用到。
所以：
导入 AI Connector：
反而是一个好机会：
重新做一次：
Permission Cleanup。
可以先问三个非常简单的问题
第一个：
这个人真的需要看到这些吗？
第二个：
这个 Workflow 真的需要看到这些吗？
第三个：
AI 真的需要做出修改吗？
三个问题：
一层一层往下缩。
例如做 Monday Brief
人：
可能是老板。
本来：
什么都看得到。
没问题。
但：
Workflow：
真正只需要：
Sales。
Cash。
Pipeline。
Invoice。
Calendar。
那 Claude：
就只使用：
相关 Connector。
如果：
只需要读：
就不要：
开 Write。
这就叫：
Least Privilege。
如果是 Proposal Workflow
可能需要：
CRM。
过去 Proposal。
Brand Asset。
Pricing Rule。
Meeting Note。
但：
可能完全不需要：
Payroll。
Bank Account。
Employee File。
那就：
不要因为：
「反正老板都看得到」
全部一起接。
如果是 Marketing Workflow
需要：
Campaign Data。
Sales Trend。
Social Content。
Customer Review。
但：
可能不需要：
正式合约。
薪资。
完整银行交易。
同样：
切开。
所以权限要跟着「工作」走
而不是：
跟着：
「Claude 很方便，所以全部打开。」
每个 Workflow：
应该有自己的：
Data Boundary。
Tool Boundary。
Action Boundary。
甚至同一个人，不同 Workflow 都可以不同
同一位老板：
做 Weekly Brief：
只读。
做 Proposal：
可以准备文档。
做 Payroll：
可以读数据和 Stage。
真正 Submit：
人来。
做 Marketing：
可以 Draft。
真正 Publish：
先 Approval。
这比：
「这个人是 Owner，所以 Claude 全开」
合理很多。
Cowork 本身也有不同 Approval Mode
Anthropic 现在提供：
Manual。
Auto。
Skip。
不同模式。
但最重要的事情不是：
模式名称。
而是：
就算你使用：
比较自动的 Mode。
真正被设置成：
Blocked：
的 Connector Action：
仍然不应该因为：
模式改了：
突然开放。
Team／Enterprise 还可以由管理员设更高一层限制
例如：
组织直接规定：
某个 Connector：
Write：
一定要 Approval。
或者：
完全 Block。
用户：
不能自己：
把它打开。
这就是：
把安全边界：
从：
「提醒用户小心」
变成：
真正的：
System Control。
小公司没有 Enterprise 管理员怎么办？
原则一样。
只是：
变成：
老板自己做。
不要：
拿公司最有权限的 Account：
连所有 Connector。
再希望：
Prompt：
帮你限制。
Prompt 可以说：
「不要看 HR。」
但如果：
技术权限：
本来就完全打开。
那只是：
Instruction。
不是：
真正 Boundary。
能在系统层切掉，就不要只靠文字提醒
例如：
不需要 Send：
就不要开 Send。
不需要 Write：
就设 Read-only。
不需要某个 Connector：
就不要 Connect。
不用的 Connector：
就 Disconnect。
真正敏感的数据：
如果：
Workflow 根本不需要：
就让：
Account 本身：
也没有 Access。
这比写十行「不要做什么」更可靠
因为：
Prompt：
是：
行为要求。
Permission：
是：
能力限制。
AI 如果：
没有：
Delete Tool。
它就：
不能 Delete。
这远比：
Tool 有开。
然后：
Prompt 写：
「拜托不要 Delete」
强。
所以「Claude 会继承原权限」其实是一个好消息
代表：
它不应该：
自动突破：
Source System：
既有 Access Control。
但：
这不是：
权限治理的终点。
真正成熟的问法：
应该再往前一步。
不是：
「Claude 有没有越权？」
而是：
「人本来的权限有没有过度？」
以及：
「这个 AI Workflow 有没有必要继承这么多？」
最后可以把权限检查缩成三层
第一层：
Human Permission。
这个人：
在原系统：
本来看得到什么？
第二层：
Workflow Need。
这次工作：
真正需要什么？
第三层：
AI Action。
Claude：
需要：
Read？
Draft？
Write？
Send？
Delete？
Pay？
三层：
一层一层缩。
最好的结果不是「AI 和人权限完全一样」
而是：
AI 比人更窄。
因为：
人可能需要：
处理很多不同工作。
一个 Agent Workflow：
通常只处理：
很窄的一件事。
既然：
任务比较窄。
权限：
也应该：
比较窄。
所以今天答案就是
Claude：
沿用 QuickBooks。
Drive。
CRM。
或其他 Connector：
既有权限。
的确可以防止：
AI 无中生有地：
取得你本来没有的 Access。
但是：
它不能替你修好原本就过大的权限。
如果：
人的 Account：
本来可以看太多。
AI：
也可能：
跟着看到太多。
真正要做的是：
先把：
人的权限。
Workflow 需要。
AI Action。
三层：
分开检查。
不要只问：
「AI 有没有越权？」
还要问：
「这个权限一开始到底该不该存在？」
今天，和 AI 一起进步一点。
每天学会一个 AI 技巧。
每天节省一点时间。
每天提升一点能力。
SasaDaily，陪你一起成长。
推荐阅读
AI 一分钟教学｜2026/09/01：OpenClaw 跑固定工作前，先写「能做、一定停、凭证怎么拿」最小权限卡
AI 快问快答｜2026/09/03：Workspace Studio 已经设置 Approval，就代表所有高风险动作一定会停下来吗？
AI 快问快答｜2026/09/11：Qodo Review 没有 Finding，就代表可以放心 Merge／Deploy 吗？
