SpaceXSI says 130+ firms joined partner early access; 18 of 45 launch quotes name Cursor, which the post never explains

18 of the 45 launch quotes name Cursor, and the post never says how Cursor relates to SpaceXSI

SpaceXSI, the name used across x.ai, published "Introducing the SpaceX Super Intelligence Partner Network" on 22 October 2026. It prints 45 launch partner quotes. Counting them (derived, from the saved page text, see calc.py) gives this: 18 of the 45 quotes, or 40.0 per cent, name Cursor, 29 name SpaceXSI, and 6 name Grok Build. The post's own sentences outside the quotes mention Cursor zero times. That is the checkable fact. It was read on Monday 26 October 2026 from 09:45 GMT and checked again at 10:00 GMT, when the post and the program pages read the same.

What the count does not establish: it does not say what Cursor is to SpaceXSI, and the post does not say either. Other primary pages do, and the next section sets them out, starting with Cursor's own blog post of 14 August 2026 that says Cursor has been acquired by SpaceX. The count also does not show that 18 partners built on Cursor rather than on Grok Build, because the quotes and the program pages use the product names loosely, as the table in that section shows.

The post's two headline numbers are floors. It says "more than 130" companies took part in early access and that Forward Deployed Engineer accreditation has trained engineers at "more than 30" organisations. Thirty over 130 is 23.1 per cent (derived), but because both figures are printed as lower bounds the ratio is not a rate. Forty five quotes against more than 130 means at most 34.6 per cent of early access firms are quoted (derived), so at least 85 are not. The post names none of them, names no customer, gives no outcome figure and prints no price.

The post is marketing, and this briefing treats it as such. SpaceXSI sells Grok and gains from a larger network of integrators and plugin publishers, and several of the quoted partners resell, integrate or build services around its products, so each quote is a partner's own statement of interest and not a finding. Nothing here says a partner's product fails. The question is what a security team can rely on before it approves the platform together with a partner's plugins or engineers, and where the record is silent.

What Cursor is to SpaceXSI, from the primary pages

The post does not state the relationship, so the table below reads the primary pages directly. Each wording is quoted from the page and each date is the page's own.

So, as of 26 October 2026, two primary pages state the same fact: SpaceX bought Cursor, with the acquisition completed on 14 August 2026 (69 days before the post, derived). They do not say who runs the Partner Network. One partner, SCX.ai, writes on its own blog that Cursor accepted it into a "Cursor Partner Network" early access program, which suggests the two names refer to one effort, but that is a partner's phrase and not a SpaceXSI or Cursor statement. The pages also do not say which terms govern a partner's work on Cursor, Grok Build or Grok Bot, or whether the three share one security program.

That is the friendly name problem in this story. A control described as living in SpaceXSI has to be pinned to a product and a version before anyone can review it. Grok Build is, per x.ai's posts of 25 May and 15 July, an open source coding agent that runs in the terminal. Cursor is an editor, command line tool and cloud agent product from Anysphere, Inc. Grok Bot is a cloud agent product. The same partner is quoted with different product names on two SpaceXSI pages, as the next table shows. An earlier briefing on Grok Voice 3.0 recorded the same split between the SpaceXSI brand and the SpaceXAI LLC footer.

What the numbers support, and what they do not

Two of the numbers deserve a second look. The post does not say how many engineers were trained, what the accreditation tests, or who audits it, so "more than 30 organizations" counts firms and not people. And the 130 is not a list. The public partner directory on partnerportal.x.ai shows 58 entries, every one labelled Transformation, and its header calls them "validated SpaceXSI partners" without defining the word. That is 44.6 per cent of 130 at most (derived), and the directory shows no Marketplace partner at all.

The program pages also quote three partners that the post does not: ZS Associates, Robosoft Technologies and Chainguard. At least 48 distinct partners have therefore been quoted in public across the three pages (derived). The program pages describe tiers called Select, Premier and Elite for both programs with qualitative definitions only (for example "larger trained teams", with no numbers), print no fees, and list "validation as an authorized partner" as a benefit. No program terms were on any public page read; the partner portal has a sign in that this briefing did not use.

Governance and security claims: which ones name a control

Twenty one of the 45 quotes make a claim about governance, audit, guardrails, security or accountability (derived: 12 chosen up front because their quotes make an explicit control claim, plus 9 more found by keyword search and read one by one). This site sorted them by one rule. A claim names a control (class M) when it says what does the checking and where it acts. It names a product and a benefit (class V) when it mentions a tool and a visibility or review gain but not what it can block. It is adjectives only (class A) when the words are secure, governed, guardrails or audit trail with no control named. The sorting is a judgement, printed here so a reader can disagree with a row.

The other nine, Databricks, AHEAD, Booz Allen, EPAM, NTT DATA, Opsera, Sinch, Synechron and Webflow, use governance, secure, trusted or accountable as adjectives or outcomes (class A). The tally is 7 quotes that name a control, 3 that name a product and a benefit, and 11 that are adjectives only, out of 21. One in three, 33.3 per cent (derived), names a mechanism. A label such as "governed" or "guardrails" is not a control until a page says what is blocked, where, and what happens when the check itself fails.

Four integration claims checked against the vendors' own pages

These are the vendors' own statements, read on 26 October 2026, and each vendor sells the product it describes. They show whether the integration exists as described and when it was published. They are not independent tests.

Two things follow. First, the integrations are real as described, but two of the four (Sonar and Zscaler) describe Cursor and never mention SpaceXSI, and Sonar's predates the acquisition by 51 days and the post by 120 days (derived). A quote on a partner program page is not evidence that the integration was built for, or tested with, the program. Second, Endor Labs' wording that its hooks "enforce your policies before each action runs" and are "deterministic" describes the verdict logic. What the platform does when a hook fails is set by the platform, and x.ai's own page says it lets the call through, as the Technical details section prints.

SCX.ai and the CLOUD Act: what the statute covers

SCX.ai's quote says enterprise and government teams can run the coding platform with code, prompts and context that never leave Australian shores, with "no Cloud Act exposure". SCX.ai's own blog says the plugin points Cursor at its Australian endpoint and that every completion, agent step and tool call "resolves on SambaNova ASIC infrastructure in Sydney", with no input or output logging. SCX.ai sells that service. Note that the same chief executive's quote on x.ai's Marketplace page does not contain the Cloud Act phrase: it appears in one of the two SCX.ai quotes on x.ai pages (derived).

The statute is 18 U.S.C. section 2713, added on 23 March 2018 by Public Law 115 141, division V, the enactment commonly called the CLOUD Act. As printed by Cornell's Legal Information Institute and read on 26 October 2026, it requires a provider of electronic communication service or remote computing service to preserve, back up or disclose communications and records within its "possession, custody, or control", "regardless of whether" they are located inside or outside the United States. The test in the text is the provider's possession, custody or control, not where a data centre stands. The text does not name Australia or any hosting model, and it does not say which providers fall under United States jurisdiction. That is a question for counsel and this note is not legal advice.

What the record does not establish is the scope of the claim. The quote and the blog describe the inference leg. The editor, as SCX.ai writes, is still Cursor, a product now owned by SpaceX, and the pages read say nothing about what Cursor itself stores or processes when a model endpoint is replaced. A buyer who relies on the phrase needs the full data flow and a lawyer's reading, not the quote.

Marketplace plugins: four descriptions of review, none in the post

Marketplace Partners are the plugin publishers, so how a plugin is reviewed is the supply chain question for agent tools. The post is silent. The pages read give four different descriptions, and the pages do not say which catalog a Marketplace Partner's plugin lands in. The plugin submission form on x.ai offers three places to be listed: Grok (marked coming soon), Grok Bot and Cursor.

The friendly words here are curated, reviewed, validated and authorized. Each is a label until a page says what was checked, by whom, and what the reviewer will not promise. Two of the four sources say plainly that review is not certification, which is the more useful sentence for a security team.

Stated and not stated

Technical details

The post prints no configuration. The documentation does, and it answers the question a security hook raises: what can it read, what can it block, and what happens when it fails. Everything below is copied from x.ai and docs.x.ai pages for Grok Build and Grok Bot, read on 26 October 2026 between 09:45 and 10:00 GMT, or from the xai org plugin marketplace repository. Where a statement is this site's reading, it says so. The documents cover Grok Build and Grok Bot; the Cursor product has its own documentation, which this briefing read only for the marketplace pages.

A hook is a shell command or an HTTP endpoint that Grok Build calls on a lifecycle event. It receives the event as JSON on standard input, with hookEventName, sessionId, cwd, workspaceRoot and, for tool events, toolName and toolInput, and a PreToolUse hook decides by printing a verdict. The docs name PreToolUse as the only blocking event and say a timeout, a crash or malformed output lets the call proceed, with the failure recorded in the session. The default timeout is 5 seconds. Project hooks need a trust decision (the /hooks-trust command or the --trust flag), and Grok Build also reads Claude Code and Cursor hook files. A defender uses this to see that a hook is a gate that opens when it breaks.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "bin/safety-check.sh", "timeout": 10 }]
      }
    ]
  }
}

{ "decision": "deny", "reason": "Unsafe command detected" }

Permissions decide whether a tool call runs, in ask, auto or always approve mode, and deny rules beat ask rules, which beat allow rules. The docs say a remembered always allow grant still prompts for dangerous patterns such as rm and git push, but an explicit allow rule in configuration or on the command line auto approves them, and under always approve they run unless a deny rule exists. The sandbox is separate and is off by default.

[permission]
rules = [
  { action = "allow", tool = "bash", pattern = "git *" },
  { action = "allow", tool = "read" },
  { action = "deny",  tool = "bash", pattern = "rm -rf *" },
]

For managed fleets the docs describe a system layer at /etc/grok/requirements.toml whose pinned values cannot be overridden by user configuration, environment variables or remote settings. The lock on always approve is honoured only from root owned sources, and the docs say a Claude Code lockdown file does not carry over to Grok Build. These two blocks are the settings a security team would pin.

[ui]
disable_bypass_permissions_mode = true

[sandbox]
profile = "workspace"

MCP servers are declared in configuration, with secrets expanded from the environment, and the docs say tokens for servers that need OAuth are stored under ~/.grok/mcp_credentials.json. Project scope servers ship with the repository, and a project server with the same name as a user one replaces it entirely. Grok Build also loads MCP configuration from Claude and Cursor files. A defender hunts for unexpected entries in these files and treats the credentials file as a secret store.

[mcp_servers.filesystem]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
env = { API_KEY = "${MY_API_KEY}" }   # ${VAR} expands at load time
startup_timeout_sec = 30              # default 30
tool_timeout_sec = 6000               # default 6000

[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"
headers = { "x-mcp-session-id" = "{{session_id}}" }

A plugin bundles skills, slash commands, agents, hooks, MCP servers and language servers. In the xai org catalog a remote plugin is only an index entry, pinned to a full commit, and x.ai's launch post says Grok Build verifies the pin at install time. The install commands below are as printed in that post. The README warns that plugins "may execute code and access data on your system" and that xAI does not verify them.

{
  "name": "my-plugin",
  "description": "What the plugin does.",
  "category": "development",
  "source": {
    "source": "url",
    "url": "https://github.com/my-org/my-plugin.git",
    "sha": "0000000000000000000000000000000000000000"
  },
  "homepage": "https://github.com/my-org/my-plugin",
  "keywords": ["my-plugin"],
  "domains": ["example.com"]
}

grok plugin marketplace list
grok plugin install <name> --trust

Grok Bot, the cloud agent product, has a different control: inference hooks send each governed model request to a security server and wait for a verdict. The docs describe this as a beta that covers Grok Bot only, and not the command line tool, editor agents or Cloud Agents. A deny stops the next model call, not an action already taken. The mode decides what a failure does.

{
  "action": "deny",
  "deny_reason": "This message contains a customer account number. Remove it and try again.",
  "reference_id": "policy-7f3c21"
}

A ranked checklist for approving an agentic coding platform and its partners

This is for a security team anywhere that is asked to approve the platform together with partner plugins or partner engineers. The order is the order worth doing them in.

The question the record leaves open

If a partner's forward deployed engineer, working in your repository, installs a marketplace plugin whose security hook times out and lets the call through, and an agent then ships the change, which document says who answers for it: SpaceXSI's terms, Cursor's terms, the partner's contract, or none of them? The post names 45 firms and does not say.

Key facts