Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What xAI's Grok build CLI sends to xAI: A wire-level analysis

gist.github.com

Post reply on HN
Print view View original

121–130 of 251 posts

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#121

Post by taywrobel »

csande17 wrote: post #115
taywrobel wrote: post #65

Earlier quoted context omitted.

GitHub Copilot engineer here working on identity, safety, and privacy - no, even Microsoft doesn’t have access to all GitHub repos. As years have passed since the acquisition “company” delineations have blurred a bit, but Microsoft employees still need to go through a separate onboarding process to access any GitHub company resources (internal repositories, telemetry, documentation, etc.), and then we have an additio…

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…

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!

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#122

Post by csande17 »

taywrobel wrote: post #121
csande17 wrote: post #115

Earlier quoted context omitted.

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…

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 inhere…

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

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#125

Post by taywrobel »

csande17 wrote: post #122
taywrobel wrote: post #121

Earlier quoted context omitted.

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 inhere…

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

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.

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#126

Post by pedromoss »

This is exactly why tools like Landstrip[1] exist. Sandboxing is a good mitigation to an extent, but it cannot address every class of attack. If an agent allows untrusted content to influence privileged decisions, the underlying design still has a large attack surface. Claude Code is also susceptible to this class of issue because of how its plugin interface works.

[1]: https://github.com/landstrip/landstrip

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#127

Post by pedromoss »

pedromoss wrote: post #126

This is exactly why tools like Landstrip[1] exist. Sandboxing is a good mitigation to an extent, but it cannot address every class of attack. If an agent allows untrusted content to influence privileged decisions, the underlying design still has a large attack surface. Claude Code is also susceptible to this class of issue because of how its plugin interface works. [1]: https://github.com/landstrip/landstrip

Also, I'm not particularly fond of using VM/microVM for sandboxing agents. This aligns with my line of thought: https://www.linkedin.com/pulse/why-your-microvm-sandbox-solv...

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#128

Post by lstodd »

taywrobel wrote: post #117
lstodd wrote: post #112

Earlier quoted context omitted.

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.

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.

If we lower the threshold from "absolutely" to "absent third-party breaches" what would you say?

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#129

Post by dminik »

Geee wrote: post #62

Isn't it assumed that the AI agent is allowed to read your files in the directory you launch the harness? Most agents read your code on the first prompt, including any secrets you have there, which you shouldn't have. Also the .env file is for local environment, and shouldn't contain any actual secrets. AI agents should be isolated from any actual secrets, because they can't be trusted to follow instructions. If you…

It will have to be sent through the context again. That's how LLMs work.

The only reason to do this is so that Musk has clean training data for his next model. Project setup, popular libraries, CI workflows, etc.

Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis

#130

Post by taywrobel »

lstodd wrote: post #128
taywrobel wrote: post #117

Earlier quoted context omitted.

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.

If we lower the threshold from "absolutely" to "absent third-party breaches" what would you say?

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.

Post reply on HN