For two decades, enterprises have taught people not to share passwords, click unknown links or leave doors unlocked. Now we are preparing to hand the same keys to software that acts on its own and never sleeps. The question for technology leaders is not whether AI agents are ready for the enterprise. It is whether the enterprise is ready for them.
Ongoing incidents are giving Indian organisations a preview. CERT-In reported AI agents under testing reaching live systems and reading business records through exposed credentials and over-permissive cloud roles. My argument is simple: agents are not a new kind of threat. They are a faster way of finding the old ones.
Different incidents, one lesson
Look at the incidents now in the news. SBI found customer records with personal data on the dark web, and the alert came from outside the bank. eMudhra’s certificate authority keys were compromised, reportedly generated with too little randomness. PHP shipped emergency fixes for two critical remote code execution flaws. And CERT-In’s agents walked in through credentials left in configuration files and public code repositories, and over-permissive cloud roles.
The causes differ. The lesson does not: credentials, configuration, patching and visibility decide who gets hurt.
Speed changes the maths
What agents change is time. CERT-In found attackers using AI-agent frameworks to cut the gap between first access and final impact from days to a few hours, and victims who fixed only part of the problem were hit again within days. Google Threat Intelligence Group reported an agent-driven campaign that harvested thousands of third-party credentials in under six hours. An agent holding a valid key looks like a legitimate user, so no alert fires. In CERT-In’s cases, none of the organisations noticed.
Five guardrails before agents go live
CERT-In’s May blueprint on defending against AI-assisted exploitation is a sound baseline. Five habits I would insist on:
- Name an owner. Every agent needs a business owner, a technical owner and its own short-lived, least-privilege credentials.
- Fix the basics first. Hunt for exposed secrets, patch exposed software, and retire old and test APIs.
- Separate testing from production. Block outbound traffic by default, at the network level and not through instructions to the model.
- Log and watch. Keep a tamper-resistant record of agent actions, retain logs for 180 days, and monitor around the clock.
- Build a stop switch. Halt a run automatically if an agent uses someone else’s credentials, and let a named person decide when it restarts.
The six-hour clock
CERT-In’s directions require specified incidents to be reported within six hours of noticing them. The DPDP Act adds a duty to protect personal data and to report breaches to the Data Protection Board and each affected person, with those duties applying from around May 2027. Both clocks start when you notice. That makes visibility a compliance matter as much as a security one: an organisation that cannot see what an agent reads cannot report it, let alone explain it.
Look beyond your own walls
Large enterprises run on smaller suppliers that hold credentials or handle their data. Automated tools do not choose targets by size, and under the DPDP Act the organisation that decides how personal data is used stays responsible for what its processors do with it. Ask suppliers what they connect to, who holds the keys and how fast they will tell you.
Agents will reach every enterprise, many of them inside software we already use. Whether they arrive safely will depend on unglamorous work: knowing which credentials exist, limiting what they can do and watching what happens next. The organisations that do it will adopt AI with confidence, and become the partners others trust.
Authored by Dr. Gaurav Nigam, Chief Operating Officer, Wepsol