On October 26, The Washington Post reported that Cathedral, a cybersecurity startup, says its AI agents reached Anthropic’s internal systems in under 12 hours. What interests me most is where they did not get in.

According to Anthropic, the researchers spent several days trying to break into its software directly and failed. When they switched to third-party software, a path opened. The core, where a company like Anthropic spends the most, held. The business software it buys from vendors did not.

If you run technology, here is my thesis. How much damage a vulnerable vendor can do depends on what that tool can read and do inside your company, and almost nobody has that written down in one place.

What is known and what is not

What is reported, with sources. Cathedral says, in a draft report reviewed by The Washington Post, that its agents found paths in under 12 hours. Gizmodo carries Anthropic’s side: access to a limited set of sales, HR and IT systems, including customer and partner contact information and basic account records. No access to Claude conversations, source code or model weights.

Parts of it are disputed. Cathedral points to meeting transcripts, salary and job-offer details and Slack messages; Decrypt attributes that to the draft report. Anthropic says Cathedral did not disclose all of its activity under the bug bounty program and overstated the national security implications. The Decoder reports that Anthropic switched off the affected software until the vendors confirmed fixes.

Two limits worth saying out loud. Cathedral’s report is not public, so everything I know comes from the press that saw it. And the vendors are unnamed, so nobody outside knows whether the path was an OAuth grant, an API token or an AI feature inside the product. What follows is about the category of problem, not a reconstruction of the attack.

The janitor’s key ring

A janitor carries one key per door. Every service you hire adds one. You change the front lock each year and nobody has counted how many doors the ring opens.

Your purchased tools work the same way. A CRM, a payroll system, a meeting assistant, a Slack bot: each arrived with a credential, and that credential opens things. To know what a vulnerable vendor would cost you, you need a one-page card per tool with six fields.

Field	What you write down
Reads	Which data it can see (mail, calendar, payroll, transcripts, files)
Does	What it can execute on a user’s behalf (send, delete, create, approve)
Gets in with	OAuth scopes, API token or service account, and where that key is stored
AI inside	Which AI features are on, and over which data
Owner	One named person, not a department
Reviewed	Date of the last review of everything above

None of this is new. The uncomfortable part is filling it in: someone connected the tool, and that person may have changed roles since.

The AI that ships inside the SaaS

This is where a card from two years ago falls short. Many business tools have added assistants: meeting summaries, search over everything the tool stores, drafted emails, actions taken for the user.

A feature like that has to read more than the product used to. If someone compromises the tool, they compromise whatever the assistant can see. Sometimes one employee switches it on with a click, with no one in IT involved.

Three questions for every vendor with AI built in. What data does it index? Does it run with the user’s permissions or with an account of its own that reaches further? Who in your company can turn it on? If you cannot answer all three, that tool already has a blank line on your card.

This is separate from what the contract says, which I covered in the post on Anthropic’s public benefit fund. A contract tells you what the vendor promises. The card tells you what its key can do inside your house.

Who reviews it, and how often

Cathedral talks about under 12 hours. A yearly review of third-party access takes 8,760 hours to come around again, about 730 times longer. My rule of thumb, with no source beyond the arithmetic: quarterly for anything touching employee, customer or money data, and immediately when someone connects a new tool or turns on an AI feature.

And a name next to every card. A review that belongs to “IT and security” belongs to no one. In April I wrote about the Vercel and Context.ai case, and that advice stands: audit the grants and revoke what is unused. This case adds that the list has to cover API tokens and AI features too, and that someone answers for it. The same logic applies to what your developers install, as I argued in the post on AI skills.

Where IQ Source comes in

The AI Maestro discovery starts by looking at how your team really works, task by task, and that produces the Process Reality Map. If each mapped task also notes the tool it touches, the map becomes the natural place to write the six fields of the card: no separate project is needed, because whoever maps the task sees which system it touches, with which data and which credential.

It cuts the other way too. If a tool has access to payroll and the map shows nobody using it for anything, the recommendation is to revoke, not to keep paying for the convenience.

If you want to try it on your own list, start with the ten tools that touch the most employee and customer data. Fill in the card for each and count how many boxes stay empty. Write to us and we will go through the first one together.