[jakewins]

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]

"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]

But they explicitly setup the permissions this way.

[GuestFAUniverse]

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

[NorthSouthNorth]

I also find this frustrating. Every time I want to add an app to Github, it defaults to org wide. So far, I've managed to keep the reins on that, and nobody has made a mistake, but I am just waiting for the day someone adds something org-wide that shouldn't be.

Another rant(ish). You can request a PAT for, say, 30 days for a repo, and if you don't have access, it'll prompt an admin to approve that PAT. Okay, makes sense. But then you can refresh that same token without permission going forward.

[_joel]

You give apps explicit access to repos (or the full org). If you chose full org, what do you expect?

[stingraycharles]

Giving an app full scope to all repos in an org does not automatically imply that it would leak information from private repo A in comments on public repo B. That’s the issue being discussed here.

Like I said earlier, I can see both points of view, and I think the answer is more granular scoped permissions (eg on a per-workflow basis). Right now the permissions are crude.

[hardsnow]

GitHub doesn’t exactly make it easy to configure agent access securely. In fact, their regular access tokens and app credentials don’t provide granular enough controls to give direct access to private repos securely. Even if tokens are tightly scoped, access to public repos is always allowed and exfiltration via public repo issues for example remains a vector. Securing this requires patching via MITM proxy that implements stricter controls than GitHub provides.

Now, presumably GitHub Agentic workflows are the proper 1st party solution for this exact issue, but seems like they still have some work to do, either on the security model, or at least in making it easier to use securely.

More on this here: https://haulos.com/blog/do-not-give-your-agent-github-access...

[AgentMatt]

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]

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]

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]

Lack of experience and understanding of the computer at the fundamental levels.

[antonvs]

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]

> 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]

> 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.

[lubujackson]

LLMs are just a dumb terminal related to permissions. What they apparently want is some synthentic permissions spun up based on their prompt which is... not a "prepared statement" solution and more of a "I will clean user SQL statements with my handy regex" and we know how that works out.

The real solution is a better UI for controlling permissions on a per prompt basis - just as we can select "search the web or not" the solution would be to have a "include my private repo" option that can be trivially toggled.