Build a Simple, Safe AI Agent for X: The Grok-Bankr Lesson

Building an AI agent for X sounds simple right up until you look closely at what actually happened to Grok in May 2026. An attacker replied to Grok in Morse code, Grok translated it faithfully, and a connected trading bot read the decoded output as a signed instruction to move 3 billion tokens. The loss: somewhere between $155,000 and $200,000, depending on which snapshot you check.

The common summary is "Grok got hacked." That's not quite right, and the actual story is more useful to a builder than the headline version.

This guide covers what really happened, what X changed afterward, and how to actually build an AI agent for X without repeating the mistake. Everything here assumes you're building something that reads, reacts, and eventually posts, not something that gets anywhere near a wallet by accident. If you've built a read-only monitor with Hermes before, the pattern will feel familiar, the tools are different, but the core discipline is the same: treat untrusted input as untrusted, gate anything irreversible behind a human.

The post that kicked it off is still up:

.

What Actually Happened

Grok holds no private keys, signs no transactions, and has no onchain agency of its own. It's a text generator. The actual failure sat one layer downstream, in Bankr, a trading bot that auto-provisions a wallet for any X account it interacts with, including Grok's.

The attack had two stages. First, the attacker sent a "Bankr Club Membership" token to Grok's auto-provisioned wallet. Holding that token was treated as a permission grant, unlocking transfer capability that a normal wallet wouldn't have. Second, the attacker replied to Grok on X asking it to translate a Morse code message. Grok did exactly that, and the decoded text turned out to be a transfer command formatted for Bankr's scanner to read.

Bankr's scanner watched public replies for anything that looked like a valid command from an authorized wallet. It found one, and it executed. No human reviewed the transfer before it went out. No secondary check confirmed the request actually came from someone with authority to move funds. The scanner did exactly what it was built to do, which turned out to be the problem.

Security researchers classified this as two separate OWASP LLM failures stacked together: LLM01, prompt injection, and LLM08, excessive agency. Both were necessary. Either one alone wouldn't have been enough to drain the wallet.

The Fix Already Existed

Here's the part that should change how you build. Bankr's own developer documentation already warned against exactly this setup. It instructed builders to require a Telegram approval step before letting any wallet-linked AI account trigger a transfer through @bankrbot.

Grok's integration never turned that safeguard on.

That's not a story about a novel attack nobody could have predicted. It's a story about a known mitigation that existed in the docs and wasn't wired in. Every agent you build for X should start from the assumption that any text a stranger can send you is untrusted input, including replies, mentions, and quote tweets, and that nothing high-stakes should execute on the strength of that input alone.

This is worth sitting with for a second, because it's the opposite of how most builders think about their own agent. The instinct is to worry about the LLM's reasoning: will it pick the right words, will it stay in character, will it handle edge cases. The Grok-Bankr incident wasn't a reasoning failure at all. Grok reasoned correctly. It translated Morse code accurately, which is exactly what it's supposed to do. The failure was entirely in what happened after the reasoning finished, in a downstream system that trusted the output too much.

What Changed on X Since Then

X has since tightened the rules in a way that actually helps here, even though it wasn't designed as a security fix. As of February 2026, the API restricts programmatic replies on every self-serve tier. An agent can only reply to a post if the original author already mentioned it or quoted it first.

A follow-up enforcement wave, publicly nicknamed "Operation Kill the Bots," went further in March 2026: unsolicited replies, quote tweets, and mentions now return a 403 even where the API documentation still lists them as available.

The practical effect: an agent for X today is naturally scoped down to conversations it was already pulled into. That's a smaller attack surface than an agent that can reply to anyone about anything, but it's not zero. Being mentionable at all means anyone can hand your agent a prompt.

None of this restricts reading. An agent can still watch a timeline, search for keywords, or track mentions freely, the API limits are specifically on unsolicited outbound actions like replies and quote tweets. That distinction matters for how you design the build below: reading is cheap and low-risk, acting is where the caution belongs.

Build Steps for a Safe AI Agent for X

Step 1: Get X API Access

The free tier covers 1,500 posts and 500 reads per month, enough for a low-volume agent. The Basic tier runs $100/month for 3,000 posts and 10,000 reads if you need more headroom.

Apply through the X developer portal and generate five credentials: API key, API secret, bearer token, access token, and access token secret. All five are required by the MCP server in the next step.

Approval isn't always instant, budget a few days before you plan to go live, not a few hours. If your use case involves anything crypto-adjacent, describe it accurately in the application. Vague applications get more scrutiny, not less.

Step 2: Install Hermes and Connect an X MCP Server

Use x-autonomous-mcp, an MCP server built specifically with rate-limited, self-enforcing safety rails rather than raw API access.

mcp_servers:
  x-agent:
    command: "node"
    args: ["/path/to/x-autonomous-mcp/dist/index.js"]

Set the five X API credentials as environment variables where the server runs, then reload:

/reload-mcp

Step 3: Set Conservative Budget Caps

The server enforces hard daily limits per action type, regardless of what the LLM decides to do:

X_MCP_MAX_REPLIES=8
X_MCP_MAX_ORIGINALS=2
X_MCP_MAX_LIKES=20
X_MCP_MAX_RETWEETS=5
X_MCP_MAX_FOLLOWS=0
X_MCP_MAX_UNFOLLOWS=0

Start lower than the defaults, especially on follows and unfollows. There's no reason a new agent needs to touch your follow graph in week one.

Step 4: Route Real Posts Through Human Approval

This is the step Bankr's setup skipped, and it's worth being precise about what "approval" means here versus what we've covered in other builds on this site.

Base MCP's transaction approval is hard-enforced. The tool cannot execute a transfer without a cryptographic signature you provide. x-autonomous-mcp's budget caps are real limits, but nothing here stops the agent from calling reply_to_tweet the moment it decides to, short of you writing that constraint into its instructions.

The workaround is a soft gate, and you should know it's soft: instruct the agent to draft a reply, send the draft to your Telegram, and wait for an explicit "approved" message before calling the posting tool. That's enforced by the agent following instructions, not by a technical barrier the tool itself imposes. Treat any output the agent produces as a draft until you've read it.

Step 5: Label the Account

X's developer guidelines require enabling the "Automated" profile label through app settings, plus a bio disclosure. "Automated account run by [you]" in the bio is enough to clear that second bar. Skipping either risks the account getting flagged regardless of how well-behaved the agent is otherwise.

Step 6: Start Read-Only, Then Add Likes, Then Replies

Run the agent for a week doing nothing but reading mentions and logging what it would have said. Add likes next, since a wrong like is nearly harmless. Only enable replies once you've watched it handle a few real mentions correctly under supervision.

Posting is the last capability to turn on, not the first thing to test.

Keeping Tabs on What It Actually Posted

Once replies are live, check in on the account daily for at least the first couple of weeks, not just when something looks wrong. Two things to compare:

A gap between those two, a post that shows as sent in your logs but reads differently on the live account, or vice versa, is worth investigating immediately. It usually means either the approval step got bypassed somewhere or the agent misreported its own action.

Hard Gate vs. Soft Gate

Common Mistakes to Avoid

• Treating budget caps as a substitute for review. A cap limits damage. It doesn't catch a bad reply before it posts.
• Enabling replies before the agent has a track record. Read-only, then likes, then replies, in that order, not all at once.
• Skipping the automated account label. It's a small thing that avoids a much bigger problem later.
• Assuming the reply restriction protects you from prompt injection. Being mentionable at all is still an open door. Scope, don't eliminate, the risk.
• Forgetting that a mention is untrusted input. Anyone can mention your agent. Treat what they say the same way you'd treat an email from a stranger.
• Connecting the X agent and a wallet-linked agent through shared state. If your Hermes instance runs both the X posting agent and something with wallet access, keep their memory and instructions clearly separated. A prompt injected through X shouldn't have a path to influence a decision the wallet-side agent makes later.
• Not rehearsing the shutdown. Know how to pull the API keys or kill the process before you need to do it under pressure. hermes cron stop and revoking the X API keys from the developer portal should both be one command away, not something you're looking up for the first time during an incident.

Why the Two-Stage Attack Matters for Your Own Design

Look back at the actual sequence: privilege escalation first, prompt injection second. Neither stage alone would have worked. The membership token gave Grok's wallet elevated permissions it didn't need for its actual job of replying to posts. The Morse code message only became dangerous because that elevated permission was already sitting there waiting for a valid-looking command.

The transferable lesson isn't "watch out for Morse code." It's "don't grant your agent more standing permission than its narrowest task requires, and re-check what permissions have accumulated over time." Bankr's system let permissions build up silently through ordinary interactions, the DRB token and its trading history existed for months before anyone weaponized it. An agent that's been running quietly for a while is worth periodically auditing for exactly this kind of accumulated capability, not just reviewing at setup and forgetting about it.

FAQ

Was Grok actually hacked? Not in the traditional sense. Grok has no wallet and no signing ability. The failure was in Bankr's scanner, which was built to treat public replies from Grok as authorized financial commands. That's a design choice, not an intrusion.

Can I still build a reply bot on X in 2026? Yes, but only in response to mentions or quotes, per the current API restrictions. A bot that proactively replies to arbitrary posts is no longer possible on self-serve tiers.

Is x-autonomous-mcp official or third-party? Third-party, but it uses the official X API rather than scraping, which matters, since X's automation rules explicitly prohibit unofficial API access and browser automation.

What happened to the stolen funds? Roughly 80% was recovered after the DRB token community tracked down the attacker's identity and negotiated a return, according to reporting at the time.

Do I need x-autonomous-mcp specifically, or will any X MCP server do? Any MCP server that uses the official X API will technically work. The reason to pick one with built-in budget caps is that it enforces limits even if your prompt instructions have a gap you haven't noticed yet. Treat it as a second layer, not a replacement for careful prompting.

How much does running this actually cost month to month? The X API itself is the main cost, free if you stay under 1,500 posts and 500 reads monthly, $100/month on Basic if you need more. Add whatever you're already paying for the LLM provider and a small VPS if you don't have one running yet. For a low-volume account, free-tier X API plus an existing Hermes setup costs nothing extra beyond LLM usage.

What's the single biggest lesson from the Grok-Bankr incident for someone building this today? That the vulnerability wasn't exotic. It was a known, documented gap between what a public AI account can be made to say and what a connected system chooses to trust. Anyone building an AI agent for X that both reads public replies and can take a real action is exposed to some version of this until they explicitly close the gap.

Is it actually worth building an AI agent for X given all of this? Yes, most agents never touch a wallet at all, and the risk profile for a content or engagement agent is much lower than Bankr's setup. The incident is a reason to design carefully, not a reason to avoid building one.

Sneak peek: if this agent eventually needs to move funds too, tipping a good reply in a token, for instance, that action needs the hard-gated approval flow from Build an Onchain AI Agent, not the soft-gated posting flow covered here.