Cathedral Says Its Agents Got Into Anthropic in 12 Hours via SaaS

On 2026-10-26 a security startup called Cathedral said its AI agents had found paths into Anthropic's internal systems in under twelve hours. Cathedral says the entry was not through Claude and not through a model jailbreak, but through third party administrative and sales software. Anthropic confirmed some access, disputes how the test was run, and says it shut the access off the same day. Both accounts can be true at once, and the part that matters for your company survives either way.

What Was Actually Claimed

Start with what is on the record, because the retellings already drift. According to Decrypt's report, Cathedral says its agents reached Anthropic's business systems within twelve hours, with the entry point being what the report describes as third party administrative and sales software. Anthropic's side, as quoted there, is that customer conversations, source code and model weights were not accessed, and that it shut off Cathedral's access the same day.

Silicon Report's account adds the part Anthropic did concede: access to a limited set of sales, HR, and IT systems. It also gives the context on the accuser. Cathedral raised $160 million at a $1.4 billion valuation in July, which means a security startup with fresh money and a strong commercial reason to publish a dramatic result. That is not evidence the result is wrong. It is a reason to read the claim the way you would read any vendor benchmark.

What we do not have is the test protocol, the scope agreed in advance, if any, or an independent review. We do not know how much of the twelve hours was agent time versus setup, whether humans steered, or which vendor products were involved. Those gaps are exactly where the dispute lives, and none of them change the engineering conclusion below. We will say "Cathedral says" and "Anthropic says" throughout, because that is the state of the evidence.

Cathedral Says Claude Was Not the Door

The instinct on reading this headline is to file it under AI safety. Agents attacked an AI lab, so the lesson must be about models. Cathedral says it is not. By its own account the path ran through third party administrative and sales software, not through Claude. Anthropic disputes how the test was run, so treat the entry path as a claim.

That should recalibrate where you spend security attention. Most organisations that worry about AI risk worry about their own model deployments: prompt injection, data leakage through a chatbot, a coding agent with too much access. Those are real, and we have covered them in our piece on why prompt injection is still unsolved. But the attacker does not have to engage with your AI at all. The attacker needs the cheapest path to your data, and that path is the vendor you onboarded in a hurry in 2022 with a broad OAuth grant and an admin who has since left.

Anthropic confirmed access to a limited set of its sales, HR, and IT systems. A company with a small security team and many SaaS subscriptions should assume its own exposure is at least as wide.

Why Vendor SaaS Is the Soft Edge

Walk through what a typical SaaS integration actually contains. A sales platform connects to your email through an OAuth grant. It syncs to your CRM, which holds customer contacts. It posts to your chat tool through a bot token. It reads your calendar. Each of those connections was approved once, by a person trying to get a feature working, usually with the broadest scope on the consent screen because the narrower one broke something.

Four properties make this layer attractive to an attacker and hard for you to see.

First, the credentials are long lived. An API token issued to a vendor integration often has no expiry. It sits in a settings page for years. Second, the scopes are wide because nobody audited them. Third, the activity is invisible to your tooling: the vendor's servers make the calls, your logs show a trusted application doing what it always does, and your identity provider never sees a login. Fourth, the admin consoles of these products are internet facing by design, protected by a password and perhaps a second factor, and shared among more people than anyone wants to count.

None of this is new. Breaches through a single compromised SaaS integration have been a recurring pattern for years. What is new is the cost of finding the weak link, which is the next section.

What a Chain Looks Like

The public accounts do not describe Cathedral's exact steps, so this is an illustration of the general shape, not a reconstruction. Suppose a sales tool holds a token that can read mailboxes. Mailboxes contain password reset emails, shared documents, and the names of other internal tools. Those names point to an HR system, which has its own support portal. The support portal accepts a reset sent to an address the first token can read. One weak grant has opened a second system, and the second system names a third.

Each hop on its own looks minor. A security review of the sales tool would rate the token as medium risk. A review of the HR portal would rate the reset flow as low risk. The danger is in the composition, and composition is what a human reviewer working through a spreadsheet of separate vendor assessments never sees. An agent that holds the whole graph in context does. It does not need to rate anything. It tries the edge and observes whether it opens.

Note what that chain does not require: a software vulnerability. No exploit, no zero day. Only the permissions that were already granted and the trust the systems extended to each other. That is why a patch cadence, however disciplined, does not cover this surface. You are defending against legitimate access used in an order nobody anticipated.

What Agents Change About the Economics

A human penetration tester working a SaaS estate does what an agent does, only slowly. Enumerate the tools the company uses from job postings and DNS records. Find the admin portals. Check for exposed tokens, default settings, forgotten test accounts, over permissive sharing links. Find one foothold in one tool, read what it contains, discover credentials or contacts for the next tool, and pivot. The work is mostly patience and breadth, and it does not need genius at any single step.

Patience and breadth are precisely what language model agents provide cheaply. An agent does not get bored on the fortieth login page. It runs the same reconnaissance against dozens of targets in parallel. It reads documentation for products it has never seen and tries what the documentation says. The step that used to require a specialist, noticing that the output of tool A is the input to tool B, is a reasoning task models are now decent at. Cathedral's claim, whatever its precise accuracy, describes this shape: a multistep chain across several business systems, completed fast.

We made the same argument about the defender side in our coverage of Project Glasswing: capability that finds vulnerabilities at scale helps whoever points it first. The Cathedral story is the offensive mirror. The question is no longer whether agents can do useful offensive work. It is how many attackers can afford to run them, and the answer is trending toward everyone.

The Models Are Closing the Gap, in the Open

A fair objection: one startup's demonstration is an anecdote. The more durable signal is what the underlying models can now do, and the vendors themselves publish it. Two data points, both vendor reported and both worth discounting for that reason.

Google's announcement of Gemini 4 Carbon reports 54.8% on ExploitGym, a benchmark of exploit development tasks. That is a vendor reported figure, measured by the vendor, on a benchmark the vendor chose to feature. Read it as a statement of direction, not a precise measure of what the model can do against your systems.

The second matters more for access. Mistral's release of Mistral Large 4 reports 51% on the AA Cyber Index, again a vendor reported number, and again the interesting part is the licence rather than the score. It is an open weights model. Open weights means anyone can run it on their own hardware, with no usage policy to enforce and no account to suspend. When the strongest models sit behind an API, the lab can watch for abuse and cut off a customer. When a model that reaches offensive capable territory is a download, that control is gone.

Put the two together. Cathedral's claim, if even roughly right, shows a capable agent chaining weaknesses across business software. The benchmark disclosures show the models underneath getting better at exploit work, and at least one of them being freely runnable. You do not need to believe the twelve hour number to plan for the direction.

Holding the Claims Loosely

Before the hardening list, a note on epistemics, because this story invites two lazy readings. One is "AI broke into an AI lab, panic." The other is "a startup marketing stunt, ignore." Neither survives contact with what we know.

Against the panic reading: Anthropic says customer conversations, source code and model weights were not accessed, and says it ended the access the same day. Taken at face value, the blast radius was business systems, not the crown jewels, and the response was fast. Against the stunt reading: Anthropic confirmed access to sales, HR, and IT systems. HR systems hold employee records. IT systems hold the keys to everything else. A limited set of those is not nothing, and a stunt does not get confirmed by the target.

The disagreement over how the test was run is real and unresolved. If Cathedral operated within an agreed scope, the result is a red team report. If it did not, it is an unauthorised intrusion described as research, and the legal and ethical picture is different. We have no basis to pick. What we can say is that the technique described, agents probing connected vendor software for a path inward, is something any attacker can do without anyone's permission, and that is what you are defending against.

The Hardening List

Four controls, ordered by how much risk they remove per hour of work. None requires a new product purchase.

1. Inventory and scope every vendor token

You cannot revoke what you cannot list. Pull the authorised applications from your identity provider, your email suite, your chat workspace, your source host and your cloud accounts. Add the API keys that live inside each SaaS tool's own settings, which no central dashboard shows you. Build one table: application, owner, scopes, creation date, last used, business purpose.

Then cut. Revoke anything with no recent use. Replace broad scopes with the narrowest set that keeps the feature working; read only where read only is enough. Remove access held by departed employees' personal grants. Assign a named owner to each remaining row, because an integration without an owner is one nobody notices being abused. This is the same governance gap we described in the non human identity crisis, applied to vendors rather than your own agents.

2. Replace standing credentials with short lived ones

A token that never expires is a permanent breach waiting for a trigger. Where a vendor supports it, move to credentials that expire in hours: OAuth refresh with rotation, workload identity federation for cloud access, signed requests in place of static keys. Where the vendor does not support rotation, rotate manually on a calendar and put the dates in the owner column of your table.

Add network and context restrictions wherever the product allows them. An API token usable only from the vendor's published address ranges is much less valuable to someone who lifts it from a settings page. Admin consoles should sit behind your identity provider with phishing resistant multifactor authentication, not behind a password the sales operations team shares in a spreadsheet. If a product cannot do single sign on without an enterprise surcharge, pay the surcharge. It is cheaper than the incident.

3. Alert on machine speed access

Humans have a rhythm. They log in, click around, pause, read things, go to lunch. An agent chaining across tools shows a different signature, and it is detectable if you look for it: many distinct endpoints touched in a short window, systematic enumeration of users or records in alphabetical or numeric order, a new application grant followed within minutes by bulk reads, the same credential appearing in several products inside the same hour, requests spaced at suspiciously even intervals.

Pull the audit logs from your highest value SaaS tools into one place. Most expose them, many only on a higher tier. Write three detections to start: bulk export or listing above a threshold, a new OAuth grant from an unusual location or client, and any administrative action from a session younger than a few minutes. Tune against a week of normal traffic. The goal is not to catch every intrusion. It is to shrink the window from the claimed twelve hours to something your on call engineer can respond inside, and to notice the access on the day, as Anthropic says it did, rather than months later.

4. Red team your own SaaS stack with your own agent

The only way to learn what an attacker agent would find is to run one. Do it deliberately, in writing, with scope. Choose a test identity that mirrors a low privilege contractor, or start from a leaked looking token, and give an agent the goal: reach HR data, reach customer contacts, reach any admin console. Record where it succeeds, how long it takes, and which of your detections fire. Run it against staging copies of the tools where you can, and against production only with explicit approval from the owners of the systems involved.

Constrain the agent as carefully as you would a contractor. Fixed scope, a kill switch, logging of every action, and no ability to take destructive steps. The machinery for this is the same machinery for running any agent safely, and our guide to the agent harness covers the sandbox and permission layers worth copying. The useful output is not a pass or fail. It is a ranked list of the specific paths that worked, which becomes next quarter's remediation backlog.

Expect it to find embarrassing things. A shared inbox with the password reset flow for three tools. A test account with admin rights from 2023. A chat bot token posted in a ticket. Every one of those is the ordinary material an attacker agent will also find, which is the argument for finding it first.

Vendor Risk Is Now a Speed Problem

Traditional vendor risk management runs on questionnaires and annual reviews. A vendor fills in a form, a security team files it, and the review repeats in twelve months. That cadence assumed attackers moved at human speed, so a gap between reviews was an acceptable risk. If an agent can walk from one tool to the next in hours, the review cycle is an order of magnitude too slow to matter.

Move the effort from paperwork to blast radius. For each vendor, ask what happens if their admin console is taken over tomorrow. What can it read in your systems? What can it write? Which other vendors does it connect to on your behalf? Rank vendors by that answer, not by contract value or the size of the logo. A small scheduling tool with write access to your calendar and read access to your email belongs above a large analytics platform that only sees anonymised events.

Contract terms can help at the margin. Ask for breach notification inside a fixed number of hours, audit log access included in your plan, and support for single sign on and token expiry without an upsell. Vendors that refuse are telling you how they will behave on the bad day.

There is also a quieter version of this risk in how your own developers work. Agents that install dependencies and connect to services on a developer's behalf extend the vendor chain without a review, a pattern we covered in the piece on slopsquatting. Every new integration an agent adds is another row for the table in step one.

What To Do This Week

You do not need a program. You need five working days and an afternoon of agreement from whoever owns your identity provider.

On Monday, export the list of authorised OAuth applications from your email suite and your identity provider. Sort by scope breadth and by last use. On Tuesday, revoke everything unused for ninety days and ask owners to justify the five broadest remaining grants. On Wednesday, list the static API keys inside your ten most important SaaS tools, record their age, and rotate the oldest. Put the next rotation date on a calendar owned by a named person.

On Thursday, turn on audit log export for your CRM, HR system and admin consoles, send them somewhere searchable, and write the three detections from step three. On Friday, write the agent red team plan: scope, test identity, targets, kill switch, approver. Schedule the run for the following week. Do not skip the written approval; an attacker agent pointed at production without it is the thing you are trying to avoid being on the receiving end of.

Then wait for the details. More about the Cathedral test will come out, perhaps including the protocol, the vendors involved, and Anthropic's own account. Update your model of the incident when it does. Do not wait for it before fixing tokens that nobody can explain. Those were a liability before the story broke and will be after it fades.