Securing AI Agents: Plan Approvals & MCP Canonicalization

TL;DR

• The vulnerability: An October 7, 2026 security report identified eight vulnerabilities across seven AI coding agents, exposing attack vectors like git configuration hijacking, unsafe plugin execution, and sandbox escapes capable of local privilege escalation.
• The mitigation: MonkeysCode shipped Editor v1.3.2 and Agent Manager v1.1.2 on October 9, introducing mandatory plan approval controls under Auto routing to ensure explicit developer review before execution.
• Platform security: October 11 updates implemented Windows MCP (Model Context Protocol) trust canonicalization to prevent path-based trust bypasses, alongside strict prevention of chat code auto-apply.
• The trade-off: MonkeysCode currently lacks a formal external security audit mapping our sandbox against these 8 specific CVEs, and we have not yet published a documented threat model guide for MCP server permissions on our documentation site.

The Execution Boundary Problem in AI Agents

On October 7, 2026, security researchers published a comprehensive analysis identifying eight distinct vulnerabilities across seven popular AI coding agents, including open-source tools such as Goose and Hermes Agent. The attack vectors documented in the report are practical exploits that target the implicit trust models many agents operate under.

Specifically, researchers demonstrated how autonomous agents could be manipulated into executing git configuration hijacking. For example, by maliciously modifying core.pager or injecting aliases, an attacker can force the host system to run arbitrary binaries whenever a developer executes a standard git command. The report also detailed unsafe plugin execution and sandbox escapes capable of privilege escalation on local developer machines.

Sandbox escapes in the context of AI agents often rely on exploiting the agent's ability to execute shell commands or interact with the file system. If an agent is running within a restricted environment but has the ability to write to files that are later executed by the host (such as shell profiles, git hooks, or build scripts), it can effectively bridge the gap between the sandbox and the host system. The researchers highlighted that many agents fail to properly sanitize the outputs of the LLMs before passing them to the system shell, allowing for command injection if the LLM is fed malicious context from a compromised repository or an external API.

For senior engineers and platform teams, this report validates a long-standing skepticism: granting a Large Language Model (LLM) unrestricted CLI access or multi-file edit privileges without a strict execution boundary is inherently unsafe. The findings have sparked a necessary debate over how tools should enforce external permission models. An agent that can write code is useful; an agent that can silently modify your .gitconfig or escalate privileges via shell commands is a liability.

Explicit Plan Approvals over Implicit Trust

At MonkeysCode, our approach to autonomous CLI execution risks centers on supervised execution via the Agent Manager. We do not support "fire and forget" autonomy when local system integrity is on the line.

On October 9, we shipped MonkeysCode Editor v1.3.2 and Agent Manager v1.1.2. These releases introduced dedicated plan approval controls under our Auto model routing. When Capuchin (our built-in coding agent) formulates a plan to edit multiple files or run tests, the execution pauses. The agent must present its exact intended actions to the developer for an explicit review and approval gate before any state changes occur on the local machine.

When using Capuchin, the agent operates in a distinct planning phase before transitioning to execution. The Agent Manager parses the LLM's output, extracting the proposed actions into a structured format. This structure is what allows the Editor and CLI to present a clear, human-readable plan. Under the Auto routing model, which dynamically selects between frontier and open models based on prompt caching and task complexity, the variability in model outputs makes this structured parsing and explicit approval even more critical. A smaller, faster model might hallucinate a command that a larger model would avoid; the approval gate normalizes the security posture regardless of which model is routed.

This workflow ensures that developers retain the final say. If an agent hallucinates a destructive shell command or attempts to modify a sensitive configuration file outside the project scope, the developer can reject the plan.

Here is an example of how the Agent Manager CLI presents a plan for approval:

$ monkeyscode run --task "Update test fixtures for the new API"
[MonkeysCode Agent Manager v1.1.2]
Model: Auto routed
Routing to optimal model based on prompt complexity...

Agent Plan:
1. Read `src/api/client.ts` to understand the new interface.
2. Modify `tests/fixtures/api_responses.json` to match the new schema.
3. Run `npm run test:api` to verify the changes.

Proposed Execution:
- READ: src/api/client.ts
- WRITE: tests/fixtures/api_responses.json
- EXEC: npm run test:api

? Approve this plan? (Y/n)

By enforcing this gate, we mitigate the risk of an agent autonomously executing an unsafe plugin or running a command that escapes the intended sandbox. The developer acts as the final security boundary.

Securing the Model Context Protocol (MCP)

Beyond explicit approvals, the underlying protocols that agents use to interact with the system must be secure. On October 11, we shipped updates to the MonkeysCode CLI and Agent Manager to address edge cases in cross-platform execution, specifically focusing on Windows MCP trust canonicalization.

The Model Context Protocol (MCP) allows agents to interact with local tools and resources. However, if file paths are not strictly canonicalized, an agent might bypass trust boundaries using directory traversal techniques (e.g., ..\..\Windows\System32). Windows environments are particularly susceptible to this due to differences in path separators and volume letters compared to Unix-like systems.

Our October 11 commit enforces strict path canonicalization for MCP trust verification on Windows. Before an MCP server is granted access to a directory or file, the path is fully resolved and checked against the explicit allowlist defined by the developer. If the resolved path falls outside the allowed workspace, access is denied.

The October 11 fixes also addressed CLI test portability and cross-platform test fixtures, ensuring that these security mechanisms are robustly verified in our CI/CD pipelines across Linux, macOS, and Windows. We resolved Windows CRLF test failures and Agent Manager CI linting issues, which ensures that our security patches are consistently applied and verified before release. The integrity of the Agent Manager is paramount; if the supervisor itself is vulnerable or fails to build correctly on certain platforms, the execution boundaries it enforces cannot be trusted.

Additionally, this update included a fix to prevent chat code auto-apply. Previously, there was a risk that code snippets generated in the chat interface could be applied to the codebase without sufficient user intent. By strictly preventing auto-apply, we reinforce the principle that all state changes must be explicitly authorized.

Acknowledging the Trade-offs

While these updates significantly improve the security posture of the MonkeysCode platform, we must acknowledge the current limitations in our security validation.

First, MonkeysCode does not yet have a formal external security audit specifically mapping our sandbox boundaries against each of the eight published CVEs and attack vectors detailed in the October 7 report. While our internal testing and recent patches address the known vectors, external validation remains a pending requirement for enterprise compliance.

Second, we have not yet published a documented threat model guide on docs.monkeyscode.com regarding MCP server permissions. Developers configuring custom MCP servers currently must rely on general best practices rather than a MonkeysCode-specific security framework. We are actively working to document these threat models and permission guidelines to assist platform teams in deploying MonkeysCode securely at scale.

Takeaway

The October 7 security report is a clear signal that AI coding agents require rigorous execution boundaries. Autonomy without supervision is a security risk. By implementing mandatory plan approvals in Editor v1.3.2 and Agent Manager v1.1.2, and enforcing MCP trust canonicalization, MonkeysCode ensures that developers maintain control over their local environments.

We build tools for senior engineers who demand transparency and control. You can review our pricing or explore our team plans to see how MonkeysCode can fit into your secure development workflow. If you want to test the new plan approval workflow, you can download the latest version today.