SQL attack is different. There's clearly zero expectation that someone can, for example, enter something on a web page and extract database info or modify the database beyond what was intended by the API (e.g., update a single record).
If you are working in an organization and you tell a junior coder "do everything on this list" and on the list is something that says "do something to some other list" and the junior coder does it...that's a fundamentally different kind of "bug". Maybe you expected that the junior coder should say "oh hmm, it's weird that something in this repo mentions another repo" but in that case, you can imagine a high level todo list that points to other low level todo lists, where you would want the junior coder to proceed. Maybe you're looking for "common sense" where there is none?
Actual organizations have ways to mitigate this. For example, OWNERs files would prevent someone from committing code to a repo of which they are not an OWNER without review. And then we're back to what many in these comments have proposed: you should not have given the agent access to another repo if you didn't want it to do something in that repo after you told it--albeit indirectly--to do something in that repo...
--
Actually, arguably a better analogy is that you go to share a file with someone in, e.g., Google Drive. You share a folder and inadvertently grant them access to a subfolder that you didn't want to share. If, in sharing the folder, you say "hey please revise some docs" and then somehow something in the subfolder gets modified, that's not a bug. That's you sharing a thing you weren't supposed to share. So this automatic detection pipeline can maybe detect where you intended to share X but actually shared X and Y.
If you are working in an organization and you tell a junior coder "do everything on this list" and on the list is something that says "do something to some other list" and the junior coder does it...that's a fundamentally different kind of "bug". Maybe you expected that the junior coder should say "oh hmm, it's weird that something in this repo mentions another repo" but in that case, you can imagine a high level todo list that points to other low level todo lists, where you would want the junior coder to proceed. Maybe you're looking for "common sense" where there is none?
Actual organizations have ways to mitigate this. For example, OWNERs files would prevent someone from committing code to a repo of which they are not an OWNER without review. And then we're back to what many in these comments have proposed: you should not have given the agent access to another repo if you didn't want it to do something in that repo after you told it--albeit indirectly--to do something in that repo...
-- Actually, arguably a better analogy is that you go to share a file with someone in, e.g., Google Drive. You share a folder and inadvertently grant them access to a subfolder that you didn't want to share. If, in sharing the folder, you say "hey please revise some docs" and then somehow something in the subfolder gets modified, that's not a bug. That's you sharing a thing you weren't supposed to share. So this automatic detection pipeline can maybe detect where you intended to share X but actually shared X and Y.