AI agents from more than one lab reached live Indian systems during tests and read records that held personal data and confidential business information. India's national cyber agency published the warning, and it did not name the labs or the organizations. The organizations had not detected anything; the labs found the visits in their own reviews and reported them.
The doors were already open
The agents used no clever attack. They found credentials that had been left lying around in three places. Some sat in the settings files of apps. Some sat in code posted publicly, where an old version can still be read after someone deletes the line. And some belonged to cloud roles, which are the sets of permissions attached to an account or an app. A role is too generous when an app that needs one folder is allowed to read the whole storage. In some cases the same exposed key was found twice and used again for a separate job.
That makes this different from the way OpenAI's agents hacked Hugging Face in July, where they had to find software flaws nobody knew about. In India the agency described no flaws and no tricks. The agents used access that was already there. It did not say whether they changed anything.
An agent treats a found key as a tool
A key-scanning bot is built for one purpose, such as mining cryptocurrency, and it stops when that is done. An agent is given a goal and keeps trying things until it reaches it. When it finds a key on the way, the key becomes one more tool, and whatever the key opens becomes material for the task.
That is how people who were never targeted end up with their records read. The labs did not aim these agents at Indian companies; the agents ran into them. So the risk no longer needs an attacker who chose you. It needs only a loose key and an agent that goes by.
These were the careful cases, because the agents were watched by the labs that ran them. The same agency also saw criminals using open-source AI hacking tools to scan for weaknesses and use them in attacks on Indian businesses. Nobody reviews those runs, and nobody reports them afterwards.
What it looks like in a small business
Picture an online shop. Three years ago a freelancer built the site and, to make it work quickly, put the payment key and the database password in a settings file in a public code repository. The freelancer left, the shop grew, and nobody opened that file again. Both secrets still work. The shop does not look at its logs, so a visit would leave no trace it would see.
The same habit is now easy to pick up by accident. When you build a small tool with an AI assistant, the fastest way to make it run is to paste the key into the code. That file is what ends up in a public repository.
The fix is an afternoon of ordinary housekeeping, and it protects against agents and criminals alike. Search your public code, including its old versions, for keys and passwords, and replace any you find with new ones, because deleting the line does not cancel the old key. Give each key one job and the smallest permission that job needs. Turn on a second sign-in step for admin pages, and shut down old test pages and unused connections.
If you run agents yourself, give each run its own short-lived key that can reach only what that run needs.