PERMISSION/PROTOCOL
Back to incident tracker

2026-05-07

HighPrimary

TrustFall Coding Agent Security Flaw Enables One-Click RCE

TrustFall showed how repo-controlled MCP configuration could trigger coding agent tool execution without a specific human approval boundary.

Claude Code / Cursor / Gemini CLI / GitHub CopilotTool execution / MCPRepo-controlled tool executionDeveloper workstation / CI runner / MCP server

What happened

Researchers described a malicious repository configuration that could cause coding agents to spawn attacker-controlled MCP servers after a generic trust approval.

Why it matters

Reports describe one-click remote code execution risk across developer workstations and CI contexts, with potential access to local credentials, repo contents, and workflow secrets.

Missing authorization check

Starting a repo-defined MCP server or privileged project tool should require explicit approval naming the server, command, working directory, and credential scope.

Would PP block it?

The missing control is a receipt for tool execution before untrusted repository configuration can run code. GitHub Deploy Gate helps at merge/deploy, but local agent runtime needs its own authorization boundary.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-05-07

    Adversa AI published TrustFall research describing repo-controlled coding-agent execution paths.

  2. 2026-05-07

    Coverage focused on malicious repository configuration and MCP startup as the risky boundary.

  3. Permission boundary

    The authorization check belongs before starting the repo-defined server or running the privileged project command.

Technical breakdown

  • The risk starts when an agent treats repository-controlled configuration as trusted execution policy.
  • A generic workspace trust prompt is too broad because it does not name the server command, working directory, or credential scope.
  • The Permission Protocol control point would be a tool-call or MCP-server startup receipt, not only a PR review.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
MCP server startup, project tool execution, CI action runner
Still needs
Local workspace trust prompts and repo-defined agent config
Receipt required for
Starting an MCP server, running repo-defined commands, exposing workflow secrets

Would block if MCP server startup or project tool execution were routed through a tool-call authorization gate; a PR-only gate would not cover local agent trust prompts.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop