Engineering teams have rapidly adopted AI coding assistants with access to source repositories, internal documentation, and sometimes deployment pipelines. That access makes them productive, and also makes them part of the software supply chain's security surface.
MFA is often treated as the primary safeguard, but it mainly protects the login itself, not the assistant's actions once authenticated. Recent research demonstrated this gap clearly: the attack didn't bypass authentication at all — it worked entirely within an authenticated session. This is why AI coding assistant security needs to extend beyond login protection into authorization and runtime behavior: which repositories it can read, whether it can open pull requests, merge code, or touch production configuration.
Once an assistant can access repositories or CI/CD workflows, its behavior becomes part of the security model, not separate from it. A prompt injected through a malicious comment or compromised dependency could attempt to redirect its actions in ways a human reviewer might not immediately notice.
Safeguards include human approval for production-touching changes, logging every repository action, and separating read access from merge or write privileges. Third-party code an assistant suggests deserves the same dependency scrutiny as code added manually, since a compromised package introduced through a suggestion carries identical downstream risk.
For a deeper look at how authentication alone failed to prevent a real exploit, see this analysis of the CoSnitch vulnerability.
Top comments (0)