CLI, MCP, and agentic workflows
Shhhs gives humans a web app, operators a CLI, teams a scoped API, and agents a local MCP adapter. The job is the same everywhere: create a short-lived encrypted handoff without leaking plaintext into the wrong system.
01
The shhhs CLI is built for shell-driven workflows: create encrypted pushes, request links, burns, vault lookups, event delivery checks, account checks, and package inspection from scripts or terminals.
02
shhhs-mcp runs as a local stdio adapter. It exposes tools for encrypted pushes, request links, submissions, and burns while keeping account material on the user's machine.
03
Instead of pasting credentials into prompts, one agent can create a temporary encrypted link or request link and another agent can submit through that controlled channel.
04
Team API keys are scoped separately from human login. API v1 is described by OpenAPI and protected by Cloudflare API Shield schema validation before requests reach the Worker.
05
Enterprise extends the same model into customer admin, Microsoft and Google lifecycle hooks, browser extension enrollment, and an outbound on-prem agent for internal IAM events.
06
Automation does not mean Shhhs reads secrets. Prompts, logs, audit, support, event notifications, and connector logs should contain metadata and ciphertext only.
Use shhhs for terminals, scripts, CI, and operator runbooks. Use shhhs-mcp when an agent runtime needs local MCP tools for encrypted secret handoffs.
No. Secret creation flows encrypt locally before upload. The MCP adapter should run locally and must not be exposed as an unauthenticated remote service.
Yes. Team automation should use scoped API keys, stdin for secret input, JSON output for scripts, and short TTL/view limits.
Yes. The safer pattern is a request link: one agent creates it, another submits into it, and the owner reveals from the Shhhs console.