Grok Build: 8,700 Stars in 48 Hours. 5 Questions Before Devs Install.

TL;DR: xAI released Grok Build on July 14, 2026 -- a Rust-built terminal coding agent now at 8,700 GitHub stars in 48 hours. The free tier is covered by xAI's consumer privacy policy, which uses your code for model training by default. An enterprise DPA exists but it is not clearly documented for the CLI. Answer these 5 questions before your developers install it.

xAI dropped Grok Build on July 14, 2026. Within 48 hours: 8,714 stars, 1,373 forks, and a link in every developer Slack channel. That's the fastest GitHub growth any AI coding tool has seen this year.

The tool is real. It runs Grok 4.5 -- xAI's newest model -- inside a full-screen terminal interface built in Rust. It reads codebases, edits files, runs shell commands, searches the web, and can execute CI/CD pipelines in headless mode. It supports MCP servers, AGENTS.md conventions, hooks, skills, sandboxed execution, and a plan mode that blocks edits until you approve. On paper it is a direct competitor to Claude Code, GitHub Copilot CLI, and Cursor.

Your developers want it. The governance question is whether they should have it before your IT and security teams have reviewed the data handling terms.

What Grok Build actually is

The install is a one-liner:

curl -fsSL https://x.ai/cli/install.sh | bash

First launch opens a browser to authenticate via grok.com. Enterprise SSO is supported -- xAI's enterprise FAQ mentions SSO integration -- though the company does not publish pricing or CLI-specific documentation for the enterprise tier publicly.

The open-source repository at github.com/xai-org/grok-build is Apache 2.0 licensed and written in Rust. Third-party tool implementations were ported from openai/codex and sst/opencode, documented in THIRD-PARTY-NOTICES. The codebase is genuinely open: you can read the source, fork it, audit the tool implementations. One important caveat: external contributions are not accepted, per the CONTRIBUTING.md file. If a security researcher finds a vulnerability, they can report it but cannot submit a patch. Your organization is dependent entirely on xAI's internal response cadence for fixes.

The feature set is competitive. Grok Build supports MCP servers out of the box, which means it integrates with the same tool ecosystem your team may already use with Claude Code. It has a plan mode (analogous to Claude Code's plan mode) that requires user approval before file edits. It includes a skills system for project-specific instructions, similar to CLAUDE.md. The architecture is clearly informed by existing terminal coding agents, and the implementation is fast.

The question isn't whether it works. It's what happens to your code when it does.

The governance gap on the free tier

Here is the sentence that determines your governance exposure.

xAI's privacy policy (effective April 4, 2026) defines "User Content" as "prompts and other content you input, such as files, images, audio, voice, video, and other material." It then states that User Content may be used "to develop and improve our Service and to conduct research."

That means training. When your developer installs Grok Build on the free consumer tier and runs it against your codebase, the code submitted to Grok 4.5 is subject to that policy by default.

Compare this to the alternatives most enterprises have already reviewed:

• Claude Code (Anthropic API or Team tier): Users get a no-training commitment at policy level. Enterprise users get it contractually. The Anthropic API terms, which prohibit training on customer data, govern Claude Code usage. This is documented and enforceable.
• GitHub Copilot Business: GitHub explicitly does not train foundation models on code from organizations subscribed to the Business tier. This is a specific, documented, contractually backed commitment -- not a general privacy policy statement.
• Grok Build (free tier): No equivalent commitment. xAI's consumer privacy policy applies. Training is on by default.

This is not a criticism of xAI's security posture. It is a factual description of what your developers accept when they run the install script without an enterprise contract in place. The same logic applies to a developer using the free tier of any LLM product for work-related code: consumer terms govern, and your content can be used to improve the product.

The enterprise DPA: what exists and what's missing

xAI does have an enterprise Data Processing Addendum at x.ai/legal/data-processing-addendum, effective June 9, 2025. The security controls documented there are solid:

• Per-customer AES-256 encryption at rest
• TLS 1.3 in transit
• Least-privilege access controls
• Regular third-party penetration testing
• Standard contractual clauses for GDPR compliance

The enterprise FAQ at x.ai/legal/faq-enterprise addresses training on business data directly, suggesting enterprise customers have different terms than the consumer privacy policy. A BAA template for HIPAA-covered use cases is available at x.ai/legal/baa.

The gap is documentation specificity. xAI's enterprise DPA applies to "customers of our business offerings, such as the xAI API." Grok Build on the free tier authenticates through grok.com, which is the consumer product. There is no publicly available documentation that explicitly confirms free-tier Grok Build users are covered by the enterprise DPA rather than the consumer privacy policy.

This is not a unique problem with xAI -- it's a common gap when a company's enterprise agreements were built around an API product and a new consumer-facing tool is released at speed. The fix is straightforward: if you want enterprise-grade data handling for Grok Build specifically, you need to contact xAI enterprise sales and get written confirmation that your CLI usage falls under the Enterprise Terms of Service and the DPA. Do not assume it transfers automatically from an existing API contract.

5 questions to answer before approving Grok Build

1. Which authentication tier are your developers on?

The authentication path determines which terms apply. Free-tier authentication via grok.com puts you on consumer terms. Enterprise SSO authentication -- if properly configured under an enterprise contract -- may put you on different terms.

Before approving install, confirm: does your organization have an active enterprise agreement with xAI? If yes, does that agreement cover Grok Build CLI usage specifically, or only API access? Get the answer in writing from your xAI account contact. If you do not have an enterprise agreement, treat Grok Build as a consumer tool with consumer-level data protections.

2. What code is actually leaving the machine?

Grok Build reads your codebase to build context for model inference. It also executes web searches from within agent sessions. Both the code it reads and the search queries it generates transit to xAI's servers. For most development teams working on non-regulated software, this is an acceptable tradeoff given comparable tools' behavior.

For teams working with regulated data -- customer PII embedded in comments, database connection strings with production credentials, proprietary algorithms with trade secret status, code that processes health data or financial records -- you need to scope exactly which repositories Grok Build can access before authorizing the install. The tool does not limit itself to a single file; it reads the broader codebase for context.

3. Is any of your code subject to regulatory requirements?

Four categories create hard stops for the free tier:

HIPAA: Protected health information in code, configuration files, or code comments requires a Business Associate Agreement. xAI's BAA template exists at x.ai/legal/baa, but it applies to enterprise customers, not free-tier users.

PCI-DSS: Any code that touches cardholder data environments requires vendors to meet specific data handling controls. Free consumer terms do not satisfy PCI-DSS requirements for third-party service providers.

Attorney-client privilege: Law firms and legal engineering teams whose code contains privileged communications need explicit confidentiality agreements. Consumer privacy policy terms are not a substitute.

Government and classified systems: Most government contracting requires FedRAMP authorization or equivalent for cloud services handling government data. xAI has no public FedRAMP authorization at this time.

If any of these apply to any codebase your developers might run Grok Build against, the answer is simple: enterprise contract with explicit terms first, install authorization second.

4. Do you have an existing enterprise agreement with xAI?

If your organization already uses the xAI API under Enterprise Terms, this is worth a direct conversation with your xAI account contact before your developers start installing Grok Build. The question to ask: "Does our current enterprise agreement and DPA cover Grok Build CLI usage, or do we need an addendum?"

Get that answer in writing. Do not assume that because your API access is under enterprise terms, the CLI tool authenticating via grok.com falls under the same contract. xAI's enterprise documentation was built around the API product; CLI coverage needs explicit confirmation.

5. What does your approved-tools policy say about AI coding agents?

If your organization already went through a vendor review process for Claude Code, GitHub Copilot, or Cursor, Grok Build needs to go through the same review. It is categorically the same type of tool: a system that reads your codebase and sends it to an external AI provider for inference.

The specific things to compare are the data handling commitments you required from approved tools:

• Did you require a no-training commitment? Get that from xAI or don't approve it.
• Did you require a DPA with GDPR standard contractual clauses? Confirm xAI's DPA covers this usage.
• Did you require a BAA for any team with HIPAA exposure? Confirm the BAA applies to the CLI.
• Did you require SOC 2 or equivalent certification? Verify xAI's current certification status.

The tool being popular is not a substitute for the vendor review. If anything, the 8,700 stars in 48 hours is a signal that your developers will install it regardless of policy if you do not act quickly. Getting the governance question settled now -- while the install wave is early -- is better than trying to reverse an established install base later.

Comparison: data handling across AI coding agents

This table reflects public documentation as of July 14, 2026. xAI's enterprise terms are not fully public; the Grok Build enterprise row is based on inference from the existing DPA and enterprise FAQ, not on explicit Grok Build-specific documentation.

What to actually do

Do not block Grok Build by default. Developer demand for this tool is real, the feature set is genuinely competitive, and a blanket block tends to push adoption underground -- which is harder to govern than a controlled approval.

The right response is a conditional approval with a fast lane for low-risk cases:

For teams with no regulated codebases and no existing enterprise concerns about AI coding tools: authorize Grok Build for non-production, non-sensitive repositories while you initiate the enterprise contract conversation. Set a 30-day deadline for the contract to be in place or the tool to be removed from the approved list.

For teams using regulated data (any HIPAA, PCI, government, or privileged code): do not authorize Grok Build on the free tier. Start the enterprise sales conversation. The contract needs to be executed, and you need written confirmation that the DPA and BAA cover Grok Build CLI usage specifically, before any install.

For the developers already running it: the 8,700 stars in 48 hours means some of your team has already installed Grok Build before this guidance reached them. Ask them to restrict it to non-sensitive, non-production repositories while the policy question is resolved. Do not ask them to uninstall it -- that signal tends to backfire. Give them a timeline and a path to approval.

The technical capabilities of Grok Build are not a reason for concern. The governance gap on the free tier is specific, documentable, and fixable with the right enterprise agreement. Move quickly -- the install wave is already underway.

For the vendor review process, start with the AI vendor due diligence checklist framework. Add a section specifically for AI coding agents that asks about training data policies, DPA coverage for CLI tools, and BAA availability for teams with regulated code. The privacy-first AI API comparison also provides useful framing for the no-training commitment question across multiple providers.

Related Reading

• AI Vendor Due Diligence Checklist 2026
• Privacy-First AI APIs: Which Providers Don't Train on Your Data
• MCP Server Security Governance Checklist 2026
• Vetting AI Tools for Malware and Supply Chain Risk
• AI Acceptable Use Policy Template for Small Teams
• Grok Build Uploaded Your Entire Git Repo to xAI, Secrets Included