The stop pasting env files part hits home . Sharing secrets directly through the editor sounds a lot safer. How are you handling access control for the MCP server?
Stop pasting .env files in Slack. I built an MCP server to share secrets directly from code editor
7 Comments
@[Taylor Barkhouse] Glad that resonates.
MCP is gated by your Whisper API token - you add it when you connect the MCP server, and every create call uses that key.
Secrets are encrypted locally in the MCP client before anything leaves the editor.
Whisper only stores ciphertext. Same zero-knowledge model as the web app.
Please log in to add a comment.
Good defaults: the key lives in the URL fragment and links self-destruct after one view.
One thing I checked in the published MCP package (v1.0.0): create_secret_link takes the secret as secretText, so the model has to write the plaintext into the tool call. That means it passes through the AI provider before the local encryption runs. The tool also returns the full URL, #key included, into the chat transcript.
A filePath input, read by the local server, and returning the link to the clipboard instead of the model would close both.
@[jaafarabazid]
Yeah, fair point on the mechanics.
secretText is on purpose. Most of the time the file is already in context (@.env and friends), so the model saw the plaintext before the tool call.
Stuffing it into the tool args isn't really a new leak in that flow. It's just how MCP tools take input.
Whisper still only gets ciphertext, encryption runs locally in the MCP process.
Same deal with returning the full URL, #key included.
That URL is what you're meant to copy into Slack or wherever.
Anyone who can read that chat can open the secret until it burns.
That's the “key lives in the fragment” model, not an MCP quirk.
Burn-after-read cleans up the share link. It doesn't wipe every place you pasted it.
I did look at filePath, clipboard, intermediate browser pages. They hide more from the model, sure.
They also make the UX worse (goodbye whatever was on your clipboard, extra steps) and they don't change the threat model we already accept when people share links in chat.
So I stuck with the boring path: encrypt locally, return the link, you paste it.
Maybe I'll add an optional filePath later for people who don't want the model to touch file contents at all. For v1 this matches how people actually use it.
Thanks for the thoughtful reply @[mikehoh], the @.env point is a good one. If the file is already in context, the tool call adds nothing new, and I hadn't weighed that.
Maybe just a small line in the README for the MCP flow, noting that the AI provider sees the text first, so anyone sharing something especially sensitive knows the web app is the safer route. Nice work on this, and I'll keep an eye out for the filePath option.
Please log in to add a comment.
Please log in to comment on this post.
More Posts
- © 2026 Coder Legion
- Feedback / Bug
- Privacy
- About Us
- Contacts
- You Tube
- Tiktok
- Premium Subscription
- Terms of Service
- Early Builders
Webix Soft owner.
Founder @Pharmory
Founder @Whisper
Related Jobs
- Azure DevOps (Infra As Code) EngineerHAN Staffing · Full time · Iselin, NJ
- Senior Fullstack Software Engineer, ProfilesRoblox · Full time · San Mateo, CA
- Sr Web Developer SharepointHorizon Consulting Llc · Full time · Thailand
Commenters (This Week)
Contribute meaningful comments to climb the leaderboard and earn badges!