过去，员工是应用之间的“人工接口”：从 CRM 复制客户信息，切换到项目管理工具，再把结果粘贴进邮件。随着自主 AI Agent 开始执行跨标签页、跨应用的多步流程，终端不再只是显示界面，而是逐渐成为工作流执行、安全控制和上下文感知的共同入口。
Google 提出的 Intelligent Endpoints，核心并非增加一台新设备，而是把企业浏览器、操作系统、硬件、AI 能力和管理策略整合起来。对企业 IT 团队而言，真正的问题也随之变化：当 Agent 可以代替用户操作多个系统时，如何同时获得效率、可观测性和数据边界？
浏览器正在变成 Agent 的执行平面
传统自动化通常依赖 API、RPA 客户端或浏览器扩展。现在，Agent 能力开始直接进入浏览器，在多个标签页之间执行连续任务。例如，员工可以定义“整理新线索并创建跟进任务”这一结果，Agent 再依次读取 CRM、更新项目管理系统并生成后续内容。
这种方式有三个直接价值：
- 减少上下文切换：用户不必充当多个 SaaS 应用之间的数据总线。
- 复用现有系统：即使部分旧系统缺乏现代 API，仍可通过浏览器界面参与工作流。
- 统一治理入口：浏览器已经掌握身份、站点、下载、剪贴板和上传等上下文，适合执行细粒度策略。
Gemini in Chrome 的企业 Skills library 进一步强调了标准化工作流。通过受控测试计划，IT 团队可以发布预配置、经过审核的 AI Skill，让员工从企业批准的工作流库中选择，而不是每个人从零编写提示词。这种模式类似“内部自动化应用商店”：业务团队定义需求，IT 和安全团队审核权限、数据范围及目标系统。
旧应用也不一定要立即重写。Cameyo by Google 可将旧应用流式传输到 Chrome 标签页中，再结合 Chrome Enterprise Premium 的浏览器安全能力。这样做不能消除旧系统本身的技术债，但可以先统一访问入口，减少本地安装、版本漂移和不受控的数据交换。
DLP 必须前移到复制、上传和截图发生之前
Agent 带来的风险并不只来自模型本身。员工把内部代码、客户记录或知识产权粘贴到公共 AI 服务，同样可能造成数据泄露。来源材料援引的调查显示，接近 80% 的员工会自行把 AI 工具带入工作场景，超过半数受访者曾向公共系统粘贴敏感企业数据。
仅依赖 AI 服务商的隐私开关并不够。终端侧治理需要回答四个问题：
- 用户正在访问哪个 AI 或 SaaS 服务？
- 即将复制、上传、下载或分享的数据是什么？
- 当前设备、账号和应用是否受企业管理？
- 应该允许、告警、脱敏、重定向还是直接阻止？
Chrome Enterprise Premium 已支持浏览器内的细粒度 DLP。来源还提到，IT 团队将能够在浏览器触发复制动作时检测并阻止敏感记录，使内容在进入系统剪贴板之前就被拦截。部分浏览器 DLP 能力也扩展到了移动设备，包括下载、粘贴、截图和分享控制。
这类控制的关键是“尽可能靠近数据动作”。如果检测发生在内容已经进入剪贴板、上传队列或第三方应用之后，阻断就可能变成事后告警。与此同时，策略也不能过度粗暴，否则员工会转向个人设备或未经批准的工具，形成更难观察的 Shadow AI。
可以这样实践：先做一个可运行的终端 DLP 原型
下面的 Python 脚本不是 Google 管理控制台的真实策略格式，而是一个可直接运行的最小原型。它模拟终端在数据发送给 AI 服务之前，根据目标域名和敏感内容执行允许或阻止。团队可以用它讨论规则优先级，再把规则映射到实际的 Chrome Enterprise、代理网关或终端管理平台。
将以下内容保存为 endpoint_guard.py：
#!/usr/bin/env python3
import argparse
import re
import sys
from urllib.parse import urlparse
APPROVED_AI_HOSTS = {
"gemini.google.com",
"ai.example-corp.internal",
}
SENSITIVE_PATTERNS = {
"email": re.compile(r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b"),
"credit_card": re.compile(r"\b(?:\d[ -]*?){13,16}\b"),
"api_key": re.compile(r"\b(?:sk|api)[-_][A-Za-z0-9_-]{16,}\b", re.I),
}
def inspect(destination: str, text: str) -> tuple[bool, list[str]]:
host = urlparse(destination).hostname or ""
findings = [name for name, pattern in SENSITIVE_PATTERNS.items() if pattern.search(text)]
if findings and host not in APPROVED_AI_HOSTS:
return False, findings
return True, findings
def main() -> int:
parser = argparse.ArgumentParser(description="Pre-send endpoint DLP demo")
parser.add_argument("--destination", required=True)
parser.add_argument("--text", required=True)
args = parser.parse_args()
allowed, findings = inspect(args.destination, args.text)
if not allowed:
print(f"BLOCK: sensitive={','.join(findings)} destination={args.destination}")
return 2
status = "ALLOW_WITH_AUDIT" if findings else "ALLOW"
print(f"{status}: destination={args.destination}")
return 0
if __name__ == "__main__":
sys.exit(main())
运行测试：
python3 endpoint_guard.py \
--destination https://public-ai.example/chat \
--text 'Customer email is alice@example.com'
echo $?
python3 endpoint_guard.py \
--destination https://gemini.google.com/app \
--text 'Customer email is alice@example.com'
第一条命令会返回 BLOCK 和退出码 2；第二条会返回 ALLOW_WITH_AUDIT。生产环境中还应补充数据分类标签、组织单位、设备合规状态、例外审批和审计日志，并避免把原始敏感内容写入日志。
从单点控制升级为跨设备策略
智能终端策略不能只覆盖办公电脑。来源列出的产品方向包括托管 Chromebook Plus、Android Enterprise 管理的手机与折叠设备、Android XR 空间计算设备，以及 Google Beam 这类沉浸式协作终端。重点不是采购所有设备，而是让同一组身份和数据原则延伸到不同形态：
- 公司账号访问受限数据时，设备必须满足合规条件；
- AI 功能按组织、角色和数据分类开放，而不是全局启用；
- 下载、复制、截图和分享策略在桌面端与移动端保持一致；
- AI 与 SaaS 使用情况进入统一报告，并支持从报告直接阻止高风险应用或引导到批准的替代服务；
- Agent 使用独立身份和最小权限，不能默认继承员工的全部访问能力。
需要注意的是，文中提到的部分设备和能力仍处于测试、即将推出或较晚的企业可用时间表。制定路线图时，应以所在地区、Workspace 版本、设备型号和管理控制台中的实际可用性为准。
落地顺序：先治理高风险动作，再扩大 Agent 权限
企业不必一次性重构整个终端体系。更稳妥的推进顺序是：
- 盘点员工正在使用的 AI 与 SaaS 服务，识别 Shadow AI；
- 先保护复制、粘贴、上传、下载、截图和分享等高风险动作；
- 建立批准的 AI 服务清单，并为被阻止的工具提供可用替代方案；
- 从低风险、可回滚的流程开始发布企业 AI Skills；
- 为每个 Agent 设置最小权限、执行上限、人工确认点和完整审计记录；
- 再逐步把策略扩展到移动设备、旧应用和新型终端。
智能终端的价值不在于让 AI 能点击更多按钮，而在于让自动化始终运行在可识别身份、可约束数据、可审计动作的环境中。只有把生产力入口和安全控制放在同一层，企业才能放心地把 Agent 从个人助手升级为真正的业务流程执行者。