I don’t want remote MCP calls, I don’t even want remote models but that’s cost prohibitive.
If I need to call an API, a skill with existing CLI tooling is more than capable.
But I agree with the author on custom CLI tooling. I don’t want to install another opaque binary on my machine just to call some API endpoints.
I suppose that curl + API docs could replace a CLI but that's really token inefficient
Step 1) run a small daemon that exposes a known protocol over a unix socket (http, json-rpc, whatever you want), over a unix socket. When I run the daemon, IT is the only that that has the secrets. Cool! Step 2) Have the agent run CLI that knows to speak that protocol behind the scenes, and knows how to find the socket, and that exposes the capabilities via standard CLI conventions.
It seems like one of the current "standards" for unix socket setups like this is to use HTTP as the protocol. That makes sense. It's ubiquitous, easy to write servers for, easy to write clients for, etc. That's how docker works (for whatever it's worth). So you've solved your problem! Your CLI can be called directly without any risk of secret exposure. You can point your agent at the CLI, and the CLI's "--help" will tell the agent exactly how to use it.
But then I wondered if I would have been better off making my "daemon" an MCP server, because it's a self-describing http server that the agent already knows how to talk to and discover.
In this case, the biggest thing that was gained by the CLI was the ability of the coding agent to pipe results from the MCP directly to files to keep them out of its context. That's one thing that the CLI makes more obvious and easy to implement: Data manipulation without context cluttering.
Sure, if I want my agents to use naked curl on the CLI, they need to know secrets. But that's not how I build my tools.
what i see is that you give it a pass manager, it thinks, "oh, this doesn't work. let me read the password" and of course it sends it off to openai.
The fact that it doesn't see it and cannot access it.
Here is how this works, highly simplified:
def tool_for_privileged_stuff(context:comesfromagent):
creds = _access_secret_storage(framework.config.storagelocation)
response = do_privileged_stuff(context.whatagentneeds, creds)
return response # the agent will get this, which is a string
The agent never accesses the secrets storage. The tool does. The tool then uses the secret to do whataever privileged work needs doing. The secret never leaves the tool, and is never communicated back to the agent. The agent also doesn't need, or indeed can give the tool a secret to use.
And the "privileged work" the tool CAN invoke, does not include talking to the secrets storage on behalf of the agent.
All the info, and indeed the ability to talk to the secrets storage, belongs to the framework the tool runs in. The agent cannot access it.
Your agent process has access to those secrets, and its subprocesses have access to those secrets. The agent doesn't have to be convinced to read those files. Whatever malicious script it manages to be convinced to run could easily access them, right?
Well yes you don’t need those things all the time and who knows if the inventor of mcp had this idea in mind but here we are
I do not want agents using the same elevated auth I have via my CLI tooling. One hallucination with your gh cli and the blast radius is every repo you have write (or worse, admin) access to.
MCP lets you scope tokens down (on supported platforms), or at minimum gives you something you can revoke independently.
Although, I think MCP is not really appropriate for this either. (And frankly I don't think chatbots make for good UX, but management sure likes them.)
The story for MCP just makes no sense, especially in an enterprise.
MCP is basically just an RPC API that uses HTTP and JSON, with some other features useful for AI agents today.
If you use the official MCP SDK, it has interfaces you implement for auth, so all you need to do is kick off the OAuth flow with a URL it figures out and hands you, storing the resulting tokens and producing them when requested. It also handles using refresh tokens, so there's just a bit of light friendly owl finishing on top.
Source: I just implemented this for our (F100) internal provider and model agnostic chat app. People can't seem to see past the coding agents they're running on their own machines when MCP comes up.
This might help if interested - https://vectree.io/c/implementation-details-of-stdio-and-sse...
You absolutely DO want to run everything related to LLMs in a sandbox, that's basic hygiene
What about auth? Authn and authz. Agent should be you always? If not, every API supports keys? If so, no fears about context poisoned agents leaking those keys?
One thing an MCP (server) gives you is a middleware layer to control agent access. Whether you need that is use-case dependent.
How would MCP help you if the API does not support keys?
But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to?
You ARE running your agents in containers, right?
Kerberos, OAuth, Basic Auth (username/password), PKI. MCP can be a wrapper (like any middleware).
> But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to?
If the cli can access the secrets, the agent can just reverse it and get the secret itself.
> You ARE running your agents in containers, right?
Do you inject your keys into the container?
What do you mean by this? How "reverse it"? The CLI tool can access the secure storage, but that does not mean there is any CLI interface in the tool for the LLM to call and get the secret printed into the console.
We could use suid binaries (e.g. sudo) to prevent that, but currently I don't think we can. Most anyone would agree that using a separate process, for which the agent environment provides a connection, is a better solution.
MCP looks like it would then fit that purpose, even if there was an MCP for providing access to a shell. Actually I think a shell MCP would be nice, because currently all agent environments have their own ways of permission management to the shell. At least with MCP one could bring the same shell permissions to every agent environment.
Though in practice I just use the shell, and not MCP almost at all; shell commands are much easier to combine, i.e. the agent can write and run a Python program that invokes any shell command. In the "MCP shell" scenario this complete thing would be handled by that one MCP, it wouldn't allow combining MCPs with each other.
Maybe an "agent shell" is what we need.
Other comments have claimed that tools are/can be made "just as secure" - they can, but as the saying goes: "Security is not a convenience".
they are just a superior tool to MCP because the agent can write code that invokes, pipes and do many other things with the tool