明文不扩散，日志仍可用：阿里云可观测敏感数据保护方案

AI Agent 让日志中的敏感数据更多、更复杂。除手机号、IP、API Key 等传统字段外，AI Coding Agent、RAG 应用和运维 Agent 还会读取代码、配置、环境变量与数据库连接串，并将工具调用、终端输出和模型回复写入审计日志，敏感信息因此更容易进入日志链路。

这些数据又不能简单丢弃，因为它们是排障、审计和治理的重要依据。为兼顾安全与可用性，阿里云可观测提供贯穿采集、写入和加工环节的保护方案：数据入库前可脱敏或加密，入库后也可进一步加工，形成适合长期留存和共享分析的安全数据集。

下面先看整体方案，再展开不同方式的落地场景。

少暴露、不减值：保护敏感数据贯穿全链路

SLS 的敏感数据保护方案，可以拆成两个简单问题：敏感内容用什么方式保护，保护动作放在数据链路的哪一站执行。前一个问题对应脱敏、对称加密和信封加密；后一个问题对应端上处理、写入处理器和数据加工。

两类选择可以灵活组合：同一种保护方式既可以放在采集侧，也可以放在写入前或入库后；同一个处理位置也可以根据数据风险选择脱敏或加密。客户可以按数据来源、合规要求和后续分析方式选择组合：要求明文不出主机时优先端上处理；多来源直写时使用写入处理器集中治理；需要长期共享或存量治理时，再通过数据加工生成受保护 Logstore。

按使用需求选择

不同类型的敏感数据，不需要用同一种方式处理。SLS 在数据处理中提供脱敏、对称加密和信封加密三类SPL 函数，分别对应“保留可读性”“授权可还原”和“职责分离”的安全诉求。

脱敏：保留可读性，降低隐私风险

mask适合处理散落在文本中的 PII 或凭证类字段。它支持两类匹配方式：

• buildin：内置手机号、邮箱、身份证、银行卡、IP、固话、AccessKey、车牌、IMSI、VIN 等规则；
• keyword：按字段名或键名匹配，如 password、token、authorization、api_key。

打码方式可以是占位符，也可以保留前后缀。例如手机号保留前三后四，既保护隐私，也便于排障时与业务侧做模糊核对。脱敏后的日志仍可读、可查、可聚合，适合作为大多数日志场景的首选（具体使用方式参考帮助文档 ）。

典型场景包括：

• AI 网关 prompt 中散落手机号、邮箱、身份证；
• 应用访问日志中的客户端 IP、鉴权 token；
• LLM 应用日志中的银行卡号、地址、用户标识。

对称加密：密文落库，授权还原

aes_encrypt 适合“后续需要还原，但密钥归属清晰”的场景。例如内部 RAG 问答、模型请求、客户方案等内容，落库时可以是密文，授权审计时再由持有 Key + IV 的团队还原。

如果采集、分析和审计都在同一团队内，Key + IV 可以统一管理，对称加密是简单且高性能的选择。它的边界也很清楚：密钥一旦共享出去，所有持有者都具备解密能力，因此适合同组织、同安全域内部使用，不适合跨团队广泛分发。

信封加密：公私钥分离，适合高敏协作

envelope_encrypt 适合采集方和解密方分离的场景。它采用信封加密机制：随机生成 DEK 加密业务数据，再用非对称公钥加密 DEK。采集侧只配置公钥，私钥由安全或审计团队单独保管。

这类模式适合高敏字段，例如：

• AI Coding 工具读取文件后的完整返回；
• 命令执行输出；
• 含密钥、连接串、配置文件的整段日志。

信封加密的另一个优势是性能可控。DEK 在 pipeline 级别生成，非对称加密只作用于 DEK，业务数据仍由 AES 处理，避免对采集吞吐造成过大影响。

保护方式和处理位置不是固定绑定的。下文按数据流依次展开三个位置，每个位置只挑一个代表性方式举例，并不代表该位置只支持这一种。

端上保护：让明文不出采集侧

在更严格的合规场景里，敏感数据保护需要下沉到采集侧：日志刚被采集，就已经完成处理，明文不出主机、不出容器，也不进入后续传输链路。

端上保护可以分成两类：一类是 LoongCollector 面向主机/容器日志的采集时处理；另一类是 LoongSuite Pilot 面向 AI Coding Agent 的端侧隐私控制。二者解决的问题不同，但目标一致：在数据离开采集侧之前，先控制明文扩散。

LoongCollector：采集即处理，业务无需改造

对于部署在 ECS、ACK、IDC 主机或容器中的应用，LoongCollector 不只是采集器，也可以在采集时执行 SPL。AI 网关、百炼应用、RAG 服务、模型代理层等组件通常会输出大量访问日志和交互日志，其中既有结构化字段，也有用户输入的自然语言内容。把处理放在采集侧，可以显著降低明文扩散面。

以 AI 网关访问日志为例，一条原始日志可能包含调用方 IP、API Key 和用户 prompt：

model=qwen-max client_ip=203.0.113.55 prompt="我是张某，手机号138xxxxxxxx，邮箱zhangwei@xxxx.com，帮我查最近订单" tokens=128

在 LoongCollector 采集配置中，可以用 mask 同时处理内置 PII 和关键字字段：

写入 SLS 后，日志仍然能用于模型调用量、Token 用量、网关访问趋势分析，但敏感值已经被替换：

这类方案适合业务应用日志、网关日志、模型代理日志等主机/容器侧数据。它的优势是无需修改业务代码，采集配置里完成处理，日志写入 SLS 时已经是脱敏后的安全形态。

LoongSuite Pilot：AI Coding 数据先脱敏再分发

端上方案的另一个典型场景是 AI Coding 审计。开发者本机运行的 Coding Agent 经常会接触项目源码、配置文件和本地环境变量。开发者在提问时粘贴一段配置，或者 Agent 读取 .env 文件后把内容写入工具调用参数，都可能让 API Key、云厂商 AK/SK、私钥等数据进入采集链路。

LoongSuite Pilot面向这类端侧 AI Coding 场景，负责发现并采集 Claude Code、Cursor、Codex、Qoder 等工具的活动数据，归一化为会话、工具调用、模型调用、Token 用量等审计事件。同时，Pilot 内置基于规则的自动脱敏引擎，在数据分发给任何输出通道之前统一扫描并替换敏感内容。开启后，无论数据输出到 SLS、JSONL、HTTP 还是 OTLP，脱敏规则都会统一生效。

Pilot 的自动脱敏覆盖以下常见凭据类型：

例如，一次 AI Coding 会话中，Agent 读取本地 .env 文件后产生如下工具返回：

DB_URL=mysql://root:Abc@2025!@10.0.0.12:3306/prod
ALIYUN_AK=LTAI5tFakeExampleKey0001
-----BEGIN RSA PRIVATE KEY-----
MIIEvQIBADANBgkqh...
-----END RSA PRIVATE KEY-----

Pilot 在输出前完成自动脱敏后，写入 SLS 的内容会变成：

脱敏通过 mask.mode 配置开关控制，支持 none、all、custom 三种模式，默认关闭。开启后，敏感凭据不会原样进入后续输出通道；而 session_id、tool_name、Token 用量、执行耗时等审计元数据仍然保留，研发管理和安全团队可以继续分析 AI Coding 的使用情况、工具调用风险和成本分布。

综上：端上保护适合三类客户诉求：

• 明文不能离开业务主机或开发者本机；
• 采集链路跨网络、跨团队，明文传输风险不可接受；
• 希望在不修改业务代码的情况下，把敏感数据保护前置到日志产生的第一站。

写入前保护：直写数据入库前统一治理

并不是所有数据都会经过 LoongCollector。很多系统通过 SDK、WebTracking、OpenAPI 或第三方采集链路直接写入 SLS。对于这类数据，写入处理器提供了服务端统一治理能力：数据到达 SLS 后、写入 Logstore 前，先执行 SPL 完成脱敏或加密。

写入处理器的优势在于集中配置。规则放在 SLS 侧，客户端不需要逐一升级；当处理策略变化时，只需要调整处理器配置，就能覆盖所有直写数据。对于多业务线、多语言 SDK 或第三方系统上报的场景，这种方式更容易落地。

以 AI 网关的访问日志为例，网关把每次模型调用拼成一行、用 ## 分隔后直接写入 SLS。其中 request 字段是完整的模型请求体，可能夹带用户 prompt、身份证号等任意敏感内容；其余字段则是结构化的调用元数据：

2026-06-25 11:17:25.471##c9d7ab4c-b312-9d08-9243-c7f7475905be##5000000276111136##API_KEY##qwen-max##text-generation##{"input":{"prompt":"我的身份证号是53010219200508011x，帮我查询保单状态"}}##chat-app##3de69809a9d0fd22773f33c77dab12a8

这里的 request 是整段、非结构化的请求体。这个示例选择对 request 做对称加密，重点展示写入处理器如何在入库前统一处理直写数据：先按分隔符拆出字段，再单独对高敏正文执行 aes_encrypt。

在写入处理器中加密高敏请求体

写入处理器 SPL 配置：

* | extend temp = split(content, '##')
  | extend time          = temp[1],
           request_id    = temp[2],
           caller_uid    = temp[3],
           source        = temp[4],
           model         = temp[5],
           api_type      = temp[6],
           request       = temp[7],      
           service_name  = temp[8],
           trace_id      = temp[9]
  | extend request = to_base64(aes_encrypt(
        cast(request as binary),
        cast('aZ4kP9mX2qL7nR1t' as binary),
        cast('Gh8dW3sB6vN0cT5e' as binary)))
  | project-away content, temp

入库后，request 变成 Base64 密文，而 request_id、region、model、service_name、trace_id 等调用元数据仍是明文：

运维可以靠 request_id、trace_id 排查链路，运营可以按 model、service_name 统计调用量，而真正的请求正文已经是密文。

授权场景下按需还原

需要还原时，由持有 Key + IV 的团队成员在查询时解密：

数据加工：面向共享分析生成安全数据集

端上处理和写入处理器解决的是“入库前保护”。数据加工解决的是另一个问题：已经进入 Logstore 的数据，如何重新组织成更安全、更适合长期分析的数据集。

在实际项目中，很多团队会保留两个 Logstore：

• 原始 Logstore：保留时间短，访问权限严格，仅用于紧急排障或安全调查；
• 受保护 Logstore：由数据加工任务生成，敏感字段已脱敏或加密，保留时间更长，面向更大范围的分析和审计。

这种模式特别适合 AI 观测数据。以 LoongSuite Pilot 采集的 AI Coding（如 Qoder）活动日志为例，每条 llm.response 事件都带着一批结构化元数据（会话 ID、模型、用户 ID 等），以及一个 gen_ai.output.messages 字段——它是模型本轮回复的完整正文，可能夹带内部系统名、主机信息、配置或密钥等任意敏感内容：

{
  "event.name": "llm.response",
  "gen_ai.session.id": "58bf461a-285f-468e-963c-00cd1706a9d9",
  "gen_ai.provider.name": "qwen",
  "gen_ai.response.model": "auto",
  "user.id": "1",
  "gen_ai.output.messages": "[{\"role\":\"assistant\",\"parts\":[{\"type\":\"text\",\"content\":\"已整理候选人薪资表：张某（手机号138xxxxxxxx）...\"}],\"finish_reason\":\"end_turn\"}]",
  "trace_id": "a58ed78ac2573159b4fa8b38ab4c2697",
  "__time__": "1782367255"
}

gen_ai.output.messages 是整段、结构不固定的模型回复，逐字段脱敏难以覆盖全部风险；真正排查问题时又可能需要还原原文。这个示例选择信封加密，重点展示数据加工如何先派生分析字段（这里取回复长度 msg_len），再对高敏正文加密后写入受保护 Logstore：

* | extend msg_len = length("gen_ai.output.messages")
  | extend result = envelope_encrypt(
      cast("gen_ai.output.messages" as binary),
      '-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Vh1QIpNurP0bB9uHRK3
ZL29SjY74OtYa5nmf9xUMKAuLrio5BN6LRZyG680uCkCThCMOK/T9ka5ZYtEIu8b
U7acNR1dL3LWsbZG3ScbqyISJ3pEBli2rCgOqBQK3EE+6HGavh6wo8FAhkSBiryU
eVKxSJSnC928RvlBWtyfdubVYQHPONhx0TbCj38Njjfi8kbKGgE92q9gTlL+spge
qvgDec9GV2VzxhLoTgxd6jdHYyfFzuQucb0hZtmWqus4E4MTnAXnUJOGizmI02AP
5d49P44kZXElBPRw4A0WISKBmwOzYCZqPSEWyHnj/qIaXAbz90B8TCUiPZlNouCG
TwIDAQAB
-----END PUBLIC KEY-----',
      '{"mode":"RSA"}',
      '{"mode":"CTR"}')
  | extend encrypted_dek = result['encrypted_dek'],
           enc_output_messages = result['encrypted_data']
  | project-away "gen_ai.output.messages"

加工后写入受保护 Logstore 的记录里，gen_ai.output.messages 已被移除，取而代之的是密文 enc_output_messages 和被公钥加密的 encrypted_dek，其余元数据保持明文：

这样做后，受保护 Logstore 中保留了事件类型、会话 ID、模型、用户 ID、回复长度等分析字段，仍然可以做告警、趋势统计和风险排查；真正的模型回复正文则变成密文。需要深度调查时，由持有私钥的安全人员解密指定记录。

这也是加密与可分析性之间的平衡点：不要把所有字段一股脑加密，而是在加密前抽取必要的分析元数据，只对高敏正文加密。 日常分析依赖元数据，敏感原文通过授权解密受控访问。

如何选择：看明文边界、分析诉求和解密权限

落地时可以按三个问题做选择。

第一，明文能不能离开采集侧？ 如果不能，优先把处理放到端上。

第二，日志是否还需要日常阅读和分析？ 如果需要，优先保留可读性；只有当内容整体高敏、无法可靠局部处理时，才考虑加密。

第三，谁有权解密？ 同团队、同安全域内可以统一管理密钥；跨团队或职责分离场景，应让解密权限由安全或审计团队独立掌握。

可以把策略总结为一张表：

安全与可用可以同时兼顾

日志的价值在于可观测、可分析、可追溯；敏感数据保护的目标，不是让日志失去价值，而是让日志在安全边界内继续发挥价值。SLS 把脱敏和加密能力前置到采集、写入和加工链路中，帮助企业在控制明文扩散面的同时，保留必要的分析能力。

最终，企业可以按数据类型选择脱敏或加密，按数据链路选择端上、写入前或加工后处理，按密钥归属选择对称或信封，在“数据可用”和“数据安全”之间建立清晰、可执行的边界。