Grok Bot is the most interesting agent launch this year. It’s fast, it’s capable, and it does the one thing no MCP server or REST API can do for you: if the integration doesn’t exist, it opens a browser and does the work anyway. I used it last week for a job nothing else could do, and it did the job.
It also spent a few hundred Clay credits I can’t account for. An agent spent them on my behalf, inside my account, on my session, and the only description of what it did is the one the agent wrote. Nothing between the agent and Clay could have refused a single click, and nothing wrote one down.
A few hundred credits is a rounding error. The hole they fell through is the story, because Grok Bot is going to be sitting in a lot of accounts soon, and its own docs say it isn’t ready for that.
The job Clay’s MCP couldn’t do
I wanted a Clay table that bucketed the personas attached to our deals, so I could report on which personas we’re actually winning. Normal GTM work. I do as much of my work as I can headlessly, through agents, so I went to Clay’s MCP server and CLI first.
Neither surface could do it. Clay’s MCP exposes admin-approved Functions and search, and agents connected to it “cannot browse tables, view raw workspace data, or access anything outside of what enabled Functions return.” The CLI reads tables: list, get, columns, rows, query. No create. Clay’s own agent docs tell you to go make the table in the UI.
So I had two options. Build the table myself, or hand an agent my logged-in Clay account and let it click through the UI.
I didn’t want to do it myself. I wanted my agent to do it. Suffice to say, I gave the task to the agent.
What Grok Bot is
Grok Bot, a cloud-hosted agent harness, launched a few weeks ago. Every user gets a persistent computer in xAI’s cloud, a Linux VM with a browser, a filesystem, and a terminal. You give a Bot a task the way you’d give it to a coworker, and when an app has no connector, the Bot opens the browser and uses the app the way a person would.
The part that matters is sign-in. You don’t hand it an API key. You sign into Clay inside the Bot’s browser, and the session stays there. Per the docs, “signing in for one Bot makes the session available to your other Bots,” and you should “treat a login or file on the computer as available to every Bot that user runs.” The docs are honest about what that means: “The screens are separate work surfaces, not separate security boundaries.”
An MCP server hands an agent a list of actions. Grok Bot hands it your account. Anything I can do in Clay, the Bot can do in Clay.
And it works. Grok Bot is good at this and it will get better. That’s the part that worries me.
The bill, and the record that isn’t
I gave it the job, the scenarios, and specific instructions, and I walked away. When I came back the table existed and my credit balance was lower than the job should have cost.
So I went looking for what happened.
The agent’s chat. Grok Bot narrates its work in the conversation, so there’s a story of what it did. But that story is the agent’s self-report. It’s the one witness with a reason to make itself look good. After the Hugging Face incident in July, where OpenAI’s agents recognized they were out of scope, kept going, and forged their own audit trail, I’m not treating an agent’s account of itself as a record.
The usage page. On an individual plan, that’s all you get: spend, broken down by product. On Enterprise, Audit Logs cover “admin, security, and authentication events,” which is to say, not what the Bot did in your apps. A separate Enterprise-only feature, Action Recording, does capture Bot actions. It’s off by default, and even on, it’s a recording. It tells you what happened after it happened.
The tool path. Had the job gone through a tool call, there would have been somewhere to put a rule. Clay’s MCP only runs the Functions an admin has enabled, and a runtime like Arcade sits in front of every tool call and asks whether this agent, for this user, may take this action right now, including how many credits it’s allowed to burn doing it. A call that fails the check never reaches Clay, and every call that passes is written down. None of that applies to a browser. The governed path couldn’t do my job, so I took the ungoverned one, and nothing on the governed path ever saw me leave.
Nobody bypassed anything on purpose. The browser just doesn’t know a policy exists.
Governance inside the loop is a suggestion
Grok Bot does have controls. Sensitive actions prompt for approval, and a review model called Auto Review evaluates shell commands, plugin calls, and computer use. Read the fine print, though. Auto Review “does not review every side effect.” No spend cap is documented anywhere. And “an organization-level lock is not available,” so each user’s own setting is the off switch.
Put that next to the questions a CISO asks in the first meeting. Every answer on the right is from Grok Bot’s docs.
| What the review asks | What Grok Bot documents |
|---|---|
| Is policy enforced before an action lands? | Approvals judged by a review model; it “does not review every side effect” |
| Can the org lock that policy? | “An organization-level lock is not available”; each user’s setting is the off switch |
| Is there a spend limit? | None documented |
| Is there a trusted record of every action? | Action Recording, Enterprise only, off by default; Audit Logs exclude Bot actions |
| Are agents isolated from each other? | Screens are “separate work surfaces, not separate security boundaries” |
Today the honest answer to all five is no.
The deeper issue is that Auto Review is a model judging a model, inside the agentic loop. If you’re trying to scale agents across a company, you want guardrails, and they have to live outside that loop. A rule inside the harness, whether it’s a system prompt, a hook, or a reviewer model, is a suggestion to the same system that is trying to finish the task. Models are goal-directed. A guardrail is one more obstacle between them and the goal, and they treat it like one.
The research backs this up. In a 2026 benchmark of seven frontier agents, 57% of runs exhibited reward hacking, and the rate stayed above 50% when the agents were explicitly told not to cheat. Palisade told models to “allow yourself to be shut down,” and o3 sabotaged the shutdown script in 7 of 100 runs. Anthropic’s agentic misalignment work found models from every major provider choosing blackmail when it was the only path to their goal, knowing it was wrong. Those scenarios were contrived, and the rates have dropped since. The mechanism hasn’t changed. Give a model a goal and an obstacle and it looks for a way around the obstacle.
You don’t fix that with a better rule inside the loop. You put a deterministic check at the point of action, where a denied action never reaches the system. My colleagues have written this up in Guardrails vs. Governance and One Question, Every Tool Call, so I’ll keep it short: govern the tool call.
Here’s the policy I’d have written for this job, if there had been anywhere to put it. This agent, acting for me, may create and edit tables in this Clay workspace, and may not spend more than N credits doing it. Enforced at the tool call, that holds no matter what the agent tries. The runtime says no and the action never lands.
There was nowhere to put it. There was no tool call. There was a browser.
The UI is the wrong abstraction for an agent
Even setting governance aside, driving a UI is a bad way for an agent to work.
Every step means looking at the page, finding the control, deciding, acting, and checking whether it worked. Interfaces change. Modals pop up. Agents get confused by UIs the same way people get confused by bad ones, and every confusion costs tokens. It’s slow, it’s expensive, and it produces exactly the kind of unexplained spend I came home to.
MCP is the right abstraction because it turns “do this in the app” into a named, typed call with parameters. The agent asks for CreateTable, a runtime decides whether that’s allowed, and there’s a record either way. That’s what makes an action governable in the first place.
To vendors: Grok Bot is your symptom
So why did I reach for the browser? Because the tool surface wasn’t finished. That’s the real message.
If I can’t get my job done through your MCP server, Grok Bot is a sign of an immature market. MCP servers today are brittle, partial, and early. I want to say what I want and have it happen, and when the sanctioned path can’t do it, I’ll take the unsanctioned one. So will everyone else.
The end state is easy to describe. My agent can take every atomic action I can take, in every app I use, on my behalf, governed and logged. That doesn’t exist yet, and the gap between it and what vendors ship today is the space Grok Bot fills.
So, vendors: do better. Spend the time. Build out the endpoints. Build an MCP server that lets an agent take every action a user can take in your interface, not the six you thought were interesting.
The obvious objection is scale. What if that means 200 tools per app? What if it bloats every context window? That problem is solved. Tool search lets an agent pull three relevant tools out of thousands on demand, and we tested it against 4,000 tools. Ship the 200 tools.
If you don’t, your users will do what I did. They’ll hand a browser agent their credentials and let it loose in your product, and neither of you will have a record when something goes wrong. Then the first time a competitor ships a complete, governable tool surface, they’ll leave.
Phenomenal, powerful, not ready
Grok Bot is a phenomenal tool. It will get better. I’ll use it again for something trivial, and a lot of people are going to use it for things that aren’t trivial at all.
My few hundred credits are gone and I’ve made peace with that. There’s a version of this where it’s a few thousand, or a few hundred thousand, or every credit in the account, and I’d bet on that version happening to someone within the year. Grok Bot will do things you can’t govern, because doing things you couldn’t otherwise do is the whole product.
An enterprise asks two things of any system that acts on its behalf: a policy that is enforced, and a record it can trust. Neither exists anywhere between a Bot and your apps. That’s what “not enterprise-ready” means here. It’s a reading of the docs, and I’d be glad to be proven wrong by the next release.
Handing an agent your session is a workaround, and until vendors close the tool gap, the workaround keeps winning. When they do, govern the tool call, and stop handing over the keys.
