Your MCP Gateway Can't See Most of What Your Agent Does - OneCLI<br>Blog<br>Watch a coding agent work for ten minutes. It opens a pull request with gh, hits an API with curl, and when neither does the job it writes a Python script and runs that. Three trips to external services, and not one of them is an MCP tool call.<br>If your agent security is an MCP gateway, you just watched ten minutes of ungoverned traffic, and your dashboard stayed green. The real problem is not the gap but the confidence: the gateway is up, the policies are configured, the box is checked. The gateway isn't broken. It is standing at the wrong layer, and it has no way to tell you what it isn't seeing.<br>How you got here<br>Nobody deploys an autonomous agent. They adopt an assistant. On day one, they approve every action. By week two, approving file reads is tedious, so those get auto-accepted. By month one, it's “just let it run the tests.”<br>By month three, it's --dangerously-skip-permissions in a tmux session over the weekend, because the agent is good and babysitting it has become the bottleneck.<br>At no point did anyone make a decision called “give an autonomous agent production credentials.” The autonomy arrived one convenience toggle at a time, while the environment never changed from day one: real keys in env vars, a full shell, open egress. The security control that actually existed was human attention, and it was quietly traded away for velocity , because trading it away is the entire point of these tools. Every coding agent ships with an autonomy dial, and every user turns it up. The question is whether your security holds at the setting you'll actually use, not the setting in the demo.<br>How agents actually reach services<br>An agent with shell access has at least four ways to hit an external API.<br>MCP tool calls. These are structured and easy to govern if you proxy the protocol. This is the slice MCP gateways cover.<br>CLI commands. gh, aws, stripe, vercel, kubectl. Agents are startlingly good at these. Peter Steinberger, creator of OpenClaw, put it bluntly: “Agents are really, really good at calling CLIs (actually much better than calling MCPs).” Andrej Karpathy made the same point: CLIs are exciting precisely because they're a “legacy” technology that agents can natively use. There's a whole genre of posts now arguing that the CLI is the new MCP.<br>curl. When no tool or CLI exists for the job, the agent shells out and improvises a single hand-assembled HTTP call.<br>Code it writes itself. This is usually a Python script with requests or a Node script with fetch. For coding agents it is the default mode of work.<br># one agent session, three minutes apart:<br>gh pr merge 482 --squash # CLI<br>curl -X POST api.stripe.com/v1/refunds # improvised shell call<br>python retry_failed_webhooks.py # code it just wrote<br># one agent session, three minutes apart:<br>gh pr merge 482 --squash # CLI<br>curl -X POST api.stripe.com/v1/refunds # improvised shell call<br>python retry_failed_webhooks.py # code it just wrote<br>Here is the part that makes this structural rather than incidental: to the agent framework, those last three are all one tool: bash. From the tool layer's perspective, each of them is just “ran a shell command.” The tool layer cannot tell you which credential was used, which host was reached, or what the payload contained, because at that layer those details do not exist as distinct events. The only place those three actions look like what they actually are is on the wire, as authenticated requests to GitHub, Stripe, and wherever the script points.<br>An MCP gateway can't be extended to cover this. There is nothing at its layer to extend into.<br>Coverage disappears exactly when risk peaks<br>So the gateway intercepts one protocol. The gh command doesn't pass through it. Neither does the curl call, or anything the Python script does. Those requests go straight to the service, authenticated with whatever credentials the process could reach: environment variables, config files in the home directory, CI secrets. None of those calls get a policy check, a rate limit, an approval flow, or an audit line. The attack surface hasn't shrunk. The unguarded part of it has moved out of view.<br>But the timing is worse than the coverage. Agents route around failure by design. That is their value proposition. A tool is missing, an MCP server is down, a rate limit trips, and the agent finds another way: it shells out and improvises. The governed path failing is precisely the trigger for the ungoverned path. Your enforcement coverage is inversely correlated with how much you need it.<br>An MCP gateway sees the agent's best behavior and misses its improvisation. Improvisation is where incidents live.<br>Enforce on the wire, not on the interface<br>If enforcement sits at the network layer, the calling mechanism stops mattering. Every outbound HTTPS request from the agent's environment, whatever produced it, passes the same choke point, and the same three things happen to it.<br>Credential injection. The request...