了解更多关于 Well-Architected Trust → Agentic Enterprise Trust
客服人员身份和运行用户
模式
| 何处查看 | 好样的 |
|---|---|
| Agentforce | 客服人员配置 | ✅ 创建集成用户 "Agent_Product_Support"，权限集授予对个案/产品的读取权限、对 Knowledge 文章的访问权限以及仅用于个案更新的特定操作 |
| Agentforce | 客服人员配置 | ✅ 为运行用户配置客服人员定义范围所需的最小权限 |
| 平台 | 权限集 | ✅ 为客服人员上下文创建专门构建的集成用户，并授予权限集，准确提供客服人员的需求 |
| 平台 | Event Monitoring | ✅ 部署后，使用 Event Monitoring 识别在运行时从未行使的授予权限，并将其删除；设置审计跟踪记录配置更改（授予和撤销），而不是实际使用的权限 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| Agentforce | 客服人员配置 | 将系统管理员分配为运行用户，因为它“刚刚有效”，并避免测试期间的权限错误 |
| 平台 | 组织 | 允许客服人员保留开发期间授予的广泛权限集，而无需部署后审核 |
子代理和操作授权
模式
| 何处查看 | 好样的 |
|---|---|
| Agentforce | Agent Builder | ✅ 将客服人员生成器中的子客服人员和操作配置视为权限边界，而不仅仅是路由 — 如果操作未分配到子客服人员，客服人员无法调用它 |
| Agentforce | Agent Builder | ✅ 移除子客服人员显示客服人员不需要的功能（回答产品问题的客服人员不应具有记录修改、电子邮件发送或范围中的流调用），并在责任变更时查看子客服人员范围 |
| 平台 | Apex | ✅ 验证客服人员操作集中的每个 Apex 操作是否与共享或继承共享一起使用，除非系统上下文经过深思熟虑并有记录，因此运行用户仍保持安全边界 |
| Agentforce | 操作 | ✅ 在客服人员处理前，根据模式验证工具输出，将每个工具响应视为不可信输入 |
| Agentforce | 操作 | ✅ 将工具参数约束到允许的值范围（例如，验证发送电子邮件操作的收件人域），而不是让客服人员对不可信数据进行推理来确定它们 |
| Agentforce | 操作 | ✅ 不仅在客服人员配置中，还在工具实施层强制执行工具级权限检查，因此功能在执行前会验证其调用上下文 |
| Agentforce | 操作 | ✅ 对客服人员操作中的所有外部标注使用命名凭据 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| Agentforce | Agent Builder | 将公开记录修改、电子邮件发送或流调用的子客服人员留在仅用于回答产品问题的客服人员上 |
| Agentforce | Agent Builder | ⚠ 将客服人员配置视为仅路由，而不识别列出的任何内容是否可通过即时操作访问，即使客服人员并非设计使用的功能 |
| 平台 | Apex | 添加在系统模式下运行的自定义 Apex 操作（不共享），绕过运行用户的字段级安全性和共享规则，而不进行有意设计 |
| Agentforce | 操作 | 将工具响应作为可信输入处理，无需模式验证，允许格式错误或注入的数据到达客服人员推理 |
多客服人员权限链
模式
| 何处查看 | 好样的 |
|---|---|
| Agentforce | 客服人员配置 | ✅ 文档权限链：订单管理器（读订单、写订单状态）→库存专家（读/写库存）→发货专家（创建发货）。验证用户上下文是否允许所有下游操作 |
| Agentforce | 客服人员配置 | ✅ 部署前映射完整编配链的有效权限 |
| Agentforce | 客服人员配置 | ✅ 设计整个工作流的权限边界，而不仅仅是单个客服人员 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| Agentforce | 客服人员配置 | 允许具有有限权限的编配员通过修改所有数据调用专家，绕过编配员的限制 |
| Agentforce | 客服人员配置 | 评估单个客服人员权限，无需映射整个编配链的有效权限 |
提示注入防御
模式
| 何处查看 | 好样的 |
|---|---|
| Agentforce | 提示模板 | ✅ 在架构上将指令与数据分开：系统级指令不得通过字符串连接与记录源内容、用户提供的文本或工具响应混合 |
| Agentforce | 操作 | ✅ 将个案描述、电子邮件正文、聊天脚本识别为高风险字段。实施预处理层，在传递给客服人员推理之前汇总内容，在保留含义的同时剥离潜在的注入指令 |
| Agentforce | 客服人员配置 | ✅ 在每个客服人员边界定义输入验证合同，并将每个外部内容源视为不可信 |
| Data 360 | 接地源 | ✅ 将 Knowledge 文章、Data 360 索引文档和外部检索源视为需要持续审查的持久注入表面 |
| Einstein | Trust 层 | ✅ 将 Einstein Trust 层安全控制视为深入防御中的一层，而不是完整的解决方案 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| Agentforce | 提示模板 | ⚠ 假设模型将区分个案内容和攻击指令，将原始个案描述连接到带有系统指令的客服人员提示 |
| Data 360 | 接地源 | ⚠ Trust基础源，而不考虑对抗性内容持续存在，并且可以随着时间的推移被没有直接客服人员访问权限的各方修改 |
| Einstein | Trust 层 | ⚠ 完全依赖 Trust 层安全控制，无需额外的架构防御措施，即可获得新的注入技术 |
Einstein Trust 层
模式
| 何处查看 | 好样的 |
|---|---|
| Einstein | Trust 层 | ✅ 客服人员检索个案信息时仅查询推理所需的字段（个案编号、产品、状态、优先级），而不是所有个案字段。如果出现意外的 PII，PII 屏蔽会提供额外保护 |
| Einstein | Trust 层 | ✅ 适当配置 Trust 层，并通过 Trust 层处理记录数据流 |
| Einstein | Trust 层 | ✅ 确定哪些数据分类可以为您的监管上下文输入 LLM 推理 |
| 平台 | Event Monitoring | ✅ 将 Trust 层审计事件与 Event Monitoring 数据一起路由到 SIEM |
| 平台 | Event Monitoring | ✅ 实施应用程序级日志记录，记录客服人员的决定、采取的操作以及 Trust 层日志带来的业务结果 |
| 业务 | 文档 | ✅ 验证 Trust 层审计保留是否符合监管要求 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| Einstein | Trust 层 | ⚠ 查询所有个案字段，包括敏感备注和付款信息，并依赖 PII 掩码来删除所有有问题的内容 |
| Einstein | Trust 层 | 设计客服人员将完整记录上下文发送到 LLM 推理，假设 PII 掩码处理所有内容 |
| Einstein | Trust 层 | 将 Trust 层 PII 掩码视为数据最小化的替代，而不是深入防御 |
客服人员间 Trust 边界
模式
| 何处查看 | 好样的 |
|---|---|
| Agentforce | 客服人员配置 | ✅ 订单履行专家验证编配员提供的订单数据包含必填字段（订单 ID、客户 ID、产品 SKU），值在预期范围内（数量 > 0，价格 > 0），订单状态允许在执行前履行 |
| Agentforce | 客服人员配置 | ✅ 定义显式类型化接口合同，以便客服人员与结构化、范围明确、经过验证的数据进行通信 |
| Agentforce | 客服人员配置 | ✅ 在多客服人员工作流中设计每个客服人员，以在操作前验证收到的上下文，无论呼叫者身份如何 |
| Agentforce | 客服人员配置 | ✅ 以与外部用户输入相同的审查方式处理客服人员间消息内容 |
| 集成 | 外部服务 | ✅ 对于调用外部 AI 服务的客服人员或 Salesforce 外部的第三方客服人员，应用零信任原则并验证响应是否在预期的结构和范围内 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| Agentforce | 客服人员配置 | 专家直接执行编配员请求的任何操作，无需验证请求结构、值或授权上下文 |
| Agentforce | 客服人员配置 | ⚏ Orchestrator 传递原始指令字符串，专家将其视为权威指令 |
| Agentforce | 客服人员配置 | 将完整执行上下文、用户会话数据或累积推理跟踪传递给每个下游客服人员 |
| 集成 | 外部服务 | ⚏ 对外部客服人员响应采取行动，指示编配员在当前任务范围之外执行操作，而不会拒绝或升级 |
在环人
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 流 | ✅ 退款客服人员配置了流检查点，在执行任何超过 1000 美元的退款之前需要人工批准，无论客服人员是否有信心。在客服人员推理外部实施的检查点 |
| 平台 | 流 | ✅ 将 hitL 检查点实施为客服人员推理循环之外的工作流门，设计为架构控制，而不是客服人员指令 |
| 业务 | 文档 | ✅ 定义需要人为确认的操作类别：不可逆转的操作、超过财务阈值的操作、与外部通信的操作、涉及监管数据的操作、发现错误的操作 |
| Agentforce | 客服人员配置 | ✅ 设计审查界面，显示建议的操作、用于达成建议的数据代理以及可用的推理路径 |
| 平台 | 审计 | ✅ 包含客服人员操作记录的商店审核决策：谁审核、何时审核、显示哪些信息、决定的内容 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| Agentforce | 客服人员配置 | ⚠ 为客服人员配置指令“在退款超过 1000 美元前请求批准”，假设提示注入无法覆盖指令 |
| Agentforce | 客服人员配置 | 将 HITL 实施为可解释和潜在忽略的客服人员指令，而不是推理路径之外的工作流检查点 |
| 业务 | 流程 | 向人工审核人员提交批准请求，缺少有关建议操作、使用的数据或推理路径的上下文 — 没有提供真正的监督 |
客服人员行为监控
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | Event Monitoring | ✅ 将事件监控和 Trust 层事件路由到 SIEM，以进行集中安全监控 |
| 平台 | 事务安全性 | ✅ 通过实时评估配置事务安全性策略，包括阻止和通知功能 |
| Agentforce | 客服人员配置 | ✅ 实施自定义应用程序日志记录，捕获推理汇总、工具调用和验证失败 |
| 平台 | Event Monitoring | ✅ 设计检测客服人员特定可疑模式的提醒规则：预期窗口之外的批量数据访问、调用与目的不一致的操作、重复的验证失败、异常的编排模式 |
| Agentforce | 客服人员配置 | ✅ 跟踪每个客服人员的典型操作调用模式、数据访问量、推理调用率、错误率和执行时间，以建立行为基线 |
| 平台 | Event Monitoring | ✅ 定义特定于客服人员的安全事件：权限边界违反、重复验证失败、编排异常、置信阈值违反、后备激活模式 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | Event Monitoring | 将人类活动监控模式应用于客服人员，无需建立特定于客服人员的行为基线 |
| 平台 | Event Monitoring | ⚠ 仅依赖于基于签名的检测，而没有可以检测新攻击的行为监控 |
| 平台 | Event Monitoring | 将错误率升高、验证失败重复或编排模式异常视为正常客服人员行为 |
审计和解释性
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | 审计 | ✅ 对于每个重要的客服人员操作，捕获：客服人员身份和运行用户上下文、触发事件、检索的基础数据、推理汇总、具体行动和结果、置信度、人工审核决策（如果适用） |
| 平台 | 审计 | ✅ 为平台日志（Event Monitoring、Trust Layer 事件）不包含的业务上下文实施应用程序级审计日志记录 |
| 平台 | 审计 | ✅ 将 Event Monitoring 和 Trust 层事件路由到本地保留期之后的长期存储 |
| Agentforce | 客服人员配置 | ✅ 通过编排链记录多客服人员执行跟踪中每个步骤的客服人员身份，以进行归因 |
| Agentforce | 客服人员配置 | ✅ 捕获和表面推理汇总，确定影响客服人员推荐高效决策的关键因素 |
| 业务 | 文档 | ✅ 设计客服人员工作流，以便用户可以请求解释影响他们的决策 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | 审计 | 依赖于重建客服人员在记录中的副作用 — 在您需要审计跟踪时，记录可能已经更改 |
| 平台 | 审计 | 记录多客服人员工作流，而不识别哪个特定客服人员在链中执行了哪个操作 |
| 业务 | 流程 | ⚠ 部署客服人员做出影响重大的决策，而不捕获推理汇总或向受影响的用户提供解释机制 |
不断变化的约束下的决策治理
模式
| 何处查看 | 好样的 |
|---|---|
| Agentforce | 客服人员说明 | ✅ 当新的约束出现在决策中期（截止日期、预算、人员配置、许可证）时，重新运行所有原始因素之间的完全权衡，而不是让新的输入自行推翻之前的决定 |
| Agentforce | 客服人员说明 | ✅ 明确说明目标的变化 — 当优化目标从“架构合理且可维护”转移到“约束下可交付”时浮出水面 — 这样人员可以看到现在优化的目标 |
| 业务 | 流程 | ✅ 将架构-交付-交付之间的紧张关系视为一种人为的权衡：展示收益（速度）与付出（总拥有成本、可维护性、锁定）之间的关系，并将决策传递给负责任的所有者 |
| Agentforce | 客服人员说明 | ✅ 将架构适合性（设计是否满足要求）和交付可行性（此团队能否及时发货）作为单独、可见的因素，而不是将它们夸大为一个答案 |
| 平台 | 文档 | ✅ 在撤销记录的决策时，根据原始理由重新加权，并将撤销记录为带有重新访问触发器的透明、有时限的权衡 — 更新的决策记录显示权衡已重新加权，而不仅仅是替换 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| Agentforce | 客服人员说明 | 允许单个新约束（团队不可用、期限紧迫）逆转技术决策，同时悄悄放弃导致原始选择的成本和维护因素 |
| Agentforce | 客服人员说明 | 将优化目标从“架构合理且可维护”转移到“约束下可交付”，而不标记目标已更改 |
| 业务 | 流程 | 在新的约束下，从合理的设计转向更便宜或更便捷的选择，而不会重新显示导致原始选择的长期总体拥有成本、可维护性和锁定性 |
| 业务 | 流程 | 在客服人员的推理中解决架构与交付的冲突，而不是将其作为一种有意识的、人为的权衡来升级 |
| 平台 | 文档 | 生成新的决策记录，记录撤销，但不会根据原始理由重新权衡 — 从文字上而不是实质上尊重重新访问触发器 |
AI 监管合规
模式
| 何处查看 | 好样的 |
|---|---|
| 业务 | 文档 | ✅ 跟踪解决方案运行的管辖区的监管动态，并从一开始就将合规性设计到代理系统中 |
| 业务 | 文档 | ✅ 评估每个适用框架的 AI 系统风险水平（欧盟 AI 法案、美国 AI 权利法案、区域框架） |
| Agentforce | 客服人员配置 | ✅ 实施透明度和解释性机制,设计适合风险水平的人力监督 |
| 业务 | 文档 | ✅ 记录如何通过特定的架构控制来满足每个行业的特定要求（HIPAA、DORA、SOX、GDPR、CCPA） |
| 业务 | 文档 | ✅ 在生产部署前验证合规性 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 业务 | 流程 | ⚠ 部署后提高透明度、可解释性和人为监督，而不是从一开始就内置 |
| 业务 | 流程 | 部署处理 PHI、财务数据或个人数据的客服人员，无需验证是否满足 HIPAA、DORA/SOX 或 GDPR/CCPA 要求 |
| 业务 | 流程 | 忽略新出现的特定于 AI 的法规（欧盟 AI 法案风险分类和透明度要求），在传统的 Salesforce 自动化也不能免除时，仅将它们视为客服人员 |
供应链Trust
模式
| 何处查看 | 好样的 |
|---|---|
| 平台 | AgentExchange | ✅ 在启用第三方操作供客服人员使用之前，请查看在代码和数据流级别执行的操作、调用的外部服务以及传输的数据 |
| 平台 | AgentExchange | ✅ 在应用受管软件包更新时，重新访问第三方操作配置 |
| Agentforce | 提示模板 | ✅ 在使用前查看来自团队外部的提示模板，并将其视为在有权访问贵组织数据的特权推理流程中执行的代码 |
| Agentforce | 提示模板 | ✅ 建立生产代理所用模板的审核审批流程,并保留模板来源记录 |
| Agentforce | 客服人员配置 | ✅ 通过代表性问题、边缘个案和已知注入尝试，维护客户服务代理的测试套件。在模型更新通知后在 Sandbox 中运行套件，在升级到生产前比较响应质量和安全性 |
| Agentforce | 客服人员配置 | ✅ 将模型版本更改视为部署事件，并为客服人员维护行为测试套件，涵盖代表性输入、边缘个案和已知对抗模式 |
反模式
| 何处查看 | 什么不好的样子 |
|---|---|
| 平台 | AgentExchange | 启用第三方 AgentExchange 操作供客服人员使用，无需查看代码、数据流和外部服务调用 |
| Agentforce | 提示模板 | 使用来自外部来源或社区示例的提示模板，而不查看可能修改客服人员安全行为或引入推理偏见的嵌入指令 |
| Agentforce | 客服人员配置 | 允许无需验证即可自动更新生产客服人员的模型，通过用户投诉发现行为变化 |