India’s Computer Emergency Response Team has released a 107-page framework for auditing artificial intelligence systems, moving AI governance from policy statements toward evidence that an auditor can test.
The AI Security Auditing Guidelines v1.0, dated November 4, apply to AI developed, bought, deployed or operated by organizations in India, as well as systems that process Indian data or serve Indian users. The scope includes in-house models, open-source software, third-party products and API-delivered services. Undeployed academic research, purely rules-based automation and personal consumer use are excluded, although providers of consumer AI tools remain in scope.
The framework’s most practical change is not another set of principles. It asks organizations to inventory each AI system, score its inherent risk, assemble reproducible evidence and prove that controls work in operation. For generative and agentic AI, that means testing permissions, tool calls, retrieval stores, approval gates, emergency stops and rollback rather than pointing to a responsible-AI policy.
There is an important limit to the announcement. The document does not identify a commencement date, a standalone enforcement provision or a penalty schedule. It should not be described as a new AI law. Existing CERT-In directions still govern matters such as reporting qualifying cyber incidents within six hours and retaining logs for 180 days. Companies should map the new audit framework to the rules, sector requirements and contracts that already apply to them.
Four risk tiers decide how much audit work is required
Each system is scored across eight factors before controls are taken into account: potential impact, autonomy, data sensitivity, scale and exposure, reversibility, sector criticality, adversarial exposure, and complexity or auditability. A missing document cannot be used to justify a lower score. Features such as autonomous safety-critical action or the absence of an interrupt and rollback mechanism can also push a system into a higher tier.
| Tier | Score | Illustrative use | Audit expectation |
|---|---|---|---|
| Low | 8–12 | Internal meeting summarizer | Self-assessment or basic internal review; annual review |
| Moderate | 13–19 | Support chatbot with staff escalation | Documented internal audit and continuous assessment, with at least annual CERT-In-empanelled review in the framework’s schedule |
| High | 20–26 | Loan-approval model | Independent audit by a CERT-In-empanelled organization; reassessment can be required every six months where risk or material change warrants |
| Critical | 27–32 | AI controlling power-grid load | Independent empanelled audit, continuous monitoring and event-triggered reassessment |
The tier is not permanent. It must be revisited at least annually and after a material model, data, architecture or use-case change; an incident; a regulatory direction; or a move from pilot to production. Smaller companies receive a simplified path for Low and Moderate systems, but the framework does not give them an exemption for High or Critical deployments.
For High and Critical work, a one-person audit is not enough. The team must include at least one AI or machine-learning specialist and one certified auditor. Vendor opacity is also treated as a limitation, not evidence of conformity: an auditor who cannot inspect a hosted model cannot simply mark it compliant.
The audit baseline covers nine domains
Governance and security apply even to Low-tier systems. From Moderate upward, the baseline spans all nine domains:
- Governance and accountability: a named owner, complete AI inventory, responsibility matrix, governance committee and AI impact assessment before higher-risk systems go live.
- Data lifecycle, quality and privacy: approved data sources, lineage, access control, retention, consent evidence where required, poisoning defenses and separation between training and live data.
- Model risk management: version control, validation, model cards, decommissioning tests and an AI bill of materials covering models, datasets, prompts, libraries and tools.
- Ethics, bias and fairness: pre-launch testing, proxy-variable review, counterfactual tests for high-impact systems and production monitoring.
- Explainability and transparency: decision records that can reconstruct an outcome and explanations that affected people can understand.
- Security and incident reporting: threat models, AI-specific penetration tests, model-file integrity, API security, supply-chain scanning and a tested reporting process.
- Continuous monitoring: thresholds for performance, data drift, concept drift and fairness drift, with approval gates before retrained models reach production.
- Human oversight: documented approval, supervision or shutdown models; trained reviewers; override logs; and tested emergency controls.
- Third-party assurance: vendor due diligence, audit rights, incident and change notifications, bills of materials and tested exit plans for important providers.
Fieldwork must show that controls operate, not merely that a policy exists. Reproducible tests should record the model or model hash, prompt version, configuration and other settings. Prompts, agent tool calls and human overrides become audit samples. AI tools can assist auditors, but their output is not evidence by itself and does not displace human accountability.
Agentic AI gets a much harder test
The guidelines add controls for generative AI, retrieval-augmented generation, multimodal systems, multi-agent deployments and cyber-physical AI. This is where the document goes beyond a conventional information-security audit.
An agent should have its own identity instead of silently inheriting all of a user’s permissions. Its tools, plugins and Model Context Protocol servers need authentication and explicit authorization. High-risk actions need approval gates, and auditors are expected to try alternate interfaces to determine whether those gates can be bypassed.
Multi-agent systems should maintain a distinct identity and execution record for each participant. Delegation needs boundaries so one agent cannot create an uncontrolled chain of sub-agents. For a consequential workflow, the evidence package should show who initiated the run, which agent made each decision, what data it retrieved, which tool it called, what credentials it used, whether a person approved the action and how the result could be reversed.
The framework also rejects input filtering as the main defense against prompt injection. Tests should include hidden instructions in documents, retrieved content, tool output and media; cross-user leakage from vector stores; poisoned retrieval or memory entries; unsafe tool calls; model extraction; privacy attacks; and stale or deleted content reappearing in answers.
Emergency controls must be operational. High-risk agents need a working stop mechanism, credential revocation and rollback. Cyber-physical systems need an independent safety interlock, a defined safe state and manual takeover. A runbook that has never been exercised is weak evidence.
A practical 30-day readiness plan
Organizations do not need to begin by buying another governance platform. They need a defensible inventory and one end-to-end test.
- Find the systems: list production, pilot and shadow AI across business units. Record owners, users, data, models, APIs, retrieval stores, tools and external vendors.
- Score inherent risk: apply the eight factors before assuming that existing controls lower the tier. Document uncertain scores and use the higher tier until evidence resolves them.
- Build one evidence pack: choose the most consequential workflow and collect its impact assessment, architecture, model card, AIBOM, data lineage, access matrix, test results, monitoring thresholds, incident runbook and vendor terms.
- Replay a real transaction: reconstruct an output from its model version, prompt, retrieved data and settings. For an agent, include every tool call, approval and side effect.
- Attack the control path: test prompt injection, poisoned retrieval, excessive permissions, approval bypass, data crossover, credential misuse and failure of the emergency stop.
- Exercise containment: revoke the agent’s credentials, isolate it, roll back a harmful action and restore service. Record recovery time and any missing telemetry.
- Fix contracts: require incident and vulnerability notice, material-change notice, provenance information, audit rights and an exit path. A provider’s assurance report may help, but it does not replace evidence about the customer’s deployment.
- Test the six-hour clock: decide who determines whether an AI incident is reportable, who contacts CERT-In, what minimum facts can be assembled quickly and how evidence will be preserved.
The Data Security Council of India’s implementation brief offers a concise map of the tiers and domains. CERT-In also maintains its list and process for empanelled information-security auditing organizations. Sector-regulated companies should check how RBI, SEBI, IRDAI, TRAI or another authority incorporates the framework before treating every recommendation as independently binding.
The useful test is simple: can a team reconstruct what its AI did, prove that its permissions were necessary, stop it quickly and show that a person remained accountable? CERT-In’s framework turns those questions into audit evidence. Many organizations will discover that their model documentation is ahead of their operational controls.
