Beyond MCP: The New Security Playbook for Coding Agents

There has been tremendous progress in agentic coding tools recently. There are a large number of coding agents out there, some created by startups already valued in the multi-billion range. Some agents themselves bring multi-billion-dollar revenue, Claude Code. Evaluating performance is still a bit of a dark art, but there is widespread agreement that there was an “inflection point” in late 2025 where agentic coding performance had a step improvement. Somewhere between better models and better “harnesses”, agents seem to be getting stronger every day. 

As with any new technology, maturity and increased use bring back to the forefront the security ramifications that typically are ignored in the early days of excitement and experimentation. There have already been quite a few widely publicised incidents (antigravity, copilot, ChatGPT, cursor, comet) that helped put these risks into perspective. Users and customers are getting worried, and vendors are paying more attention to security. 

A brief anatomy of an agent 

The main component of an agent is the agentic “loop” where the agent asks an LLM questions based on its system prompts, current state, and context, and takes actions based on the LLM’s responses. Some external input to the agent triggers the loop and continues until the agent believes it has reached the right answer. Below this simple picture, there is a lot of complexity involved  (context and memory management, for example), and this complexity is managed by code that is typically described as the agent’s “harness”. Popular as it may be, we will not go into details about the harness here. 

But one aspect of the harness is important for security: agents use “tools”. An agent needs to get additional information in order to operate and, in many use cases, needs to interact with its environment. A coding agent, for example, will need to look into your JIRA tickets or pull request reviews. It will also need to commit to git and possibly create pull requests in GitHub.  All these happen through tool use under the guidance of the LLM. 

A tool is quite broadly defined. Most will think about Model Context Protocol (MCP) tools, an early innovation by Anthropic that was later widely adopted and recently became an official project of the Linux Foundation. In the MCP model, tools are provided by an MCP “server” that implements the required functionality. In the GitHub context above, GitHub will provide its own MCP server that handles authentication and other tricky aspects and implements specific tools like “CreatePR”. These tools (and their description) are made available to the LLM, which can then decide when to use them. 

MCP is not the only way to use tools: in the GitHub example above, the agents can also use the gh cli tool. Agents are capable of running commands in a terminal and using the CLI for various packages. In fact, there is an interesting  “MCP vs. CLI” debate going on right now in the industry. 

Independent of the actual mechanics, tools vastly complicate the security model of an agent:

MCP tools bring “input” risks: 

• They are interfaces to external inputs, and these inputs can be malicious 

• In some cases, the MCP server executes in the agent’s environment, so, like a malicious dependency, it can do harm or steal data. 
• The tool metadata are essentially parts of the prompts sent to the LLMs and can be used for prompt injection attacks.  
• Plenty of real and theoretical attacks have been discussed in multiple places (this and this are good high-level overviews) and demonstrated. 

CLI and terminal usage bring “action” risks:

• The agent may destroy its environment (by deleting lots of files, for example) 
• The agent may access information that it is not supposed to (maybe as a result of a malicious prompt) 

Since we are talking about agent risks, there is no way to ignore “skills”, another innovation (again by Anthropic) that has become extremely popular. Skills are essentially instructions for the agent that provide guidance on how to perform some more niche tasks (like parsing PDFs or working with some genetic material databases). There is no need to go into too many details, but suffice it to say that skills are another major input risk, since they can contain anything, including, of course, prompt injection attempts. 

So, effectively, an agent is a system that accepts a request and, while figuring out the answer, can access (through its tools) a variety of other sources and take actions that can affect its environment. It is not hard to see the outlines of the threat model here. A recent popular take on this is the lethal trifecta, where the combination of three factors can create a security nightmare:

• Access to private data 
• Exposure to untrusted content
• Ability to communicate externally 

In this case, the typical attack will be sending the agent some malicious instructions that will make the agent access some of the private data and exfiltrate it to the adversary. All the attacks mentioned above were variations of this theme. 

(A brief but important aside here: The real underlying problem is the susceptibility of LLMs to “prompt injections”, that is, malicious commands. Despite their tremendous progress, LLMs can still not reliably distinguish between data and instructions. It is still possible to have your agent navigate to a malicious web page that contains a “delete everything” instruction hidden in the text, and the underlying LLM may choose to follow it. This is a hard problem to solve, and despite its importance, there is surprisingly little progress on it, but this is a topic for another day.) 

So, how do we secure the agents?

The lethal trifecta provides a good threat model framework and can refine the security posture of an agent as a combination of the following settings:

• Execution Environment: local (e.g., on a developer’s laptop), CI, in a cloud service 
• External request: trusted, untrusted
• Inputs (MCP tools, Skills, commands): trusted, untrusted 
• Data Access: has access to  private data, does not have access to private data
• Connectivity: the agent can connect to the “outside”, cannot connect 

To make an agent “secure by design”, we “just” need to make sure that one of the three conditions (1) exposure to untrusted input, (2) access to private data, (3) ability to communicate with the outside world, is not true. For example, an internal agent that has access to privileged data but gets only trusted inputs, has access only to trusted tools, and has no external connectivity should be safe. Also safe is a public agent that can receive untrusted input but has no access to private data. 

Of course, in real life, due to oversight or bad design, an agent may end up with the wrong combination of the above values. Thus, there is a huge amount of effort in the industry right now to come up with mechanisms to secure the agent’s operation. 

The first solution that the agent vendors came up with was to have the agent’s user review and approve all potentially dangerous agent actions, e.g., when calling shell commands. Obviously, this can dramatically reduce the effectiveness of using these agents, and all agent platforms readily provide knobs to turn these restrictions off. Something similar happens with network communication: in order to prevent the agent from exfiltrating private data, one can provide an allow list of network addresses that the agent can communicate with. Both are clearly stopgaps and not a real solution. 

The more comprehensive approaches to securing agents can be broadly grouped into three categories:

• Run the whole agent (and its tools) inside a sandbox. This isolates the agent from its environment and, in principle, allows for monitoring all the agent's interactions with the environment (including network activity) and potentially blocking unsafe interactions and applying related policies. 
• Secure the MCP tools with some kind of MCP proxy/gateway. This focuses on securing and monitoring the MCP subsystem (and may involve using a sandbox) but does not cover other potentially risky agent activity like network communication or command-line actions.
• A recent emerging approach is to use hooks to monitor, audit, and possibly block risky agent activity through the hook callbacks. Using hooks, it is possible to audit various agent activities before they happen and block them if they are unsafe or violate policies (e.g., tool calling or shell command execution). 

Let's take a closer look at all these approaches. 

Sandboxes 

In principle, sandboxes provide a “complete” solution since they can achieve isolation of the executing agent from its environment. At the same time, sandboxes are “heavy” in the sense that they require lots of configuration to set up, have underlying OS dependencies, and can also introduce execution time overhead, slower times to start, and so on. Sandboxes can run in full Docker containers or VMs, but many new and lighter technologies have emerged recently, and there are multiple vendors offering sandbox hosting. 

All the major coding agent vendors offer a sandbox solution for local development [claude-sandbox, openai-sandbox, cursor-sandbox]. Support for multiple computer architectures is somewhat limited, however.  macOS is one of the prime targets since it is a popular development platform, and all the above approaches use Seatbelt to implement a light application sandbox in macOS.  Newer work from Anthropic on sandbox-runtime uses sandbox-exec in macOS and bubblewrap in Linux. 

Sandboxes can also be hosted in cloud infrastructure. Recently, Google described its strategy for offering sandbox support in Kubernetes. There are already multiple sandbox providers like Runloop, Daytona, Leash, Openhands, Prime-intellect, and Modal, with more on offer. This article provides examples of how to run agents inside sandboxes from multiple providers.

All in all, there has been lots of activity in sandbox technology, and this will definitely continue in the future as vendors try to find the right balance between simplicity, performance, and strong isolation. There have already been some “sandbox escape” attacks:  cursor-tunnel, cursor-pillar, some limitations on enforcing sandbox checks, and even some research about the capability of LLMs in escaping sandboxes.

While sandboxing provides isolation, more pieces are required for a complete agent security solution. For one, it is not clear how much coupling should be between the (potentially application-agnostic) sandbox and the agent running inside it. Policy control is a necessary component to provide fine-grained control over which of the agent’s interactions with its environment will be allowed or blocked. The policy element of the various sandbox solutions is even less mature at this time, with no clear emerging standard. OPA is a common policy framework, but newer frameworks like cedar have also emerged. Additional usability problems remain even beyond isolation and policy control. For example, remote sandboxes will need to access potentially local resources (e.g., source code on a developer’s laptop). How to do this safely and efficiently (without having to copy all the source code to the sandbox each time the agent starts) is still an area of active investigation. For more information, this is an excellent source of information about sandboxes for AI.

MCP “Gateways”

Given the importance of the MCP tool subsystem, there has been a lot of activity around securing it, taking various approaches:

• Since MCP tools are dependencies, MCP tool registries can provide vetted MCP tool implementations that have been scanned for security issues. There are already plenty of these registries created.
• Since MCP tools can contain malicious code, some security solutions scan the source code of the tools in an attempt to detect malicious code.
• Since MCP metadata can be used for prompt injections, some security solutions check these metadata to ensure that they are prompt injection-free. Other solutions ensure that the MCP tool metadata does not change over time (so that initial legitimate tool metadata are not replaced by malicious ones later in an attack, sometimes called “rug pull”) 
• Since MCP tools can contain malicious code, some type of sandbox isolation is required to prevent damage to the underlying execution environment 
• Since MCP tools can perform potentially risky operations, some form of policy control will be needed to audit and prevent risky activity. 

Recently, the trend has been to combine one or more of the above functionalities into MCP “gateways” or “proxies”, e.g., mint, Microsoft, pulse, prompt-security, and more from this overview.  These gateways become single choke points where administrators can apply controls and policies to secure the MCP tools they use. MCP tool users are directed to the MCP gateway that serves tools from multiple MCP servers. 

Earlier this year, we explored the design space of MCP gateways in an internal project. We wanted to build a lightweight sandbox that isolates MCP tools from their environment, but uniquely also isolated MCP servers from each other. MCP server executions share the same memory space, creating the opportunity for cross-MCP server attacks. We ended up using two similarly named but distinct isolation technologies, FireJail to isolate MCP tool instances and all the MCP servers and tools run inside a lightweight FireCracker VM, thus naming our system FireMCP.

An MCP proxy hides the details of the individual MCP servers and can provide a single MCP server view to the users of the MCP tools (although we did not implement this). A variety of security tools can run inside the FireCracker VM, implementing security controls for all the hosted MCP servers/tools. Security policies control the levels of isolation between the FireCracker VM and the underlying host. This prototype gave us valuable insights into how to configure and operate an MCP gateway. You can find the source code for this project at https://github.com/dimitris-nik/FireMCP. 

MCP gateways certainly provide a meaningful mechanism for auditing and securing MCP tool use. Beyond security, MCP gateways can provide other useful functionality like intelligent tool selection (there may be multiple tools providing similar services from different providers with different cost structures) and tool auto-discovery and filtering (since eventually there may be 100s of MCP tools, with only a few applicable to each agent/use case). 

MCP gateways do have limitations. There is administrative complexity in configuring and operating such gateway(s) in an enterprise environment. Perhaps more importantly, these gateways secure only the MCP tool subsystem, but not the agent itself. The agent can still misbehave even though it is using MCP tools securely, e.g., it can still fall victim to a prompt injection attack and perform malicious shell commands without involving any MCP tools.  MCP gateways are ideal for cases where the agent itself or its inputs can be trusted. 

On the other hand, an MCP gateway like our FireMCP experiment is already a full-blown sandbox, so it is fairly simple to actually run the agent itself inside this sandbox and benefit from the isolation and policy control available in this environment while also taking advantage of the stricter MCP tool isolation. In this light, maybe the difference between the sandbox and the MCP gateway approaches for protecting agents is rather small. Or alternatively, running the agent inside a system like FireMCP combines the best from both approaches. 

Hooks 

Agent hooks are another relatively recent mechanism that has quickly become very popular. Hooks enable calling third-party handlers when the agent is taking various actions, most importantly for security, before or after taking potentially risky tool actions (MCP and command line), as well as file and other resource access. Since some hooks are called before the agents take actions, potentially risky actions can be blocked under policy control. As a result, there has been strong interest in using hooks to secure agents. See Cursor’s recent launch of tools with multiple hook security partners, with Endor being one of them.  

It is still early days for hooks, but there is certainly promise. The important question looking forward is how hooks are going to interact with sandboxes. Will it be possible to implement “full” security for agents using only hooks without the need for sandboxes? If one has a sandbox, are hooks of any use? At this time, everything evolves fast, so it is tricky to make any firm statements. But hooks will be useful even if one has a sandbox, since hooks provide more visibility into the agent’s operation (prompts, models, and thinking) while the sandbox is mostly monitoring the lower-level OS activity. And using only hooks, it is unlikely to be able to secure all agent activity; for example, network transfers are unlikely to be covered by hooks. At this point, these two technologies will coexist and complement each other.  

IDE Plugins 

For some time, coding agents were living inside the IDE. This was natural since the IDE is the main interface that humans use to work with code. It makes sense to secure agents through IDE extensions, and a few products do just that. These extensions provide policy control and can block potentially risky activities from the agents while providing pretty good visibility into the agents’ activities. But as the agent’s capabilities increase, the developer can assign them a task and let them run unsupervised until they complete it. One can instantly become more productive by spawning multiple of these background agents. As more agent activity happens outside the IDE, the coverage and the effectiveness of the IDE security extensions diminish. If the future is fully agentic, maybe there won't be an IDE anymore. At the same time, hooks and sandboxes work equally well for both in-IDE and remote agents. 

Looking forward 

Everything related to AI, agents, and coding agents are evolving extremely fast. Hooks are only a few months old, and they have already become very popular with vendors converging on the list of agent activities that are monitored. New concepts like skills have spread like wildfire while introducing new attack surfaces for agents. 

Anthropic recently came up with its code execution concept that blurs the line between calling MCP tools and writing code-calling functions. Some saw this as the beginning of the end for MCP.  Calling CLI directly instead of MCP has become popular recently, and the MCP vs CLI debate is ongoing. 

Not very long ago, everyone was excited about deep agents that do more complex processing and more aggressive context management by generating code. New paradigms like recursive language models are becoming hot. These new developments will likely bring their own unique security challenges. 

These are exciting times; let's see what the future has in store.