dsh-agentvalet

When agents on DeepSeek Harness need to call Slack, GitHub, Gmail, Stripe, or other SaaS platforms, the common approach is to place API keys directly on the agent host. A single leaked credential has a large blast radius, and the call chain offers no governance layer: nobody can answer who approved what, when, or whether a request should have been denied. dsh-agentvalet routes every platform call through the AgentValet broker. The agent host holds only an RS256 signing private key (file mode 0600, refused inside any git working tree), while all platform credentials live exclusively at the broker. There is no Slack token or GitHub secret on the local machine to steal.\n\nThe grant model is deny-by-default. After binding, the agent can invoke nothing until the owner approves specific platforms and scopes in the dashboard. Write operations (POST, PUT, PATCH) and deletes (DELETE) can be gated behind an owner approval flow. The plugin exposes four structured tools—list_platforms, read_platform, write_platform, delete_platform—that all return a uniform { ok, data } or { ok, error } shape, so the model can read and explain a denial, a pending approval, or a suspended identity without parsing exception traces. Enrolment uses a single-use bootstrap token; re-running connect on an already-bound profile is refused, preventing one agent audit history from being laundered into another identity.\n\nThis plugin is built for developers and security teams running agents on DeepSeek Harness who need safe, auditable access to enterprise SaaS. It does not ship a local policy engine, does not provide sandboxing, and does not implement sub-agent delegation or attenuated scope re-issue. It does one thing well: ensure every platform call is governed by the owner grants and approvals, pairing with a sandbox rather than replacing it.