upvote
This is a nice answer to the question "how is GitHub preventing rogue employees at Microsoft from stealing my private repositories?". Like, it's good to know I'm covered if Microsoft accidentally hires a North Korean spy or something.

But if Microsoft really was selling private repo content to OpenAI, it probably wouldn't go through those access controls. It'd be an executive-level decision with enough force to plow through all the red tape, and it'd be implemented as a data pipeline or similar automated process that wouldn't trigger the same kind of notification as, like, a Trust and Safety employee taking manual action.

Probably the better evidence here is in GitHub's ToS where they say in pretty strong/binding terms that they aren't doing this: https://docs.github.com/en/site-policy/github-terms/github-t... . If they are secretly selling your data to OpenAI they haven't left themselves a ton of wiggle room if people ever found out.

(Probably the biggest loophole they could use is to send private repo content to an OpenAI service for scanning/safety purposes. The ToS allows this and they're almost certainly doing it with other services like PhotoDNA. Then OpenAI can just violate whatever agreement they have not to store the data sent to that service.)

reply
I’m one of the people directly responsible for ensuring that those terms are properly enforced. Presently I’m arguably the person for Copilot data specifically.

Current talk of the town in the data retention space is around AI safety. There’s been a recent slew of blog posts and academic papers around how LLM harms can manifest over multiple agentic turns, from individually innocuous requests. Identifying this inherently necessitates user data retention which we do everything possible to avoid (not even meaning data sharing as is alluded to in this thread, I mean literally persisting prompts and completions anywhere outside of ephemeral memory). I’ve been the one advocating for having the storage of any data retained for safety and security purposes to be as heavily access controlled and audited as is possible.

Also, if AI safety is a space that is interesting to you, we’re hiring! Manager, developer, and applied science roles, or we can figure out the HR shenanigans if you don’t fit any of those archetypes. If interested shoot me an email at taywrobel@github.com!

reply
(FWIW, in my conspiracy theory, the data sharing would be buried in the part of the company responsible for making sure that people don't upload e.g. CSAM to private repositories, so the Copilot people wouldn't be directly aware of it. I might've edited that in after you already started writing your reply though.)
reply
Still in my bubble! I am not involved in the human review or automated analysis portions of the safety pipeline for CSAM/TVEC harms, but my team is responsible for the data handling around identifying and responding to such content.

As of 11 days ago our vision support is GA (https://github.blog/changelog/2026-07-01-copilot-vision-is-g...) and let’s just say the technical implementation wasn’t the long pull there. Figuring out the what and how of responsible data handling around what I hope is agreeably harmful use was… quite a journey.

reply
deleted
reply
How do you define "access" here? Microsoft has demonstrated that it can delete any GitHub repo at will. Maybe there's some shell entity between corporate "Microsoft" and "GitHub" that's doing the dirty deeds without attribution...
reply
Access meaning read, modify, delete, etc. Pretty standard definition, unless you know of a different meaning of access I’m not privy to.

Microsoft can certainly request that we perform actions against repositories, as can governments, customers, random people on the street, etc. Whether action is taken in those cases is a question for lawyers to fight over, but we have the engineering guardrails in place to require it to be an intentional, audited action.

I appreciate the spicy question tho, even if misguided!

reply
Can you state with absolute сertainity that no entity outside your github unit can exfiltrate data at will?

This is not spicy, this is basic infosec.

reply
Nobody can say that with absolute certainty, so obviously not.

And since you presumably knew that already (as it is basic infosec) then yes it is spicy, or simply antagonistic.

reply
If we lower the threshold from "absolutely" to "absent third-party breaches" what would you say?
reply
Even with your rephrasing you’re looking for an answer in absolutes which is generally impossible, but unpacking your line of questioning, what it really amounts to is how “in the know” I am or am not.

To the best of my knowledge I know about every ongoing company AI safety and user privacy initiative, and none of them involve permitting access to copilot user content to any second party or third party entity.

Of course, that’s tautological. I don’t know what I don’t know, but I’m senior enough and with broad enough scope that I’m at least read in on what I believe is the majority of high level business initiatives.

I’m not trying to be evasive, this is just the reality of any organization - I only know what I know. Everything within my scope of awareness indicates that there is no copilot user content access outside of our publicly published terms of service.

reply
Thanks for responding. It's great to hear from someone working these issues day to day, and it's the reason I come to HN. I feel like this particular line of questioning is a bit silly, with all the "Can you absolutely guarantee X, Y, and Z?" Thanks for engaging despite the adversarial turn it has taken!
reply
I think there's maybe a disconnect here that people are largely concerned with the contents of their private repos, while you're maybe more familiar with how AI interaction data is handled. (After all, the original topic of the thread was X.ai allegedly going above and beyond interaction data to exfiltrate entire repos.)

I personally did get the vibe that you were being evasive, just because the things you were saying didn't quite match what people were asking about, in a way that felt kind of like a corporate legally-not-a-denial denial. It's like, "Hey, has Contoso Apartments hidden a camera in my bathroom?" "Contoso Apartments is committed to your privacy and safety. We have strict controls in place to ensure that our maintenance staff cannot make a copy of your key without notifying you. To the best of my knowledge, we do not have any company initiative that involves opening envelopes addressed to you." Like it's theoretically reassuring for the company to commit to those things, but the fact that they can't directly answer the original question is disconcerting.

Ultimately there's probably not a whole lot you can do about this. Like realistically if Microsoft is doing this, they've probably constructed it in a way where not many people know and/or they can plausibly deny it. So it comes down to (a) Microsoft denies doing it, but isn't making the broadest legally binding commitment possible, (b) does the reader believe Microsoft and OpenAI are trustworthy with respect to privacy and intellectual property issues or not.

I've been in this kind of situation before, and it can be frustrating when people don't believe that you're in a good, isolated department of the company and you're committed to upholding ethical standards. I guess that's why big companies pay the big bucks :)

reply
That’s fair, and I appreciate the more constructively critical feedback! Also worth noting that I’m solidly on the platform service side, and the article here is largely focused on malicious client behavior.

Copilot has a lot of different clients between IDEs, agentic integrations, and GitHub apps. I don’t have awareness of the implementation details of all of them, but I can assure you that we don’t provide APIs like those mentioned in the article being used for data exfiltration.

Clients are responsible for context building, and all go through the same service that does auth, policy and quota enforcement, request routing to the underlying providers all of which have zero data retention enabled unless very specifically excluded from that (looking at you, Fable 5).

reply
[flagged]
reply
> If we lower the threshold from "absolutely" to "absent third-party breaches" what would you say?

If anyone answered that question affirmatively, I'd lose a massive amount of trust in them. It would betray they fundamentally misunderstand the stochastic nature of playing defense.

reply
It's a pretty antagonistic way of asking a question man. Don't do that
reply
[flagged]
reply
Prove which part?

Prove that I work at GitHub? Username + LinkedIn can show (not prove) that easily.

Prove that we have an entitlements system which regulates and audits access? I could point you to https://github.com/entitlements, but it’s all private repositories so that won’t prove much either.

Prove that there are no OpenAI employees with access to GitHub systems? Not sure how I’d do that without dumping (what you would still need to trust me is) the entirety of our org chart/HR system, which I’m not willing to do because I do enjoy being employed and am not exactly obfuscating my identity here.

Prove that HN has a strong anti-Microsoft bias? Well that one is pretty easy actually, you’re helping prove it yourself!

Let’s be real, we now live in a post-truth world. Nothing can truly be proven or disproven outside of formal logic and mathematics. You can either believe what I’m saying as good faith insider knowledge sharing (which is unfortunately rare nowadays) or you can not. Makes no difference to me.

reply
That is my point! The fact that there are a lot of people that will believe what you are stating without a reasonably proof is what makes me sad and worry about the future. That kind of statements you are doing are enough to put in company webpage and term of service and thats it. Any attempt to repeat them as if they are true makes: 1) The messenger looks good in the eyes of stupid and innocent people. 2) The messenger looks stupid in the eyes of people that have reasonable doubts about company statements that are agains their own interest.
reply