030611/dsh-context-provenance
30Last commit Aug 14, 2026
dsh-context-provenance DSH plugin
dsh-context-provenance is a privacy-focused, observe-only DSH plugin that reports what public runtime interfaces can prove about an Agent's context. It retains only the two most recent ordinary agent-loop request observations in memory and exposes them through the existing Cordis inspect query mechanism.
How to install the dsh-context-provenance DSH plugin
dsh plugin --profile web add dsh-context-provenanceCopying does not run this command. Review the repository and version before installing the dsh-context-provenance DSH plugin.
dsh-context-provenance DSH plugin data source
dsh-context-provenance DSH plugin snapshot date: Aug 16, 2026
discovered
What the dsh-context-provenance DSH plugin can do
- Labels evidence fields (e.g., provider/model, system presence, tool names) as Observed, Estimated, or Unavailable based on public interfaces
- Tracks changes across adjacent requests (e.g., system changed, tool catalog changed) using process-random keyed fingerprints without serialization
- Provides a bounded evidence report via Cordis inspect provider 'ContextProvenance' method 'report'
- AGENTS folding is incremental: first request after load catches up, subsequent requests examine only new events
- Does not perform file, network, subprocess, GPU, persistence, session, permission, tool, model-routing, or request mutation
Where the dsh-context-provenance DSH plugin fits
- Audit the context provenance of an agent's requests to understand what information is verifiable
- Debug unexpected behavior by comparing evidence labels between two adjacent requests
- Enhance transparency in agent systems by exposing which runtime interfaces contributed to evidence
- Assess privacy risk by verifying that sensitive content (prompt text, messages, tool schemas) is never exposed
- Integrate with other trust-layer plugins like Telemetry Redactor or Evidence Audit for a complete audit pipeline
Who the dsh-context-provenance DSH plugin is for
- Developers building trust-layer tooling for DeepSeek Harness agent systems
- Security researchers evaluating the verifiability of agent context in production deployments
- Operators who need to audit agent behavior without exposing proprietary prompts or configurations
dsh-context-provenance DSH plugin limitations
- Loader entries do not identify the bundle, profile, override, or dependency that introduced them
- Plugin inventory reveals ordered enablement and lifecycle categories, but never raw entry ids, package names, file URLs, absolute paths, or patch specifiers
- A tool name or schema does not identify its owning plugin
- Skill names remain visible because they are the public callable identity; a sensitive deployment name may still be leaked
- Adjacent observations cover only actual ordinary llm/stream calls seen while plugin is mounted; earlier requests, auxiliary calls, and observations lost on unload or restart are unavailable
dsh-context-provenance DSH plugin: from the repository README
Quoted from the 030611/dsh-context-provenance README, the upstream source of the dsh-context-provenance DSH plugin. Copyright remains with the original authors.
**Compare adjacent request evidence as `Observed`, `Estimated`, or `Unavailable`—without returning prompt text, message content, tool schemas, or raw paths.** ```sh dsh plugin --profile web add dsh-context-provenance ``` > Community-maintained and not an official DeepSeek project. Related trust-layer plugins: [Telemetry Redactor](https://github.com/030611/dsh-telemetry-redactor), [Verification Receipt](https://github.com/030611/dsh-verification-receipt), and [Evidence Audit](https://github.com/030611/qiushi-dsh-evidence-audit). An observe-only, CPU-only, local-only DeepSeek Harness plugin that reports what public runtime interfaces can actually prove about the requesting Agent's context. It retains only the two most recent ordinary agent-loop request observations in memory and exposes them through the existing Cordis inspect query mechanism. It performs no file, network, subprocess, GPU, persistence, session, permission, tool, model-routing, or request mutation. ## Audit verdict Conditional pass against official DSH commit `47f943859bef60e4160492346772ded9b24f765a`. Stable public seams exist for a deliberately incomplete evidence ledger. This plugin is not a complete context p
Read the full READMERepository license: MIT
dsh-context-provenance DSH plugin questions
How do I install dsh-context-provenance?
Run the command `dsh plugin --profile web add dsh-context-provenance` in your DSH environment. You need to have DSH installed and configured with a profile (e.g., 'web'). After adding, restart DSH for the plugin to take effect. The plugin is available as an npm package, so ensure your network can reach the npm registry.
How do I query the evidence report?
Use the existing Cordis inspect tools to query the Host provider named 'ContextProvenance' with method 'report'. The provider appears only when the official Cordis inspect service is present. If your DSH composition lacks that service, the observer still mounts but has no query surface. The report returns evidence fields with labels (Observed, Estimated, Unavailable) and boundary notes.
Does this plugin expose prompt text or message content?
No. The plugin explicitly never returns prompt text, message content, tool schemas, raw paths, or file contents. At the llm/stream boundary, it reduces request bodies to provider/model, booleans, safe categories, tool names, and official numeric projections. System text, messages, tool descriptions, JSON parameter schemas, raw plugin identifiers, and AGENTS paths or contents are all withheld.
What are the privacy implications of the equality fingerprints?
In schema version 1, the plugin returned plain SHA-256 digests of system prompts or tool schemas, which could allow an observer to confirm guesses offline via dictionary attack. Schema version 2 removes those digests entirely. Instead, it uses process-random keyed fingerprints held only in a private WeakMap that are never serialized. The only thing exposed is a boolean indicating whether the system or tool catalog changed between the two adjacent requests. This is a minimal comparison signal the plugin intentionally provides.
Does this plugin affect model requests or token usage?
No. The plugin adds no extra prompt, message, or tool schema to ordinary model requests. It only adds one entry and one method to the existing Cordis inspect provider directory. A deliberate inspect call adds its bounded result to conversation history, which then counts as normal tool-result history. The existing inspect tool schema remains unchanged. Therefore, there is no direct token or KV-cache effect on ordinary requests.