Comment by AgentMatt
9 hours ago
Agreed. It seems a core issue underlying these prompt injection attacks is a failure to properly scope the agent's permissions. In this case, depending on what exactly the agent is supposed to actually do, this might be defining a separate workflow agent per repo, or a workflow agent with broader repo access but configured to only be triggered by users on an allow list (still compatible with developing in the open, still allows outsiders to open public issues, but takes into account the different trust to be placed in each). And likely many more options when one properly thinks about it.
But that requires:
1. the technical ability for such fine-grained scoping / permissions
2. actually taking the time to think about what you want to achieve with the agent and what the smallest set of permissions / capabilities is for it to achieve it
Regarding 1., I think this will come, we're still in the wild west phase of agent usage. It'll be interesting to see which abstraction(s) will turn out to be the best interface for humans designing agents (minimize friction for finding and defining scope and permissions) and to limit agent capabilities (again finding the best trade-off between level of detail possible for defining capabilities and the ease of use of actually doing it).
Regarding 2., well, that's still the core problem that's always prevented the construction of high quality software, isn't it? Taking the time to properly think it out,and then taking the time to properly implement it. Which goes counter to the "move fast and break things" approach of people throwing agents at everything.
The fallacy here is expecting an agent that has access to ALL your repos to respect the singular repo it’s in. It won’t. If it has access to all your repos and you ask it about a private repo you aren’t in - it will definitely go look at that private repo. This is like giving your dog a bone and then being surprised when he buries it in the backyard.
Exactly. This is a rehash of a HN post from a week or two ago that discovered that Claude code / etc running in the user’s context can and will access filesystem resources the user has access too.
That post had crazy suggestions for harness-level rules or shell scripts or something, when the obvious and correct answer is to run agents using existing OS-level security features that grant appropriate access (if you don’t want an agent accessing ~/ , run it as a user that doesn’t have access!)
Lack of experience and understanding of the computer at the fundamental levels.
In my agent sessions,which are scoped to one or more src/project folders, the model regularly tries to access src/ for no good reason. When asked what it’s looking for, it never has a good answer, and suddenly discovers that it can find what it needs in the folders it already has access to.
The dog analogy is quite apt - it just really wants to access src/, it doesn’t need a reason.