Read-only agent-fleet credential hygiene audit: credential-file permissions, embedded credentials in git remotes (masked in output), and provider token literal counts; zero-dependency and deterministic.
Install
# from GitHub (first run asks for allowBuilds approval — follow the hint, retry)
dsh plugin --profile web add github:LeslieWylie/dsh-fleet-audit
Any plugin you install runs third-party code with your own permissions — it can read your files, use your credentials, and reach the network, and tool approvals don’t sandbox it. GitHub-sourced plugins also run build scripts at install time — pnpm blocks those until you allow them, so an install can stop with ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED or ERR_PNPM_IGNORED_BUILDS; dsh prints the exact key to add under allowBuilds in your profile’s pnpm-workspace.yaml, and the install works on the next run. Allowing a build is a trust decision: only install sources you trust, and pin a commit (github:owner/repo#sha).
README
Read-only agent-fleet hygiene audit plugin for DSH. Zero-dependency, deterministic, fully masked output. Checks three things:
- Credential-file permissions — well-known credential files (
~/.gitconfig,~/.netrc,~/.npmrc,~/.env,~/.ssh/) should be600/700; group/other-readable entries are flaggedtooOpen - Embedded credentials in git remotes — scans
~/.gitconfigand.git/configunder the given roots forhttps://user:pass@host,https://oauth2:TOKEN@host, or token-like usernames; values are masked as***in the output — byte-for-byte guarantee that the raw secret never appears - Provider token-prefix literals (optional) — github / github-fine-grained / gitlab / gitlab-ci / slack / aws / openai / jwt prefixes, reported as provider × count only
Why
On a multi-agent machine, credentials scatter across ~/.gitconfig, agent configs, .git/config files and various .env. A git url.*.insteadof or pushurl with an embedded token (e.g. https://oauth2:<token>@gitlab.example.com/...) means git remote -v prints the secret into every log, chat, and CI build. A one-shot read-only audit with masked output is the first line of a security baseline.
Install
# local validation
dsh plugin --profile web add /path/to/dsh-fleet-audit
# after publishing
dsh plugin --profile web add dsh-fleet-audit
# or
dsh plugin --profile web add github:LeslieWylie/dsh-fleet-audit
Restart dsh web after installing, then just ask: "audit credential hygiene on this machine" → the agent calls fleet_audit.
Tool parameters
| Param | Type | Description |
|---|---|---|
roots |
string[] | directories to recursively scan for .git/config (optional; default: only ~/.gitconfig) |
files |
string[] | extra absolute credential-file paths for permission checks |
scanSecrets |
boolean | scan configs for token-prefix literals (default true) |
maxGitConfigs |
number | cap on scanned git configs (default 200, max 2000) |
maxDepth |
number | recursion depth for .git discovery (default 5, max 20) |
Sample output (masked)
{
"ok": true,
"summary": { "files": 5, "tooOpen": 1, "gitLeaks": 2, "secretFiles": 1, "issues": 4, "scannedGitConfigs": 12 },
"checks": {
"credentialFiles": [
{ "path": "/Users/alice/.gitconfig", "exists": true, "mode": "644", "tooOpen": true }
],
"gitRemoteLeaks": [
{ "file": "/Users/alice/code/proj/.git/config", "host": "gitlab.example.com", "maskedUrl": "https://***:***@gitlab.example.com/group/proj.git" }
],
"secrets": [
{ "file": "/Users/alice/.gitconfig", "providers": [ { "provider": "github", "count": 1 } ] }
]
}
}
Safety boundary
- Read-only: no writes, no process spawn, no network, no state
- Masked: every secret-like value is masked; tests assert the raw secret never appears in the output JSON
- Bounded: git-config count and recursion depth are capped
Dev
npm install
npm run check # typecheck + vitest + build
Known limitations
- Textual config files only (no encrypted stores, keychains, or binaries)
- Token-prefix matching is heuristic: false negatives (unusual prefixes) and positives (manual review needed) are possible
- Default checks cover a fixed credential list; pass
roots/filesto cover arbitrary paths - The plugin never modifies anything; after a finding, run
chmod 600and rotate the credential yourself
Rollback
dsh plugin --profile <p> remove dsh-fleet-audit # or drop the row from dsh.profile.bundles
The plugin is read-only and stateless; uninstalling it never touches user data.
Independent community plugin
This project is an independent community plugin with no affiliation to DeepSeek or its official DSH repo; "official" status is only granted through official channels. The dsh-plugin topic will be added for discoverability at release time.
License
MIT © LeslieWylie
Links
More in this category
toby-bridges/api-relay-audit★ 860
Runs local security audits of AI API relays and LLM proxies from DeepSeek Harness, producing Markdown reports for prompt injection, model substitution signals, tool-call rewriting, error leakage, stream integrity, and profile-gated Web3 risks.
SeaOf0/dsh-redteam-model★ 638
Authorized-security DSH collection: nine work modes (redteam coordinator, pentest, code audit, binary analysis, attack-defense, AV evasion, incident response, cloud security, CTF solving) and fifteen runtime plugins, managed from a settings page with one-click deploy, install, update and uninstall.
howmp/dsh-pentest★ 558
Authorized pentest mode for DeepSeek Harness — exploration chain, assets and findings with a Web view.
PerryLink/dsh-auto-review★ 206
Second-model auto-review on the approval answerer chain: a read-only reviewer subagent returns structured allow/deny verdicts with reasons, fail-closed by default.
NanmiCoder/dsh-auto-mode★ 163
Adds an Auto permission preset between Workspace Write and Full access: routine work stays in the official workspace-write sandbox while the current session model reviews escalation and destructive calls, granting one exact wider access once, asking when the intent is ambiguous, and denying critical paths.
PerryLink/dsh-permission-rules★ 114
Claude Code-style declarative permission rules: ordered allow/deny/ask YAML rules matching tool names, arguments, workspace paths, and agent identity on the tools/pre-execute waterfall, with full session-log audit, dry-run mode, and hot reload.
Community comments
Comments are public GitHub Discussions. Loading them connects to GitHub and Giscus; a GitHub account is required to post.