SpaceXAI Team Bots: one shared agent holds the credentials

A shared AI agent is a shared set of keys. SpaceXAI opened Team Bots in public beta on Teams and Enterprise plans — Grok Bots that a whole team works with, carrying shared context, plugins, and third-party credentials, plus their own Slack handle. That last part is the one to read twice. A shared AI agent that holds credentials is not a chat feature. It is a service account with a personality, and most small teams have no process for issuing one.

What actually happened

Team Bots bundle four things into a bot a team shares: context (files and instructions), plugins (SpaceXAI names Salesforce, Notion, and GitHub), credentials for third-party API access, and memories that accumulate as people use it. Each member keeps their own private conversations with the bot while drawing on the shared skills — separate transcripts, common expertise. Plugins can be connected per person or configured team-wide.

SpaceXAI ships four pre-built types: a Customer Bot for sales account management, an EPD Teammate for product and engineering coordination, a Marketing Bot for brand consistency and content approval, and a Data Bot for warehouse queries. Each Team Bot gets a Slack handle and can be invited into a channel, where anyone can ask it questions and everyone sees the answers.

The one customer number in the announcement comes from Harper, an insurance company, which SpaceXAI says built a Team Bot in 24 hours to find lapsed policies and drive outreach — "saving our customers over $120,000." That is a customer quote in a vendor launch post, not an audited figure, and we would treat it that way. No pricing was disclosed, and no general availability date beyond the beta.

Why a shared AI agent changes your access control

Here is the mechanic that matters. A per-person assistant inherits that person's access and dies with their offboarding. A shared bot does not. It holds its own connections to Salesforce, GitHub, or your warehouse, it accumulates memory from everyone who touches it, and it answers in a channel where the audience is whoever is in the channel.

Three things to settle before you hand one a key.

Scope the credential to the bot, not to a human. If your Salesforce connection for the Customer Bot is somebody's personal OAuth grant, you have built a single point of failure that also violates least privilege. Issue a dedicated integration user with the narrowest object and field permissions the workflow actually needs. Read-only until a write is proven necessary.

Decide what goes in shared memory. A bot that learns from the whole team learns from the worst-scoped thing anyone pastes into it. Salary data, a customer's card last four, an unreleased price list — all of it becomes retrievable by the next person in the channel. Write the rule, then check the memory contents on a schedule instead of assuming.

Match the Slack channel to the bot's reach. Inviting a Data Bot with warehouse credentials into a channel that contains contractors is an access grant, whether or not anyone called it one. Audit the membership of every channel a bot lives in, and re-audit it when people leave.

The portable part of this is not the bot. It is your own definition of what each role is allowed to read and write. Write that down as a permission set you own, and any vendor's agent product becomes a client of it rather than the place it lives.

Sources: SpaceXAI, SpaceXAI Docs.