How is this a Github vulnerability? The researchers are the ones that grant the agent access to private repos and then ask it to answer questions in public repos.. of course this allows extracting private information?

This is like setting up a normal CI job with access to secrets and running it on public PRs. If you configure GitHub to allow public code or LLM instructions to run in contexts that have access to sensitive things, they will leak; that’s not GitHub’s fault, it’s yours.

▲

stingraycharles 7 hours ago | parent | next [-]

"How is this a Github vulnerability? The researchers are the ones that grant the agent access to private repos and then ask it to answer questions in public repos.. of course this allows extracting private information?"

I think the assumption is that the permissions are scoped to the repository you're currently asking questions on, rather than your private repositories as well.

I can see arguments for both sides.

▲

eddythompson80 6 hours ago | parent [-]

But they explicitly setup the permissions this way.

▲

GuestFAUniverse 5 hours ago | parent [-]

Half the crowd using GitHub ever thought about plugins that have org wide access but /promise/ not to misuse it. And years ago that included a lot of popular plugins (my POV was that those were outright stupid) -- on par with Docker in standard configuration: brain dead, works on my laptop idiocracy.

I stopped disabling plugins from "managers" that overreached from their repos only to org wide years ago. While I liked a lot of people I worked with in that institution on a personal level, I was happy not having to work with them as devs, when that institution got closed.

Some nice people behave rather dumb when it comes to tech. And than comes AI and tramples along, because there are no boundaries (See the article what they are writing about /assumed/ security boundaries. They assume things so much, it becomes physical pain to read or listen to them.)

	▲	_joel an hour ago \| parent [-]
		You give apps explicit access to repos (or the full org). If you chose full org, what do you expect?

▲

AgentMatt 6 hours ago | parent | prev | next [-]

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.

▲

reactordev 5 hours ago | parent [-]

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.

▲

brookst 2 hours ago | parent | next [-]

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!)

	▲	reactordev an hour ago \| parent [-]
		Lack of experience and understanding of the computer at the fundamental levels.

▲

antonvs 32 minutes ago | parent | prev [-]

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.

▲

hobofan 6 hours ago | parent | prev | next [-]

> If you configure GitHub to allow public code or LLM instructions to run in contexts that have access to sensitive things, they will leak; that’s not GitHub’s fault, it’s yours.

Is there a way to segment access per agentic workflow, so that you can have both habe an agentic workflow that has access to sensitive data and one that has only access to public data? Is the default to set the scope to only the current repository? Does Github appropriately inform about the risk of combining an agentic workflow with access to private repository data?

If the answer to any of those questions is "no", then that's a problem.

(Classic GH Workflows are also riddled with priveledge escalation via PR-triggered workflows, but that's another topic.)

	▲	philipp-gayret 5 hours ago \| parent [-]
		> Is there a way to segment access per agentic workflow, so that you can have both habe an agentic workflow that has access to sensitive data and one that has only access to public data? Is the default to set the scope to only the current repository? If the author had used the native secrets.GITHUB_TOKEN then yes. > Does Github appropriately inform about the risk of combining an agentic workflow with access to private repository data? Not really, but also this highlights a broader issue: GitHub introduced fine-grained access tokens quite a while ago to prevent these situations. However, fine-grained access tokens don't work for a fair segment of the GitHub API for whatever reason. So often you have to use a personal access token to create a GitHub integration, and these have extremely broad permissions. Having said that, that is still the author's choice.

▲

claud_ia 5 hours ago | parent | prev [-]

[flagged]