GitBook Says AI Agents Attacked It: Rotate API Tokens, Git Sync Secrets and Re-Authenticate the MCP Server

GitBook, the documentation platform, says it was hit by "a sophisticated, highly targeted attack using AI agents" that reached some of its infrastructure credentials at 19:00 CET on November 2, 2026. GitBook revoked every customer's API tokens, replaced all of its own credentials, and is telling customers to rotate third-party secrets and, if they use the GitBook MCP server, re-authenticate it. If a coding agent of yours can read or edit GitBook content, the token it carries is the first thing to replace.

GitBook's security incident page is the primary source for everything below. Where a point comes from a community discussion rather than GitBook, it is flagged. The company says a full post-mortem will follow, so several important questions are unanswered today.

TL;DR

What GitBook has confirmed

The incident page records two updates, both on November 3, 2026.

• Timeline: the attacker gained unauthorized access to infrastructure credentials at 19:00 CET on November 2. GitBook says it detected the attack immediately and acted to block further impact. By 13:15 CET on November 3 it described a platform-wide issue affecting a number of customers and said some services were offline as a precaution. By 16:21 CET the GitBook app, the GitBook API and published docs were available again, with a few services possibly still degraded.
• Containment: GitBook says it blocked the attacker and closed the vulnerabilities involved, replaced every credential and secret across its infrastructure, brought services back only when confident they were secure, and invalidated every customer's API tokens.
• Availability choices: the app and authenticated docs sites were taken offline, while publicly published content stayed live as long as possible from cached data.
• Data that may have been accessed: integration tokens, Git Sync secrets, API tokens, and the questions site visitors asked GitBook Assistant.
• Not found: evidence that content in GitBook was modified.
• Still to come: more security measures, ongoing monitoring for further attacks, and a full post-mortem with more detail.

An early update at 13:15 CET said "Action required: None at this time." That was superseded by the 16:21 CET update, which lists the rotation steps below. If you read the early note and stopped, go back to the current page.

What is not known

Be careful with the headline phrase. "Attack using AI agents" is GitBook's characterization; the page does not explain what the agents did, whether they found the credentials through a vulnerability, a leaked secret or a compromised account, or which infrastructure was reached. One commenter on the Hacker News thread, latchkey, said exactly this: that "the attacker gained unauthorized access to some of our infrastructure credentials" leaves open how, and which infrastructure. That is a fair reading of the current disclosure. GitBook's CTO, posting as SamyPesse, said the team had taken a large portion of services offline to prioritize user security and would keep users updated by email, Slack and the status page.

Another commenter, philipwhiuk, noted that the summary on GitBook's status page did not mention "the unauthorized access" at the time. The practical lesson: read the dedicated incident page, not just the status banner.

Nothing here lets us say how many customers were affected, whether stolen tokens were used, or whether this is part of a wider campaign. The Cloud Security Alliance's research note on platform-chain campaigns against AI serving describes a series of attacks on platform companies and says no vendor has publicly linked them to a single actor. GitBook has not claimed a link either. We covered the closest recent parallel, Northflank's control-plane secrets incident, where the stolen asset was also stored secrets.

Why each exposed credential type matters

Documentation platforms look low-risk, but each item on GitBook's list is a bridge into something else.

1. API tokens. A GitBook API token lets a caller read and change spaces and content as the user who issued it. GitBook revoked personal tokens, so old ones should already fail. Any service account or organization-level token you created should still be rotated, and you should confirm what actually stopped working.
2. Integration tokens and published-integration secrets. Integrations connect GitBook to other systems such as chat, analytics or support tools. A token stored for one of those lets an attacker reach the other side. The same goes for secrets you hold as the author of a published integration.
3. Git Sync secrets. Git Sync links a GitBook space to a repository. Whatever credential GitBook uses to read or write that repository may have been exposed. If it is a deploy key or a personal access token with write access, that is a path into your source code, which is the part most relevant to coding-agent users. Replace it with a narrowly scoped credential, ideally read-only if you only publish from the repository.
4. GitBook Assistant questions. Visitors' questions can contain context that people should not have typed into a public docs box: product names, error messages with internal hostnames, occasionally pasted keys. Review whether your docs assistant is exposed to private information and plan for the possibility that these were read.
5. MCP sessions. GitBook asks users of its MCP server to re-authenticate. An MCP server is an agent-facing connection: the agent calls tools on it using a stored credential or OAuth session. If that session was exposed, someone else could call the same tools. Re-authenticating issues a fresh session.

What this means if you run AI coding agents

Do the following in order, and stop to verify after each step.

1. Find where GitBook credentials live on your machine and in CI. Search your agent configuration, shell profiles and project files for GitBook tokens. For Claude Code that includes the project .mcp.json, your user MCP configuration, and any environment files an agent can read. Replace anything you find, rather than only the one you remember.
2. Rotate GitBook API tokens and create new ones with minimum scope. Prefer a token per tool so a single leak can be revoked alone. Remove tokens you no longer use.
3. Re-authenticate the GitBook MCP server in every agent client that uses it, and remove stale server entries you no longer need. Check the agent's MCP list afterwards to confirm the old session is gone.
4. Rotate third-party secrets connected to GitBook. That means the credentials GitBook holds for Slack, analytics, search, or support integrations, rotated at the third party and then updated inside GitBook, not only inside GitBook.
5. Replace Git Sync credentials and review recent commits and branch activity on the synced repository for changes you did not make. GitBook says it found no evidence content was modified, but your repository log is the independent check.
6. Look for use of the old tokens. Check your own services' logs and the audit or access logs of any system the tokens could reach, for requests from unfamiliar IP addresses or at odd hours since November 2. If a provider offers token-usage logs, read them.
7. Review GitBook content for planted instructions. Docs are text that agents read. If an attacker had modified pages, an agent that reads them could be steered by hidden instructions. GitBook says it found no modification, but a quick diff of pages your agents use as context is cheap.
8. Do not assume. Treat the first rotation as a floor. When the post-mortem lands, re-check the affected list.

What Beam can and cannot do here

The compromise happened inside GitBook's hosted infrastructure, so Beam cannot detect it or reverse it. Beam is local, on-device security and observability for coding agents; it does not see what happens on a vendor's servers.

What it can help with is the local side of the cleanup. Beam's skill and MCP scanning checks MCP configurations and skills with its heuristics, including a version-pin check, which makes it easier to spot a GitBook MCP entry you forgot about or one that is not pinned. Sensitive values are redacted before storage, so a token that appears in an agent transcript is not kept in clear text. The limits matter: the scan is heuristic, and deny decisions for Claude Code and Codex depend on PreToolUse hooks with a workspace policy; they are not a kernel sandbox, and the policy path can fail open. Everything stays on your device either way. See how Beam works and what stays local.

Pattern: platforms that hold your tokens

GitBook is the latest in a run of developer platforms telling customers to rotate stored secrets. We wrote up the Railway breach, the second Zeabur breach, and Wiz's analysis of stolen AI keys across developer platforms. The recurring lesson is structural. Any platform that stores your long-lived tokens becomes a target, and an agent that holds a long-lived token widens the blast radius. Short-lived, narrowly scoped credentials, one per tool, make each of these incidents a smaller job to clean up.

For readers following the wider story of attackers using agents, our write-up of what Google and Mandiant saw agentic attack frameworks do covers the offensive side that GitBook now claims to have experienced.

Frequently asked questions

What happened in the GitBook security incident?

GitBook says it was the target of a sophisticated, highly targeted attack using AI agents. At 19:00 CET on November 2, 2026 the attacker gained unauthorized access to some of its infrastructure credentials. GitBook detected it, blocked the attacker, took the app and authenticated docs offline, replaced every credential and secret, and restored service on November 3.

What data may have been accessed?

GitBook lists four things the attacker may have accessed: integration tokens, Git Sync secrets, API tokens, and the questions your site visitors asked GitBook Assistant. It says it has found no evidence that any content in GitBook was modified. Its investigation is still ongoing and a full post-mortem is promised.

What do I need to do right now?

Rotate any GitBook API tokens (GitBook revoked all personal tokens), rotate third-party tokens or secrets used to connect other tools to GitBook, rotate secrets used by any published integrations, and re-authenticate the GitBook MCP server if you use it. Ask your GitBook organization admin if you are not one.

Why does this matter if I use a coding agent?

Agents often hold GitBook API tokens or an authenticated GitBook MCP connection so they can read or edit docs. A stolen token can be replayed by anyone, so any such credential should be treated as exposed until replaced, and the agent configuration that stores it should be updated.

Is it confirmed that AI agents performed the attack?

That is GitBook's own description. It has not yet published technical details of how the agents were used or how the credentials were obtained, and no independent forensic report exists at the time of writing. Treat the AI-agent claim as the vendor's assessment until the post-mortem appears.

Is this connected to the Northflank, Railway or Zeabur incidents?

Not confirmed. GitBook has not linked its incident to any campaign. The pattern is familiar, though: platforms holding customer tokens and secrets are being targeted and customers are told to rotate. Cloud Security Alliance has described a cluster of such attacks on platform companies, but it notes no vendor has publicly tied them to one actor.

Related reading

• Northflank security incident: control-plane secrets and what to rotate
• Railway breach: environment variables and AI keys
• MCP TypeScript SDK OAuth credential leak (CVE-2026-104850)

Details here reflect GitBook's incident page and public discussion as of November 3, 2026. The investigation is ongoing and GitBook has promised a post-mortem, so facts and the list of affected data may change. Check the incident page before acting on anything above.