back to artifacts
Grok Bot Is Not Grok: It Is a Cloud Computer With Your Logins
xAI's Grok Bot has its own machine, signs into your tools, and reaches X through @bot. The chat is the boring part — the permissions are the story.
Every time Grok shows up in a conversation, someone says "it is just Grok with a memory." That is the wrong mental model, and it is wrong in a way that matters once you start deciding what to give it.
The landing page for Grok Bot says Bots have their own computer. Not a chat window with tools bolted on — a persistent cloud machine where they sign into your apps with your credentials, run scheduled routines, and keep working while your laptop is closed. The X integration everyone keeps talking about is the smallest part of it.
I read the changelog before the marketing page, which is backwards, but it turned out to be the honest one. Version 0.79.x from this November is about shared page themes, gift requests, airline checkout, refunds, and 1Password filling logins the Bot cannot see. That is not a chatbot roadmap. That is an operating system with a credit card.
@bot is a doorway, not a chatbot
The thing most people mean by "Grok bot" is @bot, the account you mention on X. According to X's own help page, @bot does not answer requests itself — it forwards your request to your Grok Bot. If no Bot is connected, nothing happens: you have to install the X plugin inside the Bot app and sign in with the X account you want it to use.
X's own help page: @bot is a doorway. The example request is a reminder, which is about as harmless as this gets.
Two details in that page are easy to miss:
- Connecting may create an X developer account for you if you do not have one.
- Paid Grok Bot users may receive X API credits to get started.
Read those together and the architecture becomes obvious. The Bot is not scraping X as a browser tab. It gets API access, which is exactly why the rules below are written the way they are. Once the plugin is connected, the Bot can search posts, read timelines, check mentions, and pull trends and bookmarks.
So the pitch is not "chatbot that posts for you." It is "an agent that can read and act on X, alongside everything else it is already signed into."
The product is the computer
Here is the part that should make you slow down.
The FAQ states that every Grok Bot shares one persistent computer — your Bots share the machine, the files, the browser, and the logins. Isolation is per user, not per Bot. A "Research" Bot and a "Comms" Bot are not sandboxes; they are roommates.
Then there is the stack of privileges that has quietly accumulated in the changelog:
- Vault — saves logins, cards, and contact info, and fills them in at sign-in and checkout.
- 1Password connection — each login is approved inside 1Password, so the Bot's browser gets the fill, not the secret.
- Auto-review — a second pass decides whether an action needs a human approval card.
- Routines — recurring work on a schedule, running on the Bot's own machine.
- Pages — reports and dashboards the Bot builds, which you edit together.
- Slack and Teams — team Bots can be messaged directly, and the Bot records who asked for each post.
- MCP and Tailscale — Bots can reach MCP servers on your private tailnet.
- A shell — the Bot's computer can run
sshandpsql, per the 0.79.2 changelog.
The last two items are where I stopped skim-reading. If a Bot can reach your tailnet and open a shell, "prompt injection" stops being a theoretical blog-post risk and becomes a network access question. A malicious page does not need to steal a token anymore; it just needs the Bot to call the tool.
The tiers, for context: Premium at $30/month, Super at $100, Ultra at $200, and Grok Bot is included with eligible Premium, Super, Ultra, Teams, and Enterprise plans. The interesting number is not the price — it is that all of this is a consumer subscription, not an enterprise deployment.
The policy is the hard part
If your plan is "I will build a reply bot," the API docs are not the blocker. The X automation rules are, and they are blunt.
From the automation rules (updated April 2026), Section II.B.3, in full:
the deployment or operation of any AI reply bot requires prior written and explicit approval from X.
Help Center, captured 12 November 2026. The note above it asks brands to request approval for auto-response campaigns.
Not a checkbox, not a rate limit — written approval. The same document bans automated replies driven by keyword search alone, requires that the recipient opted in (following you is explicitly not enough), limits you to one automated reply per interaction, requires an easy opt-out, and warns that scripting the website instead of using the API can get the account permanently suspended.
Meanwhile, in July 2026, X's head of product posted live updates about an anti-spam sweep: 42,000 accounts automating replies with chatbots, removed. X said the method being used with Grok had been blocked, and that most of the activity was economically motivated — accounts growing reach to sell promotion to AI companies.
Put those two facts next to each other and you get the real lesson: the technical ability to auto-reply has never been the constraint. Every one of those 42,000 accounts had the ability. What they did not have was approval, opt-in, and a reason a human would want the reply.
Prompt injection is now a product feature
My favorite line in the entire changelog, from 0.79.2:
When a web page hides instructions for AI agents, the Bot tells you it found them and didn't follow them.
The 0.79.2 entry, between an airline-booking fix and a gift-request feature. Read it as a security note.
Good behavior, and also a confession. Pages are already written to hijack agents by hiding text in them. The Bot refuses and reports it, which is the right default, but it also means the threat is common enough to need a UI. If you are building with an agent that browses, assume every page is hostile until proven otherwise, and keep the destructive actions behind an approval card.
What I would actually build
I would not build a reply bot. The approval process alone makes it a business decision rather than a weekend project, and the reward is a reply a human could write in twenty seconds.
What Grok Bot is genuinely useful for is work that is annoying but low-stakes:
- A mention digest. Every morning, read my mentions and timeline with the X plugin, group them, and draft replies I can copy. Drafts, never posts.
- A research runner. Search posts and trends for one topic, keep notes in a page, and hand me a summary I can argue with.
- A routine around a routine. The changelog's "watch me do it once, then do it yourself" idea is the only agent feature that has ever saved me time in practice.
Notice what those have in common: the Bot prepares work, and a human commits it. The moment the Bot is the one hitting send, you have inherited both the policy requirement and the trust problem.
What I would not hand over
Payments, refunds, and purchases. The Bot can place an order and request a refund for a subscription charge. Auto-review might approve it. The changelog shows the team thinking about this — approvals show the checkout total, gift orders ask for budget and deliver-by date — but the failure mode is money leaving an account, and no amount of "it usually gets it right" fixes a wrong order.
Bulk following, liking, or reposting. The rules ban automated likes and bulk follows outright, and those are the patterns that get accounts removed.
And nothing that touches production credentials from a shared machine that every Bot can read.
The bottom line
Grok Bot is not a better Grok. It is a hosted computer with your logins, a credit card-shaped hole in your approval flow, and a policy department you have to talk to before it posts.
That is not a reason to avoid it. It is a reason to decide the permissions before the prompts: which apps, which accounts, which actions need a human, and what it is never allowed to do. The chat is the easy part. The permissions are the product.
If you are building on X at all, read the automation rules first. Then read them again before you connect a Bot to your account.
related documents
ai · 3
Developer ในยุค AI ในมุมของผม: งานไม่ได้หายไป แค่ย้ายจาก "พิมพ์โค้ด" ไป "ตัดสินใจและรับผิดชอบ"
16 Nov 2026 · 2 min read
สรุป: เปลี่ยน Grokbot ให้เป็นระบบ Multi-Agent 300 ตัวด้วย Kimi K3
15 Nov 2026 · 3 min read
Gemini 4 Hydrogen: โมเดลที่ทำงานเร็วและราคาถูกสำหรับ agent workflow และการสลับโมเดลกลางคัน
13 Nov 2026 · 4 min read