# MCP Bifrost Delegated Worker Edit Abuse

- **Severity:** High
- **Signature ID:** `6f2c9a41-7d3e-4b58-9c02-1ae5f83b7d64`
- **MITRE ATLAS:** AML.T0051 (LLM Prompt Injection), AML.T0053 (AI Agent Tool Invocation)
- **OWASP:** LLM05 (Improper Output Handling), LLM06 (Excessive Agency)

## Summary

mcp-bifrost hands off code-editing tasks to a cheaper worker model and automatically applies whatever edits come back, once basic checks pass. If that worker model is tricked or compromised, its edits are trusted and applied as if the main agent wrote them, potentially rewriting files it was never asked to touch.

## How the attack works

A session running mcp-bifrost delegates an edit task to a worker process. Instead of confining changes to the scoped task, the worker's writes land on sensitive files: CI/CD workflow definitions, git or husky hooks, dependency manifests and lockfiles, container entrypoints, the validation-gate configs meant to catch bad edits, secrets, or files used for shell/agent persistence. The detection looks for one write to a high-trust surface plus a second, independent suspicious signal (another sensitive surface, secret material, or an unusually wide set of files touched) within a 15-minute window, rather than flagging every edit.

## Why it matters

An attacker who manipulates the worker model can get their changes silently applied with the primary agent's trust - potentially disabling CI checks, planting persistence, or exfiltrating secrets - without the diff itself ever being inspected by this detection.

## What you can do

- Restrict which files an automated code-editing worker is allowed to write, especially CI configs, git hooks, dependency lockfiles, container entrypoints, and secret stores.
- Require human review or a separate approval step before any automated edit touches validation-gate configs or CI/CD definitions.
- Keep dependency install steps isolated from arbitrary file-write permissions so a compromised worker can't piggyback edits on top of routine installs.
- Log and periodically audit what files delegated worker processes actually write, independent of whether edits pass validation gates.

## Known benign look-alikes

- A developer legitimately asks mcp-bifrost to add or edit a CI workflow, Dockerfile, Makefile or git hook. Mitigated by requiring a second independent evidence class - a single expected surface edit is not reported.
- Dependency installation (npm/yarn/pnpm install, pip/poetry install, bundle install) rewriting a lockfile or manifest during a bifrost session. This yields one evidence class only, because writes under vendored dependency and cache trees are not counted.
- Large legitimate refactors or codegen runs that touch many files. Volume alone is never sufficient - an execution-trust, gate-config or persistence write is required.
- Repository bootstrap or scaffolding tasks ("set up CI and pre-commit for this repo") which intentionally touch a workflow file and a validator config together. Expected to be reported; report-only so no work is blocked.
- Local .env / .npmrc edits performed by the developer's own editor process. Only writers inside the resolved bifrost process session are considered; sample and template env files are ignored.

## References

- https://attack.mitre.org/techniques/T1195/002/
- https://attack.mitre.org/techniques/T1059/
- https://genai.owasp.org/llmrisk/llm05-improper-output-handling/

---
Source: https://www.netzilo.com/threats/mcp-bifrost-worker-edit-abuse