--- author: OOMOL author_url: https://oomol.com/zh-cn/about/ datePublished: 2026-10-01 title: AI 越懂你，越能帮到你：让 Agent 在安全的边界内变聪明 description: 充分的个人与业务信息，让 Agent 提供更有价值的服务和咨询。了解企业智能化需要怎样的数据，以及 OOMOL 的数据保护、身份权限、合规与开源实践。 lang: zh-CN canonical_url: https://oomol.com/zh-cn/blog/agent-data-security/ markdown_url: https://oomol.com/zh-cn/blog/agent-data-security.md --- ![AI 助理连接个人与企业数据，外部保护与内部身份权限共同守住数据边界](/blog/agent-data-security/zh-cn-cover.webp) **Agent 越了解你，越能给出有价值的建议、提供贴合需要的服务，也会在实际工作中显得越聪明。** 从 Meta 的 Muse 到 OpenAI 的 dot，AI 助理开始记住用户偏好、连接应用、持续处理任务。[Meta Muse 官方介绍](https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/) · [OpenAI dots 官方介绍](https://openai.com/index/introducing-dots/) 模型再强，也需要知道你的目标、处境和限制。个人助理需要了解日历、邮件、沟通记录和生活偏好；企业助理需要结合 ERP、CRM、OA 中的业务数据，以及外部市场信息，才能像熟悉业务的咨询师一样给出意见，或在授权范围内代理做事。 让 Agent 获得这些信息，是智能化的前提。怎样保护这些信息，则决定了我们能否放心地把工作交给它。 ## 信息充分，Agent 才能考虑周全 同样是安排出差，知道目的地的助理，可以推荐酒店；知道会议时间、客户地址、你的日历和出行偏好的助理，才能选择合适的航班、检查行程冲突，提醒你准备客户材料。 它考虑得更周全，是因为它掌握了与你有关的信息。 企业里的问题更复杂。一位运营负责人问：“下个月应该重点推广哪些产品？” Agent 需要知道 CRM 中的客户需求、ERP 中的库存和交付能力、OA 中的审批要求，还要结合销量、回款和外部市场变化。只看需求，可能推荐供应跟不上的产品；只看库存，可能错过新的市场机会；只看销量，可能忽略利润和回款压力。 **Agent 需要足够的细节，也需要宏观的业务视角。** 它必须理解客户、供应、财务和市场之间的关系，才能判断一条建议是否适合这家公司。 这里的“充分”，包括准确、及时的业务数据，也包括历史背景、组织目标和决策约束。这些信息共同帮助 Agent 理解业务，模型的推理能力才能用得上。 ```text 目标、偏好、历史背景与业务约束 ＋ ERP 库存与交付 · CRM 客户需求 · OA 流程审批 ＋ 行业趋势与市场信息 │ 按身份与任务授权访问 ↓ Agent 关联信息，理解业务全局 ↓ 更有依据的咨询、更周全的服务与行动 ``` *图：Agent 如何利用上下文提供服务。模型能力与数据质量都会影响判断，重要决策仍需业务人员核对。* ## 不推进智能化，企业会面临什么 一家企业用 Agent 持续汇总客户反馈、核对库存、跟踪市场变化，另一家仍靠员工逐个系统查资料、整理报表、传递信息。随着前者把这些工作做得更快、更稳定，两者在响应速度和协作成本上的差距就会拉大。 如果竞争对手不断提高效率，自己长期停留在原有工作方式中，就会越来越难跟上。差距积累到客户体验、经营成本和决策速度上，企业可能失去竞争力，甚至被市场淘汰。 企业需要推进智能化，也需要解决数据接入带来的安全问题。可以从客户沟通准备、库存异常分析或市场简报这样的具体任务开始，让 Agent 获得完成任务所需的信息，再根据实际效果扩大使用范围。 ## 外部安全：保护数据和访问凭据 Agent 接入业务系统后，安全要同时覆盖外部保护和内部权限。 外部保护首先要防止未经授权的访问。需要保护的既有业务数据，也有 OAuth Token、API Key 等凭据。凭据泄露，可能让攻击者持续进入原系统；数据进入模型上下文、任务记录或日志以后，也需要妥善处理。 OOMOL 云端采用**信封加密**保护敏感数据：用数据加密密钥将数据变成密文，再用另一层密钥保护这把数据加密密钥。应用调用按授权范围执行，成员无需接触账号密码或原始 Token。[安全与合规](/zh-cn/security/) 企业接入时，还需要确认数据会经过哪些模型和服务、保存多久，以及如何撤回授权。这些安排决定了数据离开原系统后，仍能受到怎样的保护。 ## 内部安全：权限必须与身份绑定 数据留在企业内部，同样可能泄露。 销售可以查看自己负责的客户，不代表可以查看全公司的薪酬；运营可以查询库存，不代表可以修改采购审批。管理者使用过的财务资料，也不能因为进入了共享助理的记忆，就让其他成员查到。 **谁能读取哪些数据、执行哪些操作，必须与身份绑定，并由系统检查。** 对访问范围的检查应当在数据进入模型之前完成。 OOMOL 的管理员可以配置每个连接允许执行的操作，并指定哪些成员可以使用。同一个应用账号可以创建多个连接，为不同成员分配不同的操作范围。最终权限还受应用本身的授权和调用身份限制。[权限控制说明](/zh-cn/docs/access-control/) 连接层控制连接和操作权限；具体到某个客户、某个部门的数据，还需要结合原系统的权限与应用实现。助理产品和工作流也要管好共享记忆与结果接收者。例如，一个成员有权读取财务报告，并不意味着他可以让 Agent 把报告发到全员群。 ## 合规保障：安全评估与个人数据保护 OOMOL 已通过 **TAC Security 的 CASA/ESOF 安全评估**，并遵循 **GDPR 的个人数据保护要求**。隐私政策说明了数据处理方式、用户权利和隐私请求渠道。[OOMOL 安全与合规](/zh-cn/security/) · [隐私政策](/zh-cn/privacy/) CASA/ESOF 提供相应范围内的应用安全评估；GDPR 规定个人数据的处理要求，包括处理目的、数据最小化和个人权利保障。[TAC Security 评估说明](https://tacsecurity.com/esof-appsec-ada-casa-faqs-2/) · [EDPB 数据保护指南](https://www.edpb.europa.eu/sme/be-compliant/be-compliant_en) 这些要求要落实到开发和运营中：明确数据用途与保留方式，只处理所需数据，让用户能够管理授权、提出隐私请求。企业选择服务时，也可以据此核对评估范围、数据流向和双方责任。 ## 开源监督：让关键实现可以被检查 OOMOL 维护开源连接网关 **OpenConnector**，并开放 **oo CLI** 和 **Connector SDK** 的源码。OpenConnector 采用 Apache 2.0 许可证，oo CLI 与 Connector SDK 的公开仓库采用 MIT 许可证。 开发者可以检查调用怎样发出、连接怎样执行、权限在哪里检查，发现问题后提出 issue 或参与修复。 开放源码让社区有机会审查实现，也让企业可以直接检查关键代码。实际部署是否与源码一致、配置是否符合安全要求，仍需要核对。 我们希望让使用者能看见关键实现、追踪问题和修复过程，以这种透明的方式建立信任。 [OpenConnector 源码](https://github.com/oomol-lab/open-connector) · [oo CLI 源码](https://github.com/oomol-lab/oo-cli) · [Connector SDK 源码](https://github.com/oomol-lab/connector-sdk) ## 从一个任务开始 选一个你希望 Agent 接手的任务，列出它需要的信息、可以执行的操作，以及谁能看到结果。接入相关系统、配置权限，再检查它交付的工作是否有用。 随着任务深入，可以补充它缺少的背景和跨系统信息，同时检查新增的数据访问与操作权限。OOMOL 通过加密、访问控制、安全评估和关键组件开源，支持这个过程，让个人和企业能更放心地使用 Agent。 [了解 OOMOL 的安全与合规](/zh-cn/security/) · [配置连接权限](/zh-cn/docs/access-control/)