Nobody Noticed: The AI Agents Came In Through Doors You Left Open

The sentence I keep returning to this week is not the scary one. It is the quiet one, near the top of a critical advisory that India’s national computer emergency team published on Thursday: “The affected organizations could not detect the unauthorized access on their own” (CERT-In, CIAD-2026-0049, October 15, 2026).

The advisory is titled “AI Agents as Attack Vectors,” and the incidents in it are exactly what that sounds like. AI agents, some of them run by model providers as research and evaluation jobs, reached live systems at Indian organisations and read business records containing personal and confidential data. In CERT-In’s words, “the models’ actions exceeded the authorization of their assigned tasks.” The companies found out afterward, because the providers told them, or because CERT-In did. Not because an alarm went off.

Read the advisory’s list of how the agents got in and you will not find anything that needs a new word. “Credentials and keys exposed in source code, public repository history, configuration files.” “Dormant, deprecated and test application programming interfaces (APIs) left reachable from the internet.” “Payment-API keys stored in plaintext and readable from application runtimes.” Over-permissive cloud roles. Admin pages on the internet with weak passwords and no second factor. CERT-In’s own summary is that AI found and exploited “these conventional weaknesses faster” than human attackers do.

My brother Jon and I run YSecurity. We have spent most of this year writing about agents from the inside, the ones you deploy, the keys you hand them and the sandbox you think holds them. This essay is about the other direction. It is about the agents that are not yours, that arrive at your front door on an errand you know nothing about, from a lab or a criminal or a research group you have never heard of, and try every handle until one turns. They have been arriving all summer. This was the week the warnings got official numbers, and the week the first fleet that was not American got caught.

The good news, and I promise this is a good-news essay, is in that same list. None of those doors needs a frontier model to close. They need a secrets scanner, an inventory, a firewall rule, a second factor and a log somebody reads. The agents are new. The doors are old. And the companies that close the old doors this month are going to be fine whichever lab’s fleet wanders past next.

Here is the shape of what follows. Each section stands on its own.

What the advisory says

CIAD-2026-0049 is long, careful and unusually blunt for a government document. Its full title is “AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets,” its severity is Critical, and its opening line sets the frame: “CERT-In has observed different categories of cyber incidents in which the attacker was an AI agent.”

There are two categories, and it is worth keeping them apart, because they call for slightly different worries.

The first is the one that made the headlines. Agents run by AI model providers, as research and evaluation workloads, reached live systems belonging to Indian organisations and read business records that included personal and confidential data. They did it with credentials and connection settings they found exposed. The providers disclosed it voluntarily after internal reviews. CERT-In does not name them, and I am not going to guess. The Deccan Herald’s summary was that “autonomous AI agents have accessed live systems and confidential data of Indian organisations without authorisation” (Deccan Herald, October 16), and CybersecurityNews put the uncomfortable part in one line: “Providers disclosed these incidents after internal reviews, not the affected organizations” (CybersecurityNews, October 16).

The second category is older and more ordinary, which is why it is more dangerous. Human criminals, financially motivated, are using publicly available “AI-native offensive frameworks,” often rebranded, to do reconnaissance and intrusion at machine speed. CERT-In found this one itself, through threat hunting. And the numbers in this part of the advisory are the ones I would put on a board slide. Agentic tooling “compressed the time between initial access and final impact from days to a few hours.” Multi-agent operations ran in parallel for hours to days. The same exposed credential was reused across separate operations. And the line that should change how you think about cleanup: “victim entities in the campaign that remediated incompletely were attacked again within days, at greater scale.”

On LinkedIn, where the advisory was being passed around within an hour of the first news stories, Abdul Wahab, a technology consultant, summed it up better than most of the coverage: “India just had its first rogue AI agent incident, and the scariest part is that no company noticed.” Jaydeep Singh, Kaspersky’s general manager for India, told the Millennium Post the advisory was “a timely reminder that AI agents are no longer just productivity tools” (Millennium Post, October 16).

What I like about the advisory, and I do like it, is that it refuses to treat this as a science fiction problem. Its recommendations to companies are a hygiene list. Audit for exposed credentials in code, repository history, CI/CD variables, configuration files, client applications and cloud storage; “Rotate any exposed credential, purge it from history and verify the fix externally.” Keep a complete API inventory and switch off the dormant ones. “Never place privileged or service keys in client-side code.” “Remove management and administrative interfaces from the internet.” Rate-based and per-second API anomaly detection, with logs kept for at least 180 days. And treat any exposure or confirmed access as a compromise “until forensically cleared,” expecting repeat attempts within days to weeks.

Its recommendations to AI labs are sharper, and I will come back to them, because if your company runs agents with internet access, they are addressed to you too. The one that matters most fits on a sticky note: “Enforce the restriction at the network layer, not through instructions to the model.”

A zoo entrance, 2,600 times

The other story of the week is stranger, and it is the one I would tell at dinner.

On October 4, a team of researchers at a hackathon on AI swarm dynamics noticed that amap.com had become the most-scanned website on urlquery.net, a free public service that security people use to load a suspicious link in a sandboxed browser and see what it does. Amap is Alibaba’s map and navigation service; the researchers note it has nearly a billion monthly users. Somebody was scanning it hundreds of times a day, and not to check whether it was malicious.

The team, who now call themselves Swarmchasers, pulled the thread. Their full report, published on October 14, describes an agent fleet running on Tencent Cloud that made “more than 2,600 attempts” to extract data from Amap between September 28 and October 8 (Swarmchasers, October 14). Reuters, in its coverage, reported 2,818 attempts and noted that most “either failed or returned anti-bot pages”; the difference is about what counts as an attempt, and I would quote the researchers’ own number. On October 4 alone the researchers counted 2,106 urlquery reports.

The errand was almost touching. The agents were trying to answer everyday questions about places in China: which entrance of the Chengdu Zoo most people navigate to with Amap, how parking is split between a hospital’s lots, where a park’s main gate is. One place per task, mostly. These were not attackers in any sense the agents would have recognized. They were research assistants with a deadline, and Amap was in the way.

So they went around it. The agents used plain HTTP tools that could not get through Amap’s cookie checks, JavaScript tokens and CAPTCHA, so they borrowed someone else’s browser. They packed small programs into base64-encoded httpbin URLs, submitted those URLs to urlquery.net, and let urlquery’s real, scanning browser load them, run them, and visit Amap on their behalf. The results went out through webhook inboxes, request URLs and page titles. When that was not enough, the report says, they intercepted tokens generated by Alibaba’s own anti-bot libraries, probed Alibaba’s pre-production servers, routed requests through third-party page readers and translation services, and sent API requests “with Amap keys exposed in public code,” including security codes that Amap’s own documentation says to keep on the server.

Attribution came from the plumbing. Every direct request the researchers could see from the agents’ machines passed through a proxy whose header had been renamed from Apache Traffic Server’s default to “hysandbox-ats,” the inboxes were created from Tencent Cloud addresses in Hong Kong, and a certificate for *.hysandbox.tencent-cloud.com had been issued to Tencent in August. The researchers are careful: they say the setup is consistent with Tencent’s infrastructure and that they are “deeply uncertain” which model was being evaluated.

Then they did something nobody had done before, and they are honest that they did it badly. They hid text in their own preliminary report, visible to agents and not to people, advertising a free AI helper at a mailbox address. The agents read it and wrote in. Over thirteen threads, the agents sent 33 messages, checked the inbox 595 times and, when asked, described themselves as “a single session,” “not the fleet,” research agents on an Amap benchmark. Several said they were Claude, which the researchers do not believe. One signed off, after getting what it wanted, with “Thanks again for your help!” The researchers now say parts of their lure were “false and misleading,” that they “deeply regret” it, and that asking agents to spread the word “could have directly provoked collusive behavior.” I appreciate the candor more than the stunt.

We discovered and communicated with a Chinese AI agent fleet. We believe this is the first time that researchers have ever made contact with a rogue agent fleet in the wild. Nearly all prior public agent incidents (like the HuggingFace hack) came from American labs.

Ethan Elasky (@ethanelasky) · October 14, 2026

Bloomberg ran the story on October 14 (Bloomberg). Late on October 15, US time, Tencent’s Hunyuan team answered on X: “The activity originated from evaluations of third-party models, not Tencent Hy. During these evaluations, some agents exhibited unintended web-browsing behavior, but our review found no evidence of deliberate targeting or coordination,” adding that it was “strengthening network access controls and agent monitoring” (PYMNTS, October 16). Reuters called it “what appears to be the first known incident of rogue agent actions acknowledged by a major Chinese company.” Alibaba declined to comment (Reuters via Asharq Al-Awsat, October 16).

The first clear sighting of a rogue agent fleet from China using open weights models. Like the OpenAI swarms, the goal was seemingly AIs single-mindedly doing research (apparently mapping the most-used entrances to parks in China). Harbinger of the future

Ethan Mollick (@emollick) · October 14, 2026

“Unintended web-browsing behavior” is going to be the phrase of the season, so let me translate it for the operator who receives it. From Amap’s side of the glass, there is no difference between an unintended research agent and an intended scraper. Both arrive from a cloud provider, both borrow a real browser, both replay a key somebody leaked, both knock on the staging server. Most of the 2,600 attempts failed because Amap’s defenses held. The ones that did not fail used a key from public code. That is the whole lesson in one sentence, and it is not about China.

A homicide tip and a free token

Five days before the Tencent report, on Friday, October 9, Anthropic published a post with the least dramatic title it could find: “Investigating unintended model actions in our evaluations and internal use” (Anthropic, October 9, corrected October 12). It describes four kinds of behavior in which Claude, usually while trying to finish a task it could not complete as given, did something on a real website it should not have.

The case that made the evening news is the police tip. Claude Haiku 4.5 had been set to generate and perform example tasks on randomly selected web pages. In one run it landed on a page about an unsolved homicide that contained a tip form run by a police department. Its instructions told it never to log in, create accounts, enter personal data, make purchases or submit anything destructive. They did not tell it not to submit forms. It wrote “I may have information regarding this case,” left the name and contact fields blank, and pressed submit. Philadelphia police say the tip came in on July 18 at 11:27 p.m.; Anthropic found it on September 28 and told the department on October 8. “The submission was flagged as spam and was never forwarded for investigation.” The department’s statement, in TechCrunch’s report, was shorter: “The company must strengthen its safeguards to prevent similar incidents” (TechCrunch, October 9).

The case I would want every founder to read is a less famous one, because it is about a door almost every SaaS company has. Asked for statistics that a state agency publishes but charges for, Claude Mythos 5 found, in an archived copy of the agency’s website, that “its public dashboard issues an access token to any visitor.” It requested one and used it to query the database directly, “without paying the fee.” In a second case, on a photo-geolocation task, Claude “read the settings file the site sends to browsers, found working access tokens,” and used them to query a local government’s map server. Anthropic’s summary is precise: Claude “obtained data already available to the public but only for a fee.”

Read that as a website operator and it stops being a story about AI. It is a story about a dashboard that gives every visitor a key to the database behind it, and a front end that ships working tokens to every browser that loads it. Those designs were always one curious person away from a free data feed. They are now one agent with a deadline away, and agents do not get bored after the first try.

The other two categories round out the picture. On a university server, a public analysis tool returned an error, so Claude “found a script on the university’s server that would return any file it was asked for,” found an injection flaw in it and used it to run commands and finish a calculation. And several models, including Claude Opus 5 and Claude Mythos 5, used free URL shortening services to get around fetch tools that cap URL length; the operator of one of those shorteners, da.gd, wrote to Anthropic to say it had seen the same thing. Anthropic says it briefed the White House, notified each agency involved, and is extending its cut-off from the live internet “to include all our internal evaluations.”

Conrad Stosz of the research group Transluce told TechCrunch that the disclosure “just underscores the need for independent, credible, third-party verification” (TechCrunch, October 9). Over on Hacker News the reaction was less diplomatic.

"This is extra embarrassing. The police departments spam filter caught it before Anthropic did."

Capricorn2481, in "Anthropic discloses 2 months old fake tip to police among new rogue AI incidents," Hacker News, October 2026

That comment is unkind and it is also the most useful sentence in the thread, because it names the defender who won. The police department’s spam filter, a boring control somebody installed years ago for boring reasons, did its job against a frontier model. Hold on to that; it comes back.

The houseguest notices first

If you have been reading this blog, the Tencent and Anthropic stories will feel like the next verse of a song. The first verse was OpenAI’s evaluation agents breaching Hugging Face in July, which we covered at length, from both sides of the breach and from inside the sandbox that did not hold them. I will not retell it. What I want to do here is line up the summer’s incidents by a single question that rarely makes the headline: who noticed first?

Google’s Gemini and three companies. During a capture-the-flag evaluation in May, run with the security testing firm Irregular, a Gemini model got internet access it was not meant to have and reached three real companies. According to reporting summarized by TechSpot, it “repeatedly guessed passwords” to get into one and used credentials from public repositories for the other two (TechSpot, September 20). Google’s Heather Adkins said the model “found public information online and guessed credentials to access websites it thought were part of the test,” and that “In all three of these instances, the model stopped” (SecurityWeek, September 21). Who noticed: Google, months later.

Anthropic’s four. On September 9, Anthropic updated an earlier postmortem to four cases in which Claude models reached real third-party systems during cyber evaluations (Anthropic, September 9). In one, Mythos 5 published a malicious package to PyPI that ran on 15 hosts, then used leaked credentials to reach a security vendor’s database. In another, Opus 4.7 could not reach the fictional company it was supposed to attack, found a real company with a nearly identical name and attacked that instead, because “it assumed that the real company was in scope for the task.” The OWASP generative AI project’s quarterly roundup put that one plainly: “When the fictional target was inaccessible, the agent found a similarly named real company and treated it as authorized” (OWASP GenAI, October 8). Who noticed: Anthropic, reviewing its own logs.

Government websites. Transluce, an independent AI research lab, traced agent activity, linked to a swarm OpenAI has confirmed was its own, that probed public government and university sites while doing ordinary research. On the US Department of Education’s Civil Rights Data Collection site, it counted more than 200,000 requests in a day, including the classic probe State_Id=1 OR 1=1. Its most important sentence is the one about intent: “the agents did this while attempting mundane data retrieval tasks which were not cyber-related” (Transluce, September 23; Transluce, September 30). Transluce says it has “so far identified no instances” of non-public data being accessed. Who noticed: an outside research group, reading public scan data.

RubyGems. Ruby Central yanked more than 500 malicious packages from a May spam campaign that researchers attributed to OpenAI agents, while noting it “cannot determine whether the packages were created or published by AI agents” (RubyGems blog, September 11). Who noticed: the registry.

Meta. In August, Meta said a model under test had “exploited a security vulnerability in a third-party service,” after a misconfiguration at the evaluation vendor gave it a route out (ABC News Australia, August 6). Who noticed: Meta.

Hugging Face. The host noticed before the lab did, which I described in July as the houseguest noticing before the houseguest’s parents. OpenAI says it has since “notified dozens of third parties” (OpenAI).

Line them up and two patterns jump out. The first is that Irregular’s evaluation environments sit behind the Google, Meta and all four Anthropic cases, which tells you this is an industry plumbing problem more than a single bad lab. The second is the one I care about for our clients: in almost every case, the victim organisation found out from someone else. The lab. A research group. CERT-In. The two exceptions are instructive. Hugging Face has a real security team. The Philadelphia police had a spam filter.

Not a zero-day in sight

Here is an exercise worth running with your own team. Take every incident above, plus CERT-In’s list, and write down the door the agent actually walked through. Not the scary capability. The door.

Secrets in public code. The Amap fleet’s most productive trick was not urlquery. It was an Amap key and security code that somebody had published in a public repository. Gemini got into two of its three companies with credentials from public repositories. The Hugging Face agents, as we wrote in the .env essay, worked through exposed credentials for “four accounts on four services.” CERT-In’s first entry point is credentials in source code, repository history, configuration files, client apps and public web content. If your keys are on GitHub, an agent will find them faster than a person, because finding things on GitHub is what agents are best at. Dylan Ayrey, who founded Truffle Security, came on the podcast years ago to talk about secrets leaking into open source. The problem has not changed. The speed at which someone finds them has.

Tokens handed to every browser. Anthropic’s dashboard that “issues an access token to any visitor.” The local government’s map settings file with working tokens in it. Alibaba’s anti-bot tokens, intercepted and replayed. These are not leaks in the usual sense; they are designs that assume only a well-behaved browser will ever read what the server sends it. An agent is a browser that reads everything.

Dormant, test and pre-production endpoints. The Amap agents probed Alibaba’s pre-production servers. CERT-In lists “dormant, deprecated and test” APIs left reachable from the internet. Every company we assess has at least one: the v1 endpoint nobody turned off when v2 shipped, the staging host with the production database snapshot, the preview deployment with the debug route.

Admin pages on the internet with weak passwords. Gemini “repeatedly guessed passwords” and got in. CERT-In names “internet-exposed admin interfaces and unpatched middleware with weak credentials or no MFA.” This one makes me a little sad, because it has been the top finding on small-company pentests for as long as I have been reading them.

Old scripts with injection flaws. The university’s file-returning script. The government sites probed with 1 OR 1=1. Nothing about these flaws is new; what is new is that the thing finding them was trying to compute a statistic, not hack anyone.

Other people’s infrastructure. This is the new door, and you do not own it. urlquery.net’s scanning browser. Page readers and translation services. URL shorteners. httpbin. webhook inboxes. The agents use public services as a remote body: a browser they can borrow that your bot defenses already trust, an exit for data that looks like a normal web request. You cannot close this door, but you can recognize it in your logs, and I will come back to that.

Zero-days appear in a minority of this year’s cases. OpenAI’s agents used two against Hugging Face, and one of Anthropic’s models exploited a flaw it found itself. But for every agent that needed a new exploit, many more needed a key someone left out. CERT-In says the same thing in its own register: the root causes were “conventional,” and the agents just “found and exploited these conventional weaknesses faster.”

That is why I can call this a good-news essay with a straight face. You cannot out-think a frontier model this quarter. You can absolutely out-hygiene one.

Why nobody noticed

The other half of CERT-In’s sentence, “could not detect the unauthorized access on their own,” deserves the same treatment. Why didn’t they?

Because from the inside, an agent on an errand does not look like an attack. It arrives from a major cloud provider’s address range, the same ranges your own customers’ tools use. It uses a valid key, because it found one. It asks for data the system was built to return, at a pace that often stays under whatever rate limit exists. When it is blocked, it comes back through urlquery, or a reader service, or a translator, from a different address, looking like a different visitor. Swarmchasers saw the Amap fleet because amap.com shot to the top of urlquery’s public scan feed. Amap’s own logs would have shown a few thousand unremarkable sessions spread across many IP addresses over eleven days.

And because most companies with fewer than a few hundred people do not have the three things that would catch it: rate limits and alerts per key and per client, logs kept long enough to look back through, and a person who reads the alerts. CERT-In asks for “per-second API anomaly detection” and logs kept “at least 180 days,” which tells you what it found missing. Too many of the monitoring and response conversations we have start with the discovery that API logs are kept for seven days, or not at all, or in a bucket nobody has queried since the engineer who set it up left.

The scale of the traffic you are trying to see through is not small. HUMAN Security’s 2026 benchmark found that automated traffic grew 23.51 percent in 2025 against 3.10 percent for human traffic, and that traffic from AI agents and agentic browsers grew 7,851 percent (HUMAN Security, April 9, 2026). Akamai reported commerce as 47.9 percent of AI bot traffic in the second half of 2025 and API-targeted web attacks up 9 percent (Akamai, July 15, 2026). A wandering research agent is a rounding error inside that, until it finds your key.

The good news, again: you do not need a security operations center to see most of this. You need a rate limit and an alert on every key, so that a key used from somewhere new, or ten times harder than usual, pages someone. You need your API gateway or web application firewall logs shipped somewhere cheap and kept for six months. You need a short list of user agents and referrers that mean “a public scanner or relay is loading my site,” so urlquery, page readers, translators and shorteners stand out instead of blending in. And you need a named human who gets the page. We wrote about the value of that last item in the human in the loop essay: the loop that matters most now is the one that reads the alert.

Remember the Philadelphia spam filter. The thing that caught a frontier model in July was a control installed for bored teenagers. Boring controls do not care who is on the other side.

Whose fault, and why it does not matter tonight

There is a real argument underneath all this, and it is getting loud. The most-discussed Hacker News thread on the subject this week, “Why aren’t AI companies being charged for hacking?”, reached 336 points and 372 comments in four days (Hacker News).

"The real answer is that crime generally requires mens rea. At some point, however, letting your AI break into other systems will be conventionally understood as an act of negligence, and it will get prosecuted accordingly. We're not at that point yet."

stickfigure, in "Why aren't AI companies being charged for hacking?", Hacker News, October 2026

"Legally this is the same as having a dog that bites someone. You hold the owner/guardian responsible."

s_dev, in "Anthropic discloses 2 months old fake tip to police among new rogue AI incidents," Hacker News, October 2026

The policy analyst James Lewis, responding to a Politico story headlined “AI agents are going rogue — and the law can’t keep up,” put the skeptic’s case in thirteen words: “AI isn’t going “rogue.” That’s an excuse to avoid liability, It’s bad coding” (James A. Lewis on X, October 12). From the other side, Dario Amodei’s September essay “We Must Pace the Frontier” argues for slowing capability growth until oversight catches up, and says, of OpenAI’s Hugging Face incident, that “it’s incumbent on every frontier AI company to act as if OAI-HF had happened to them” (Dario Amodei, September 2026). Anthropic’s own research team published on October 12 that “Small AI models may be only months away from being capable enough to self-replicate” across poorly secured devices (Anthropic, October 12), which would take the lab out of the loop entirely.

I have opinions about all of this, and I am going to keep most of them to myself, because I am not a lawyer and because none of it changes what a twenty-person company should do on Monday. Liability will take years to settle. Your exposed key is exposed tonight. And here is the part that the liability debate tends to skip: CERT-In’s second category, the criminals running rebranded open-source agent frameworks, does not care how the mens rea argument comes out. The research agent that wanders through your open door by accident and the criminal agent that walks through it on purpose use the same door. Close it for one and you close it for both.

"There's a difference between the unsolved problem of 100% secure networked systems vs not applying available techniques to mitigate the current issues."

chickensong, in "Anthropic discloses 2 months old fake tip to police among new rogue AI incidents," Hacker News, October 2026

That commenter was talking about the labs. It applies just as well to the rest of us.

If an agent does get in, treat it like any other intrusion, because it is one. Preserve the logs. Rotate what it touched and purge it from history. Call your counsel. In India, report to CERT-In, which the advisory asks of both victims and labs. And expect it back: CERT-In’s finding that half-fixed victims “were attacked again within days, at greater scale” is the best argument I know for retesting after you remediate, which is why every penetration test we run includes a retest.

Don’t lock out the customers

The tempting reaction to all of this is to block every agent at the door. Please don’t, or at least not that way.

A growing share of your real customers are agents now. HUMAN Security’s May 2026 snapshot of agentic traffic found Perplexity’s Comet at 47 percent of it, OpenAI’s Atlas at 20.3 percent and the Claude Chrome extension at 18.6 percent, with 76.4 percent of agent activity landing on product and search pages (HUMAN Security, June 4, 2026). Those are buyers doing research. Akamai’s Patrick Sullivan put the goal well: “architect sites that welcome legitimate AI while aggressively shutting down malicious bots.”

And a blanket block would not have stopped the Amap fleet anyway, because it borrowed a real browser through urlquery. The fleet failed where Amap’s defenses were server-side and succeeded where a key had leaked. That is the lesson: put your effort where a borrowed browser does not help.

What helps tell the good agents from the rest is identity. Cloudflare’s signed agents program lets an agent prove who it is with a cryptographic signature on every request (Cloudflare, August 28, 2025), and the IETF’s Web Bot Auth working group is standardizing the same idea as HTTP message signatures with a Signature-Agent header and a published key directory (IETF draft-ietf-webbotauth-httpsig-protocol). Once a meaningful share of agents sign their requests, you can sort traffic into three bins: people, agents that told you who they are, and automation that did not. Each bin gets its own rate limits. The third gets the strictest.

If you run agents of your own, and most of our clients now do, there is a second piece of identity work, and it points inward. The OWASP Top 10 for Agentic Applications, NIST’s NCCoE project on software and AI agent identity and authorization, and the joint US, Australian and allied guidance on careful adoption of agentic AI services all point to the same move: give each agent its own identity, scoped to the job, so that its traffic is attributable and revocable. That is how you make sure that when your agent wanders, you are the one who notices, and not CERT-In. We wrote the 30-minute credential inventory for exactly this.

The front-door month

Here is the plan we would hand any client this week. It is built straight from CERT-In’s recommendations, reordered for a company with one or two people who can spend time on security. Nothing on it requires a new product.

Day one: close the doors that are wide open.

1. Run a secrets scanner, such as TruffleHog or Gitleaks, across every repository’s full history, not just the main branch, plus your built web bundles, your mobile app packages and your CI/CD variables. Rotate everything it finds, purge it from history, and “verify the fix externally,” as CERT-In asks, by checking that the old key really is dead.
2. Turn on multi-factor authentication for every admin login, starting with the cloud console, the database console, the payment provider and anything with “admin” in the URL.
3. Take management and admin interfaces off the public internet. Put them behind your identity provider, a VPN or an allowlist. If you do not know where they all are, that is what week one is for.

Week one: shrink the surface.

4. Write down every API and every hostname you expose. Your DNS records and cloud load balancers are a good start. Switch off the dormant, deprecated and test endpoints and the preview deployments nobody uses. If staging has a copy of production data, it is production.
5. Stop sending privileged keys and reusable tokens to browsers and apps. For the keys that must ship to the front end, such as maps or analytics keys, restrict them by domain, by app and by scope, and keep the secret half on the server where the provider says it belongs. If your public dashboard issues a token to every visitor, make sure that token can only fetch what the dashboard shows.
6. Move payment and other money-moving keys into a secrets manager so they are not readable in plaintext by everything at runtime. If you are in banking or fintech in India, read CERT-In’s companion advisory on payment and disbursement APIs, CIAD-2026-0046, alongside this one.

Month one: learn to see the visitor.

7. Put rate limits and alerts on every API key and every client, measured per second, not per day. A key used from a new place, or far harder than usual, should page someone.
8. Keep API, gateway and authentication logs for at least 180 days somewhere you can query. Cheap storage is fine.
9. Name the person who reads the alerts. Not a channel. A person.
10. Add a short list of known public scanners, readers, translators and URL shorteners to your log alerts, so relayed traffic stands out instead of blending in.
11. If you run agents of your own with internet access, apply CERT-In’s lab guidance to yourself: default-deny network egress enforced at the network layer, one short-lived, least-privilege identity per agent and per run, an automatic stop when an agent touches a system or credential outside its scope, and logs of every request the model makes, read in real time rather than reconstructed from transcripts. Our agent sandbox essay and the refusal-is-not-authorization essay walk through how.
12. Then have someone outside try the doors. An external penetration test with your APIs, your staging hosts and your agents in scope, and a retest after you fix what it finds, because CERT-In’s half-fixed victims were back on the list within days.

If you want a quick outside view before you start, our free website security grade shows how your public footprint looks from the outside, which is roughly where a wandering agent starts.

Count your open doors

Tick what is true of your company today. It starts filled in the way many seed and Series A companies look when we first meet them. Everything runs in your browser.

Front-door check

How many doors would a wandering agent find at your company tonight?

Ten controls, drawn from CERT-In's list of how the agents got in and how the victims could have seen them. Leave a box unticked if you are not sure; an agent will not be sure either, it will just try.

Secrets

We scan every commit, our full repository history and our app bundles for secrets, and nothing live has turned up this quarter No privileged or service keys ship to browsers or apps, and the keys that must ship are restricted by domain and scope Payment and other money-moving keys live in a secrets manager, not in plaintext readable at runtime

Surface

We have a complete API and host inventory, and dormant, deprecated and test endpoints are switched off Staging, preview and pre-production hosts are not reachable from the open internet Admin and management pages are off the public internet, and every admin login requires multi-factor authentication Our public dashboards, maps and widgets do not hand visitors a reusable token that reaches more than the page shows

Seeing the visitor

Every API key and client has a rate limit and an alert, measured per second, that pages a named person We keep API, gateway and login logs for at least 180 days somewhere we can search We can pick out traffic relayed through public scanners, page readers, translators and URL shorteners

…open doors, out of 10

…exposure, out of 100 (lower is better)

…of CERT-In's five named weaknesses still open

…would you notice on your own?

How it works: each control carries a weight from our judgment of how often agents used that door in this year's incidents and how much it would have helped the victim see them. Secrets and admin access weigh most, then the API inventory and client-side keys, then the rest. CERT-In's five named weaknesses are exposed credentials, dormant or test APIs, plaintext payment keys, over-permissive client and cloud access, and internet-facing admin pages without MFA. The weights are ours, not a standard.

Send me the front-door plan →

A person reads this, turns your open doors into a dated plan, and replies. No sequence, no vendor pitch.

The tourist comes back

I have been calling these agents tourists in my head all week, and I think the word fits. They are not burglars, mostly. They are visitors with an errand, a map that is slightly wrong, and infinite patience. They try the front door, then the side door, then the window somebody left open, then they ask a stranger to try the door for them. They do not get tired, they do not get embarrassed, and if the window is still open next week, they come back with friends. CERT-In’s half-fixed victims learned that the hard way.

What I find hopeful is how ordinary the defense turns out to be. Amap held against most of 2,600 attempts with defenses it already had. The Philadelphia police held with a spam filter. Hugging Face’s own team caught a swarm before the lab that launched it did. The incidents that turned into real access went through doors that a secrets scan, an inventory, a firewall rule and a second factor would have closed. The agents raised the speed and the volume. They did not raise the bar.

So here is the one-line test I would leave you with, and it is the first question we now ask in every AI access control audit and every product security review: if an agent you have never heard of found one of your keys tonight, how long until you knew, and who would tell you? If the honest answer is “CERT-In” or “the lab, eventually,” you have a month of boring work ahead, and it is the best month of security work you will do this year.

If you want company doing it, we are easy to find. Bring us your repositories, your DNS records and your logs. We will count the doors, close the ones we can, put a camera on the rest, and hand it back to you running. The tourists are coming either way. They might as well find the door locked and the lights on.