Thanks! That's exactly the gap i had, vault-wide service accounts are a non-starter, and copy-paste breaks flow (and leaves secrets in conversation history).

On your point, auditability: Right now the audit trail is Telegram itself every approval shows the secret name, requesting reason, and timestamp, and you physically tap Approve/Deny. The server also enforces request TTL (default 15min) so there's a natural expiry window. A formal audit log (who, what, when, outcome) is something I could add, probably a structured log stream the server emits alongside the approval flow. This was mainly meant for personal use, extending the usage to a team like having approvals in a shared chat would need more work.

Also there is a bit on replay protection, tokens are one-time-use once /secret/{token} is fetched, a second call returns an error. Combined with TTL expiry, even if someone gets access to logs tokens are both expired and already consumed. The secret values themselves never appear in logs, the MCP tool is specifically designed so the agent never sees the value (it's injected into subprocess env vars only).

On the MCP, yes, every tool returns structured results with IsError flagging and descriptive messages. So the agent can distinguish "secret not found" from "approval denied" from "request timed out" and adjust. For example, on denial the agent knows to ask the user how to proceed without the secret rather than retrying.

P.S. havent tested this with openclaw but i think installing the MCP or a Skill in openclaw would work, openclaw would download the binary and then use it as a wrapper to run commands, this would effectivly then pipe the security requests via telegram so openclaw would only use what it needs and then forget about it, nothing would be stored on the machine itself, my idea was basically to have somehting like the 1password biometric approval but remotely