Preface¶

DeepSeek Harness (dsh) logs session events in local standardized logs, which serve as primary materials for troubleshooting agent loops. Once the session telemetry backend is deployed and enabled, the same batch of events takes an outbound path: first projected into a SessionTelemetryRecord, then handed over to the collector. The official documentation clearly states that the session-telemetry/record waterfall itself does not include any anonymization rules; when no listeners are attached, the backend receives an exact copy of the captured data.

This creates a problem. Session events often contain credentials such as Authorization, cookies, apiKey, or sk-.... Standardized logs can stay on the local machine, but the outbound copies may end up in OpenTelemetry, feedback channels, or self-built collectors. The official DeepSeek repository’s motto is “Everything is a plugin”, leaving this anonymization gap to be filled by deployments themselves. dsh-telemetry-redactor is a community Profile Bundle attached to this gap: it intercepts outbound copies by default, wipes out supported sensitive patterns before sharing, and does not modify the standardized session logs.

This article is collated after cross-checking the plugin directory page, GitHub README / SECRET-MATRIX.md / SECURITY.md, npm package descriptions, and official DeepSeek Harness session telemetry documentation. The community plugin directory is an independent site and has no official affiliation with DeepSeek / FunPlus.

What It Is¶

dsh-telemetry-redactor is a minimal DeepSeek Harness Profile Bundle maintained by GitHub user 030611, currently at version 0.1.0, licensed under MIT, and primarily written in TypeScript. The directory page categorizes it under the “Session & Messaging” section; as of 2026-08-18, both GitHub and the directory page show 3 stars. The npm package with the same name was released on 2026-08-14.

The problem it solves is narrow: it performs recursive anonymization on supported credential patterns before the configured telemetry backend receives the exported copies. The repository README emphasizes two points:
- The plugin only modifies outbound copies and never rewrites the authoritative session log.
- It does not add, replace, or enable any telemetry backends; it only protects the records that the deployment’s chosen backends will process.

dsh.plugin.json declares that the effect only hooks session-telemetry/record, with network and filesystem both set to false, and modelVisible set to false. The “Model Experience” section of the README also states: it does not contribute prompts, tool schemas, messages, or model requests, and has no impact on the KV Cache.

The maintainer lists it alongside three other community trust-layer plugins: Verification Receipt, Evidence Audit, and Context Provenance. They all similarly state “Maintained by the community, not an official DeepSeek project”.

Core Features¶

Hooking the Official Waterfall¶

The official SessionTelemetryCoordinator makes a deep copy of standardized session events before entering session-telemetry/record. The mounting method in the plugin source code is:

ctx.on('session-telemetry/record', (_record, next) => redactRecord(next(), replacement), { prepend: true })

It first calls next() to allow other deployment rules to continue combining, then performs a new recursive anonymization on the returned value. The listener is registered with Cordis prepend, so it usually wraps rules mounted before and after it, and anonymizes the final output of those rules. The official documentation’s convention for this waterfall aligns with this: listeners superimpose effects by transforming the return value of next(); if an error is thrown, it is isolated by the coordinator, and only this one export copy is dropped without entering the agent loop.

The repository calls this behavior fail-closed, but with a narrow meaning: it only means the official coordinator discards this failed export copy, and the agent loop continues running. It is not a guarantee that “all telemetry paths and all listener orders cannot be bypassed”. SECURITY.md clearly states: third-party dispatchers that ignore the official isolation conventions are outside the supported boundary.

What Content It Anonymizes¶

The rules are hardcoded in the source code and cannot be disabled via configuration. The supported scope listed in the README and SECRET-MATRIX.md is as follows.

Full values under high-risk keys will be replaced, such as authorization, cookie, credential, password, secret, token, apiKey, access_token, clientSecret, privateKey. If the key name itself matches the recognized credential pattern, the key name will also be rewritten; if a key conflict occurs after rewriting, the entire record will be rejected instead of being exported with partial anonymization.

Fixed patterns in strings will also be matched:
- Bearer / Basic followed by at least 8 credential characters
- sk-...
- GitHub tokens (ghp_ / gho_ / ghu_ / ghs_ / ghr_, github_pat_)
- Slack tokens (xoxa- / xoxb- / xoxp- / xoxr- / xoxs-)
- Three-segment JWTs
- Labeled assignments such as token=..., api_key: ...

The key name will be tokenized before matching, so fields like inputTokens, output_tokens, tokenUsage, tokenCount, contextTokenCount, and tokenizer related to counting will be retained. It recursively processes enumerable JSON data in arrays, plain objects, and null-prototype objects, with a maximum of 64 levels of containers; overly deep records, circular references, accessors, and non-plain objects will throw errors, and the official coordinator will drop that export copy.

The default replacement text is [REDACTED].

Explicitly Uncovered Boundaries¶

SECRET-MATRIX.md separates “detection” and “anonymization proof”. The following situations may still be transmitted, or may not even enter this rule:
- Unknown secret formats that are neither under sensitive keys nor match recognized string patterns
- Encoded/encrypted values, overly short Bearer tokens, cookie text appearing in unrelated strings
- apiKey, apiKeyEnv in LLM/provider configurations, and request headers (not included in SessionTelemetryRecord)
- headers of OTel exporters, endpoint URL/query credentials
- Direct calls to the backend emit(), or another more outer prepended listener writing content after this plugin returns

Therefore, it is a security filter, not a guarantee that “no arbitrary unknown secrets will be leaked”. Exported data, even after anonymization, should still be treated as sensitive data.

Installation and Enablement¶

The installation command given on the directory page is:

dsh plugin add github:030611/dsh-telemetry-redactor

For reproducible installations, fix the commit hash as instructed on the directory page:

dsh plugin add github:030611/dsh-telemetry-redactor#<commit>

The repository README and npm package both provide the method of installing the public package by profile (the example profile is web):

dsh plugin --profile web add dsh-telemetry-redactor
dsh --profile web --dump-config

The configuration dump must include the newly added telemetry-redactor line. The dsh.bundle field in package.json points to cordis.patch.yml, which only inserts a record with id: telemetry-redactor and does not modify the backend. The README reminds: dsh.plugin.json only supplements community metadata, and what truly controls DSH installation is dsh.bundle and cordis.patch.yml.

Compatibility is subject to the current repository declaration: Node ^22.19.0 || >=24.0.0; peer dependencies @deepseek-ai/cordis ^4.0.1, @deepseek-ai/dsh-session-telemetry >=0.1.0-rc.5 <0.2.0. The release smoke test uses a frozen fixture carried with the package, corresponding to the official commit 47f943859bef60e4160492346772ded9b24f765a. DeepSeek Harness is still in developer preview, and the official README has stated that there will be breaking changes; after installation, you should recheck with the resolved version at that time.

Both the directory page and official plugin documentation remind: the plugin runs with the permissions of the current dsh process, and may execute code during installation. Inspect the source code repository and license before installing.

Typical Usage¶

After installation, the only configurable item is replacement. The default is [REDACTED], with a length of 1 to 128 characters, and it must not match the supported credential patterns itself; an invalid value will fail directly when the Cordis plugin fiber is awaited.

- id: telemetry-redactor
  config:
    replacement: '[TELEMETRY-REDACTED]'

The key name rules and string patterns cannot be turned off. To confirm whether the plugin truly blocks outbound copies without modifying the standardized logs, the repository provides a set of tests that do not connect to the network, do not call models, and do not require an API key:

pnpm run typecheck
pnpm test
pnpm run build
pnpm run test:smoke
pnpm run test:performance
pnpm run test:official-head
pnpm run test:official-patch
pnpm run test:packed:clean-env

The README clearly states: this set of tests uses a real Cordis Loader combined with SessionTelemetryCoordinator — the backend can only receive the replaced values, and the authoritative session events still retain the secrets in the fixture; overly deep records will be blocked, and exceptions will not escape the capture handler.

The acceptance test for daily deployment is simpler: first use dsh --profile <profile> --dump-config to see telemetry-redactor, then confirm that the telemetry backend itself is the one you explicitly selected. This plugin will not enable sharing for you.

Applicable Scenarios and Notes¶

It is suitable for DSH deployments that have (or plan to) connect to a session telemetry backend: you want to send session events to a collector, feedback channel, or operation dashboard, but do not want apiKey, Bearer tokens, GitHub/Slack tokens to be sent out in plaintext. It is not suitable as a complete privacy solution — the standardized logs still retain plaintext events locally; provider configurations and exporter credentials also do not go through this waterfall.

Before using it, it is recommended to do the following:
1. Read the repository’s SECURITY.md and SECRET-MATRIX.md, and review the complete set of waterfall listeners according to your actual deployment. Another plugin that prepends an outer listener may still add content after anonymization.
2. Collect telemetry as little as possible. The plugin’s own security documentation recommends: adopt the officially default-closed sharing strategy on the explicitly authorized frontier, restrict collector access and retention, and treat anonymized records as sensitive data.
3. Check the source code, license (MIT), and commit before installing. The plugin runs with the permissions of the current dsh process, and may execute code during installation.
4. Do not interpret “fail-closed” as a full unbreakable path. Direct emit() calls, non-official dispatchers, and unknown secret formats are all outside the promises of this rule.

Summary¶

dsh-telemetry-redactor does a very specific thing: it adds a default-intercept export anonymization rule on the official session-telemetry/record, wipes out supported credential patterns, and leaves the standardized session logs unchanged. Its capability boundaries are clearly stated, and there is only one configuration item for the replacement text.

Directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-telemetry-redactor/

GitHub: https://github.com/030611/dsh-telemetry-redactor

Anonymized Export of DeepSeek Harness Session Telemetry with dsh-telemetry-redactor