My understanding is that the weakest link here is either git or the way the agents rely on git. So, every commit in a git repository has a unique*, immutable, deterministic identifier. A commit with different content would have a different identifier. It is commonplace to use these identifiers to pin a dependency to a specific commit. In addition to these immutable deterministic identifiers, there are also so-called “refs”, which are mutable identifiers. You use these to point to e.g. “the most recent version”. So if the agent needs a “skill” that is pinned to the commit with ID aaaaaaaaa it will run the checkout command with that ID; this should prevent any shenanigans because only* a commit with the specific content that was vetted earlier will have that ID This attack exploits an unexpected git behavior: the command to checkout a particular commit accepts either a commit ID or a ref, but tries refs first. So what the attacker does is add a ref to the repository named aaaaaaaaa that points to the malicious commit. Then the agent runs git checkout aaaaaaaaa and ends up at the malicious commit instead of the one that was pinned. I don’t know if there’s a way to tell git checkout to ignore refs, but this might actually be a vulnerability in other systems that rely on git like this.