The Five Doors Checklist – Mathew's Library

01 Why these five doors

On October 15, 2026, India's national cyber agency, CERT-In, said AI agents had reached the live systems of Indian organizations and read their business records. None of those organizations noticed. The AI companies that ran the tests reported it.

How they got in is the part that matters. They didn't break anything. They used credentials and connection settings that had been left lying around. CERT-In calls the root weaknesses conventional: keys left in code, test systems left open, permissions that were far too wide. What changed is speed: the agents found those gaps faster and at a larger scale than human attackers did, according to the advisory.

What changed on your side is who builds. A marketer with an AI builder can ship a working tool before lunch, and nobody asks a developer, because nobody thinks of it as software. CERT-In doesn't say those systems were built with AI. Its list is simply the plainest map of the doors.

02 Doors 1 and 2: keys and public links

Door 1. Keys in the code

A key is a password that lets one program talk to another: your ad account, your email platform, your customer database, an AI model. The quickest way to make an AI builder connect is to paste the key into the code, a settings file or the chat. A key that leaks once keeps working until somebody cancels it.

List every key you've pasted into an AI tool, a prompt, a spreadsheet or a Slack channel. For each one that has been anywhere shared: make a new key in the service it opens, then cancel the old one. Put the new key only on the tool's secrets or settings page. That's called rotating a key, and CERT-In asks for it by name.

Door 2. A link anyone can open

On May 7, 2026, WIRED reported research by RedAccess: more than 5,000 apps built with tools like Lovable, Replit, Base44 and Netlify had essentially no login, and close to 2,000 appeared to show private data to anyone with the address. The researchers found them with ordinary Google and Bing searches.

Open your tool's link in a private window, signed out. If it opens, it's public. Search your company name together with the platform's domain, the way those researchers searched. Check shared ChatGPT links too. Deleting a chat doesn't delete its share link.

03 Door 3: what each connection can do

Every tool you connect gets a set of permissions: read your ad account, or run it; see your contacts, or delete them. The easiest way to make a demo work is to give it everything, and CERT-In names over-permissive cloud and backend roles as one of the routes in.

Read the settings. For every connection, open its settings and read what it's allowed to do. View-only where a tool only reports. Never your own admin login. Ask one question. If a developer built or hosts a database behind your tool: are the access rules turned on? CERT-In calls them row-level security. When Wiz looked at Moltbook, the key in the site's code was meant to be public; the missing database rules are what opened everything.

04 Doors 4 and 5: test data and owners

Door 4. A test app holding a real customer export is the least protected thing you own, with the most real data in it. CERT-In gave the AI companies the same advice: synthetic data, fake credentials, production data kept out of tests. So test with ten invented rows. If a test app has ever held a real export, treat it as a real system: a login, an owner, and a date when it gets deleted.

Door 5. A tool nobody owns is a tool nobody rotates keys on, nobody reviews and nobody turns off. CERT-In asks for a complete inventory of connections, with the dormant ones switched off. The check is a spreadsheet:

One row per tool

If the person who built it leaves, the row gets a new name.

05 If you find an open door

Here's the order. Cancel the key. Make the link private. Then tell whoever owns the data, and your IT or legal contact, before you quietly fix anything else. Whether you have to notify anyone depends on the data and on where your customers live.

Finish the job. CERT-In says victims who only partly fixed the weaknesses were attacked again within days, on a larger scale.

Rotate every key that was ever shared. New key on the secrets page, old key cancelled.

Open each tool signed out. If it opens, make it private.

Read what each connection can do. View-only where it only reports.

Take real data out of test apps. Ten invented rows instead.

Give every tool a row and an owner. With the date it gets switched off.

Sources

CERT-In Advisory CIAD-2026-0049: AI Agents as Attack Vectors TechCrunch: Pluto Security and vibe-coded tools PPC Land on the WIRED / RedAccess research Wiz: the exposed Moltbook database Search Engine Journal: OpenAI pulls shared chats from Google

Mathew's LibraryLibrary card

Free access

Keep reading free with your library card

One email opens this checklist and all 3 resources in Mathew's library. No account, no password.