I’ve been spending a lot of time experimenting with agent workflows that need access to real services. Stripe test mode, internal APIs, automation systems, things like that.
One pattern kept making me uneasy.
Most setups hand credentials directly to the agent process and then rely on prompts, tool wrappers, or good behaviour to keep things under control. That works for demos. It starts feeling brittle pretty quickly once the workflows become more autonomous.
So I built tsk.
It’s a local-first MCP server that sits between an LLM agent and the APIs it interacts with. The idea is simple: the model shouldn’t have direct access to credentials in the first place.
Secrets live in <code>~/.tsk/.secrets</code>, outside the project directory, and access is controlled through a <code>rules.yaml</code> allowlist that defines which API actions are actually permitted. tsk then exposes only those approved operations as MCP tools.
A few things happen at runtime:
<ul>
<li>credentials get injected without being exposed to the agent itself</li>
<li>sensitive values are scrubbed from responses before they reach the model</li>
<li>tool-level rate limits are enforced</li>
<li>every call is written to a local SQLite audit log</li>
</ul>
The main goal was separating policy enforcement from the model layer entirely.
A hallucinated tool call, prompt injection, or even a typo shouldn’t quietly trigger privileged API requests with full credentials attached. That became especially obvious while testing longer-running autonomous workflows.
I also wanted the setup to stay lightweight:
<ul>
<li>single Go binary</li>
<li>no daemon</li>
<li>no cloud dependency</li>
<li>no account system</li>
</ul>
It uses STDIO MCP, so it works with Claude Code, Claude Desktop, OpenClaw and other MCP-compatible agents.
Current features:
<ul>
<li>HTTP tools</li>
<li>bearer and header authentication</li>
<li>per-tool rate limits</li>
<li>scrubbing for emails, IBANs, credit cards, and custom regex patterns</li>
<li>SQLite activity logging</li>
</ul>
Releases include SBOMs and SLSA attestations, and the installer can verify checksums and attestations automatically during install.
Install:
<code>curl -fsSL https://tesserak.dev/install.sh | sh</code>
or
<code>go install github.com/tesserakdev/tsk/cmd/tsk@latest</code>
Repo: <a href="https://github.com/tesserakdev/tsk" target="_blank" rel="noopener nofollow">https://github.com/tesserakdev/tsk</a>
I’d genuinely appreciate feedback, especially around the <code>rules.yaml</code> structure and the default scrubbing behaviour. Feels like we’re still collectively figuring out what a practical security boundary for autonomous agents should actually look like.

Lukas

tsk is a local-first MCP server written in Go that acts as a security proxy between LLM agents and external APIs. Instead of handing credentials directly to agent processes, secrets are stored outside the project directory and access is controlled via a rules.yaml allowlist. At runtime, credentials are injected without being exposed to the model, sensitive values are scrubbed from responses, per-tool rate limits are enforced, and all calls are logged to a local SQLite audit log. It ships as a single Go binary with no daemon or cloud dependency, supports STDIO MCP, and works with Claude Code, Claude Desktop, and other MCP-compatible agents.

Running autonomous agents without exposing credentials directly