Comment by FrinkleFrankle
4 days ago
MCP is a tool more for security than anything else. If you give your agents access to an API key, there's a chance they can accidentally or maliciously leak that key. If the MCP server has access to the keys instead, it takes that possibility away. That's not always something you need to care about, but it is very important for some people's threat model.
> MCP is a tool more for security than anything else. +1 to this; API keys mean: a) Your agents are overprivileged by default b) Your API key is more likely to get into logs and pre-training / leaked as FrinkleFrankie mentioned c) You can't manage it centrally with granular tool policies in Enterprises. (e.g. "you're not allowed to read slack channel for #finances")
Also, you can always collapse MCP to CLI, so MCP as auth/security middleware makes a lot of sense.
PoC of MCP -> CLI: https://github.com/edison-watch/cli
> MCP is a tool more for security than anything else.
The agent can get to the resource through the MCP server or using API key. I personally do not see the benefit MCP is providing here. Sure you can reduce the exposed surface at MCP layer, but I do that at the API layer. I don't need to add another layer here.
I can kinda understand if you do not have control of the API layer and/or you have to expose the API layer to the public Internet as well. Most of the time that is not the case for me.
The idea is that with an MCP, the agent doesn’t have access to any credentials. It can’t leak an API key.
There are many ways to do this without using mcp, for example one of the many proxy servers that inject the token into requests. I use a custom solution that redacts all secrets to agent transcripts before the agent sees them in a hook.
I find it way better to be able to confidently tell agents to use CLIs than worrying about partially implemented mcps that need configuration and are often yolo’d with npx @latest anyway
Sooo, how does the agent authenticate with the MCP server?
My own approach is to put the API key in the MCP server, apply principle of least privilege there, and firewall access to MCP with agents being on same private network with Tailscale.
Not only giving an API key to an agent can leak to the model because of harness issues or too broad reading rights, but also most providers don't give the ability to apply principle of least privilege to an API key.
I don't want to give an agent full R/W access to any of my services/accounts.
The agent doesn't, the harness does. It's separate from a normal conversation / agent runtime environment. How do you suspect auth keys can leak from an MCP that's been added to chatgpt.com?
With a different key, obviously. This lets you keep the MCP server firewalled to your local network only while still allowing home assistant itself to access the internet
You give it a key of course! And if that doesn’t fit your security model and threat vectors, simply give the key to another MCP.