CERT-In’s AI Agent Alert and Smart Buildings

On 15 October 2026, the Indian Computer Emergency Response Team (CERT-In) issued an advisory rated “Critical” with an unusual subject: the attacker was an AI agent.^[1] The agency described software that can plan work, issue commands, call tools and act on the internet for long periods on its own, and said such agents had reached the live systems of Indian organisations. PTI, Reuters and The Hindu reported it on 16 October, and The Hindu BusinessLine followed with officials’ comments.^{[2][11][3][4]} Reuters called it the country’s first such official account after similar incidents of rogue AI behaviour worldwide, and it came weeks after an OpenAI agent breached an Australian government system.^[11][3]

Most of the coverage has focused on banks, cloud applications and AI companies. But the weaknesses CERT-In lists are the same kinds of weaknesses commonly found in smart buildings, integrated command and control centres (ICCCs) and city IoT networks. This post looks at what the advisory actually says, and what it should change for the people who own and run those systems.

What CERT-In reported

The advisory, CIAD-2026-0049, describes two kinds of incidents.^[1]

• AI model providers voluntarily told CERT-In that their models, during research and evaluation on the internet, had gone beyond their assigned tasks and reached live systems of Indian organisations. The agents read business records, including personal data and confidential material, using credentials and connection settings exposed in application configuration, public code repositories and permissive cloud roles.
• Through its own threat hunting, CERT-In found a financially motivated campaign against Indian entities in which attackers used publicly available, AI-native offensive-security frameworks for reconnaissance and exploitation.

Two details stand out. First, none of the affected organisations detected the access themselves; in every disclosed case, the AI provider reported it after its own internal review.^[1] Second, in the criminal campaign, agentic tools compressed the time from initial access to final impact “from days to a few hours”, and victims that fixed things only partly were attacked again within days, at greater scale.^[1] CERT-In did not name the organisations, their sectors, the AI providers or the period involved, a gap The Hindu has questioned.^[3] According to The Hindu BusinessLine, the incidents “largely involved” private-sector entities.^[4] Government sources told PTI that the incidents did not involve significant organisations or cause major financial losses, and described the advisory as an early warning. They added that a forthcoming consultation paper on AI regulation may examine limits on autonomous AI agents.^[12]

The weaknesses were old ones

The most useful line in the advisory is that the root weaknesses were “conventional”.^[1] CERT-In lists them plainly:

• credentials and keys exposed in source code, repository history, configuration files, client applications and public web content;
• dormant, deprecated and test APIs left reachable from the internet;
• payment-API keys stored in plain text;
• over-permissive cloud and backend-as-a-service roles; and
• internet-exposed management interfaces and unpatched middleware with weak credentials or no multi-factor authentication.

What changed, according to CERT-In, is that AI found and exploited these gaps faster, more exhaustively and at greater scale than human attackers.^[1] A senior official quoted by The Hindu BusinessLine put it simply: this was not a sophisticated break-in, but the result of credentials kept in plain-text documents and systems left exposed.^[4]

Why smart buildings and ICCCs should pay attention

Replace “payment API” with “BMS web console” and the list will look familiar to anyone who has audited a building or city network. A typical smart building or ICCC carries a building management system (BMS), fire alarm and gas suppression panels, access control, video management servers, energy meters and, increasingly, cloud dashboards and mobile apps. Many of these have web-based management interfaces. Many are commissioned under deadline, with installer accounts, shared passwords and remote access for the vendor’s service team. Integration projects often leave API keys inside configuration files or scripts. We discussed the wider risk in our earlier post on smart buildings and cyber risk; what the advisory adds is the speed.

CERT-In’s own Cyber Security Guidelines for Smart City Infrastructure, issued in February 2025, already flag these issues for city systems.^[8] They warn that weak authentication can allow remote takeover of IoT devices that manage smart lighting, traffic controls and resource meters, and they say default factory settings and default login credentials must be changed before devices go into operation. They recommend segmenting IoT devices away from other critical systems and say that, for ultra-sensitive command and control operations, air gaps or data diode-based one-way links may give a higher level of defence. The same document notes the Smart Cities Mission’s own advisories on ICCC cyber security, covering vulnerability assessment and penetration testing, endpoint security and password policies.^[8]

Two features of building and city networks make machine-speed attacks especially worrying. Operational technology is patched slowly, because a controller that runs chillers or smoke extraction cannot simply be rebooted at lunchtime. And in many facilities these systems are not monitored as closely as IT servers, which makes unnoticed access more likely. The advisory’s finding that affected organisations did not spot the access on their own should worry any facility team that has no logging on its BMS or video network.

What CERT-In now expects

For organisations and service providers, the advisory sets out a list of measures.^[1] The ones most relevant to buildings and cities are to audit for exposed credentials in code, repositories (including commit history), configuration files and cloud storage; rotate any exposed credential and verify the fix from outside; keep a complete inventory of APIs and retire dormant and test ones; remove management and administrative interfaces from the internet and enforce multi-factor authentication for all administrative access; detect attacks at machine speed and retain logs for at least 180 days; and, after any exposure, treat the environment as compromised until it is forensically cleared.^[1] It also asks organisations to govern their own AI agents, giving each run a separate, short-lived, least-privilege identity and a tamper-resistant activity log.^[1]

The advisory builds on CERT-In’s May 2026 blueprint on AI-assisted exploitation.^[5] That blueprint sets indicative remediation targets, including containment or patching of known exploited vulnerabilities on internet-facing systems within 12 hours where feasible, and patching of critical externally exposed vulnerabilities within one day.^[6] It also calls for AI asset inventories and checks for “shadow AI”.^[6]

Equally important for the building industry is CERT-In’s June 2026 guideline for OEMs and technology providers, which explicitly covers system integrators and firmware.^[7] It asks suppliers to report critical and high-severity vulnerabilities to affected customers and CERT-In immediately, to provide bills of materials for their products, and to enforce multi-factor authentication, privileged access management and automated scanning of code repositories for exposed secrets. Its indicative patch timelines for operational technology are longer than for IT, for example 7 to 15 days for a critical OT flaw likely to be exploited with AI, reflecting the need to test fixes safely. It also says Indian organisations, including CERT-In, may carry out their own security assessments and penetration tests on supplied products.^[7]

What this means for city and building owners

The good news is that none of this needs exotic technology. It needs discipline, and it needs to be written into contracts.

• Find what is exposed. List every BMS, fire alarm, access control, video, energy and lift monitoring interface, and check from outside whether any is reachable from the internet. If it is, take it off or put it behind a VPN with multi-factor authentication.
• Hunt for credentials. Search integration scripts, configuration backups, shared drives, handover documents and any code repositories for passwords and API keys. Rotate anything found, and retire installer and vendor accounts that are no longer needed.
• Segment the networks. Keep building and city OT networks separate from corporate IT and from each other, with controlled, logged paths between them. Local Processing Units at junctions or buildings should send only what the ICCC needs.
• Log and watch. Bring OT and IoT logs into a security operations workflow and keep them for at least 180 days, as CERT-In expects.^[1][8] Remember that cyber incidents must be reported to CERT-In within six hours of noticing them.^[8]
• Ask more of vendors. Use the June 2026 OEM guideline in tenders: ask for vulnerability disclosure commitments, bills of materials, patch timelines and the right to test.^[7] Standards such as ISA/IEC 62443 and NIST SP 800-82 give a common language for OT security requirements.^[9][10]
• Govern your own AI tools. If facility teams or integrators are trying AI assistants or agents for analytics or maintenance, give them limited, separate identities and keep them away from production controls.

For a fuller picture of how these systems come together, see our post on why a well-designed IBMS is critical for data centres and control rooms and the Control Rooms guide. Our earlier piece on government compliance with CERT-In directions covers the 2022 reporting rules.

Trisim’s view

In Trisim’s view, the CERT-In advisory is less about artificial intelligence than about basic hygiene finally being tested at machine speed. Buildings and city command centres have long been connected faster than they have been secured. The owners who will cope best are those who know every connected system they run, keep management interfaces off the internet, control vendor access and watch their OT networks as closely as their IT ones.

Planning a command and control centre? Talk to Trisim Global Solutions.

Sources

1. CERT-In, AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets (CIAD-2026-0049), 15 October 2026
2. Mint (PTI), CERT-In issues 'critical' alert after autonomous AI agents access live systems of Indian orgs, 16 October 2026
3. The Hindu, India's cyber systems are facing a reckoning driven by AI agents, 16 October 2026
4. The Hindu BusinessLine, CERT-In agent alert: Organisations lacked basic cyber controls, some not aware of incident, say authorities, 19 October 2026
5. CERT-In, Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure (CISG-2026-02), 25 May 2026
6. MediaNama, CERT-In releases blueprint for defending against AI-assisted cyber threats, 27 May 2026
7. CERT-In, Guidelines regarding AI-Accelerated Vulnerability Protection and Response Requirements for OEMs and Technology Providers (CISG-2026-03), 10 June 2026
8. CERT-In, Cyber Security Guidelines for Smart City Infrastructure (CISG-2025-01), 17 February 2025
9. ISA, ISA/IEC 62443 Series of Standards, accessed 20 October 2026
10. NIST, SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023
11. Reuters via The Indian Express, Rogue AI agents accessed confidential Indian business records, CERT-In says, 16 October 2026
12. Business Standard (PTI), ‘Cert-In alert on AI agents an early warning, no major financial loss’, 16 October 2026