The dangerous agent failure is not always a bad answer.
Sometimes it is public input reaching private context.
I have seen permission models that looked reasonable until two contexts touched. Separately, each made sense. Together, the boundary quietly disappeared.
GitLost is a clean example of this. Researchers showed that a crafted public GitHub issue could steer an AI agent — one wired with read access across an organization's repos — into fetching a private README and posting it as a public comment. No stolen credentials, no code, just a well-worded issue the agent read as an instruction. It is not really "prompt injection" in the narrow sense. It is a context-separation failure: the agent held both untrusted public input and privileged private access, and the workflow let them meet. As the researchers put it, the agent's context window is its attack surface.
Here is why this is structural, not a one-off bug. The agent runs on a service-account permission model, not a user one — it has standing credentials and reads attacker-reachable text in the same context. No patch closes that; the fix is architectural. Scope the token to the one repo it triages, not the whole org. Treat every issue, PR, and comment as untrusted input. Separate what can instruct the agent from what it can access. Gate anything it can publish.
A safe agent needs more than a refusal policy. It needs a hard boundary between what can instruct it and what it can reach.
If public text can steer private access, the permission model is already broken — the model just hasn't been asked the right question yet.