The trust check arrived after the first dangerous action

On Windows, a coding assistant can ask Git for basic repository information and run a repository-controlled executable before the user approves the project. That was one of three pre-trust execution routes disclosed for Mistral Vibe in November 2026. The flaw was not a model obeying hostile prose. It was software doing executable work while preparing the context on which the trust decision would later depend.

Other recent reports place the same ordering problem elsewhere: an MCP gateway that accepted authentication headers without the authenticating proxy, a browser-accessible local memory server, and a coding action that reached fork-controlled code under privileged CI credentials. They do not form one exploit chain. Together they clarify a review question that a final agent transcript cannot answer: what had already happened by the time the control was evaluated?

Mistral Vibe inspected project state at startup. Three distinct Git mechanisms crossed the approval boundary, and they require different preconditions.

The latter two are not ordinary clone-and-click attacks: a standard Git clone does not copy an attacker's .git/config. The distinction matters for anyone evaluating real exposure. The advisories describe pre-approval execution in specifically configured projects, not evidence of widespread malicious repository distribution. Windows lookup advisory, filter advisory, signature advisory.

A trust screen can only protect an operation if its decision precedes the operation. Testing this requires tracing the agent host's startup subprocesses, environment and configuration resolution, rather than scanning just prompts and generated code.

Agent Router's MCP proxy was designed to sit behind an Envoy frontend. Envoy verifies the token and inserts route, backend and subject headers. The proxy accepted those headers as trusted input. But version 1.2.0 bound its internal listener to all interfaces on port 9856, leaving a path for an adjacent network peer to connect directly and present the same identity claims. This required reachability to the gateway pod; it was not demonstrated as an unauthenticated internet-wide compromise. First-party advisory.

Unlike the Git findings, this was a network and provenance failure, not an early subprocess. The proxy made an authorization-sensitive decision using a header whose source it did not independently authenticate. The 1.2.1 repair bound the listener to loopback and rolled affected gateway pods. That removes the documented direct path; it does not mean arbitrary downstream tool arguments are validated automatically. Release notes.

The MCP Memory Service issue crossed a different boundary. The vulnerable local HTTP transport accepted cross-origin JSON-RPC tool calls without an independent authenticated authorization check. An attacker-controlled webpage could induce deletion or alteration of persistent memories while the service was running. Retrieving memory through DNS rebinding involved additional preconditions and should not be confused with the simpler write path. Version 12.6.0 addressed the reported exposure. Advisory.

Here the intended assistant session was not necessarily active when the unwanted instruction arrived. If stored memory later influenced another session, a clean chat transcript would not contain the original browser request. The control boundary is the local tool's authorization and origin checking at the moment of a persistent write.

The Junie GitHub Action finding concerns fork-controlled content reaching execution under privileged workflow credentials before 1.8.0. The public advisory does not specify every event or checkout configuration, so it would be unsafe to name a particular workflow trigger as universally affected. Still, the engineering distinction is clear: the model's reasoning safeguards and the runner's code-execution permissions are separate enforcement systems. Junie advisory.

These are different failures with different remedies. A useful security review records the transition that each control is meant to govern:

1. Project initialization: which executable or configured Git helper actually ran before workspace approval?
2. Gateway ingress: did the request traverse the identity verifier, and what binds a resulting session to its original route?
3. Persistent tools: which authenticated principal and origin authorized a memory write?
4. CI execution: what code ran with workflow credentials, and who controlled its bytes?

That evidence comes from process traces, network paths, tool authorization logs and durable writes. A model's final summary can describe the task, but cannot prove that every authority-bearing step passed the right gate. This is an engineering inference across the cited cases, not evidence that they share an attacker or that all involved a malicious model.