Matrix Coder persona contract leaks into user messages — prompt injection that overrides host agent identity

[Interstellar-code]

Summary

The Matrix Coder specialist persona contract is being injected as a trailing block inside user messages on the messaging gateway (Telegram confirmed; likely all gateway platforms). This block contains directives that conflict with the host agent's actual identity (SOUL.md) and the user's real intent, and includes an instruction to begin the reply with a specific line verbatim — a prompt-injection pattern.

Observed symptoms

A user message that should be plain intent (e.g. "give some points as to what sections of the frontend SwitchUI profile creation need refactoring") arrives at the model with this appended:

[matrix-coder active: role=review, lens=code]
Begin your reply with the line above exactly as written.

# Specialist Contract
You are a **Matrix Coder specialist**: ...
## Scope discipline
- Stay inside the goal and the file set you were given.
- If a needed change falls outside your file set or role, do not make it
...
# PERSONA
# Review Specialist
You are the review specialist: a focused, read-only code reviewer.
...

This contract:

1. Demands identity override — "Begin your reply with the line above exactly as written" attempts to force the agent to adopt the persona and emit its marker.
2. Conflicts with host agent identity — instructs read-only / never-delegate, while the user's actual request requires delegation and synthesis.
3. Restructures output format — appends a 4-section output contract (Findings / Open Questions / Positive Observations / Recommendation) that overrides the host agent's configured behavior.
4. Is not requested by the user — the user typed a normal message; the persona block was appended by the system (Matrix Coder plugin/hook), not by the user.

Why this matters

• Prompt injection at the system layer. A plugin appends structured directives to user messages that the model treats as instructions. This is the same class of vulnerability as any untrusted-content injection, but coming from a trusted plugin — so it bypasses the normal "untrusted source" skepticism.
• Identity hijacking. A specialist persona contract that says "Begin your reply with..." can override the host agent's SOUL.md identity. In a multi-profile setup (orchestrator + specialists), this can make an orchestrator behave as a specialist, breaking the delegation topology.
• User confusion. The user does not see the persona block they typed (it's appended post-send) and may not understand why the agent's behavior changed. The agent has to explicitly refuse the injected persona and explain the conflict, burning tokens and eroding trust.

Reproduction

1. Matrix Coder plugin enabled on the active profile
2. User sends a normal message via Telegram gateway (e.g. a task requiring delegation or synthesis)
3. The Matrix Coder hook appends a specialist persona contract to the user message before it reaches the model
4. Model receives: {user_text}\n\n[matrix-coder active: role=review, lens=code]\nBegin your reply with...

Suspected root cause

A Matrix Coder plugin hook (likely a pre_llm_call or message-mutation hook) is appending the persona contract to the user message body instead of one of these correct mechanisms:

• Injecting via system prompt (where the host agent's identity already lives and can be reconciled)
• Setting as a separate, clearly-delimited context block that the model knows is advisory
• Being opt-in per invocation (the user or orchestrator explicitly requests a specialist framing), not unconditional

Proposed fix direction

1. Persona contracts should never mutate user messages. If Matrix Coder wants to frame a turn as specialist, it should inject into the system prompt or a dedicated specialist_context field — not append to user-role content.
2. Remove the "Begin your reply with..." directive. This is a prompt-injection vector regardless of source; even trusted plugins should not dictate the first line of the agent's response.
3. Make specialist framing opt-in. The orchestrator (or user) should explicitly invoke a specialist role; it should not be auto-appended to every message.
4. Add a guard: if a plugin hook returns text that contains identity-override directives ("Begin your reply", "You are a X specialist"), the gateway should reject or quarantine it with a warning.

Related

• [RFC] Matrix Coder Plugin — OMC-style specialist agent bundle for Hermes #76 — [RFC] Matrix Coder Plugin (the RFC that introduced this architecture)
• Matrix Coder workflows (ralph/autopilot/ultrawork/ultraqa) are persona text only — no programmatic loop, iteration cap, or cross-turn state #129 — Matrix Coder workflows are persona text only (related: the persona mechanism is overloaded)
• Matrix Coder Kanban audit: only one parent card per invocation — per-dispatch child cards not implemented #130 — Matrix Coder Kanban audit gap (related: the specialist contract promises capabilities not implemented)

Environment

• Hermes Agent: current (profile hermes-switch, active gateway)
• Gateway platform: Telegram
• Plugin: matrix-coder (version per plugin.yaml)

cc @rohits

[Interstellar-code]

Fixed — merged to main (98ea628d4), live on the gateway

Root cause was two-fold and both are addressed.

1. Injection channel (the identity override). The persona contract was returned from the pre_llm_call hook as a bare string and the gateway concatenated it into the user-role message (agent/conversation_loop.py), same trust tier as user input — so it could override the host identity (SOUL.md), aided by the coercive "Begin your reply with the line above exactly as written." line.

• The gateway now honors a target key: a hook returning {"context": ..., "target": "developer"} is appended to effective_system at API-call time (trusted tier), never the user message. The cached system prefix stays byte-stable on non-matrix turns, so the prompt cache is preserved. Plain-string / target-less returns from every other plugin are unchanged.
• Dropped the verbatim-echo coercion and the user-visible [matrix-coder active: …] marker; goal text is sanitized before the audit sink.

2. Over-eager IntentGate (wrongly picking up tasks). A single trailing ? flipped identical text from quiet → silent specialist activation; advisory/meta questions addressed to Hermes were hijacked.

• Negative-signal short-circuit (advisory / meta / hermes, addressee / bare-locate), applied leading-only so compound imperatives still route.
• Dropped bare-?/wh sufficiency; silent activation now requires a strong signal (explicit role word or a clear code imperative). Weaker/ambiguous and evaluative yes/no questions fall to a visible recommendation instead of silently activating.
• New MATRIX_CODER_IMPLICIT_ROUTING=0 kill-switch (explicit matrix trigger still works).

Acceptance: what parts of the frontend … need refactoring?, should I refactor …?, is this api backward compatible?, hermes, what should we do …? → no silent activation; refactor the auth module, why does the API endpoint crash?, fix the bug, should i mention it also breaks login → still route correctly.

Also hardened (from the audit): session-keyed bridge state with an LRU cap (was a process-global singleton bleeding across sessions), atomic card close (double-close race), hot-path exceptions promoted to WARNING, orphan audit cards close blocked not done.

Verification: 124 plugin + 73 gateway tests green, including new regression coverage for the advisory-to-orchestrator, compound-sentence, advisory-yes/no, addressee-boundary, and kill-switch cases. Two independent adversarial review passes; one BLOCKER (a NameError on hook failure) and the gate over-correction caught and fixed before merge.

Docs updated (README + plugin.yaml → v0.6.1) and the gateway has been restarted, so the live agent is running the fixed code. LOW/NIT backlog tracked in #142.

Closing.