PARAS MADAN
All writing

Latest in AI

CERT-In's AI Audit Guidelines Put Agent Permissions and Evidence Under Scrutiny

India's new AI auditing framework defines four risk tiers and detailed agent controls. Its practical relevance should be separated from claims of a new universal law.

An AI agent can produce a convincing answer while leaving a much harder question unanswered: what was it allowed to do, and can anyone reconstruct what it actually did?

India's CERT-In published AI Security Auditing Guidelines on November 4. The 107-page framework uses four risk tiers, from low to critical, to shape audit depth and oversight. Its stated scope includes organisations operating AI in India and systems processing Indian data or serving Indian users.

The agent section is concrete

The official guidelines call for documented agent identities, authorised objectives, approved tools and permission limits. Agents should not automatically inherit permissions from users, tools or other agents.

They also specify human approval for consequential actions, records that reconstruct execution chains, and emergency interruption, credential revocation and rollback for high-risk agentic systems. Connections to external tools and MCP services should be inventoried and authenticated.

For retrieval systems, the document says retrieved material must remain untrusted and must not override higher-priority instructions or bypass user access restrictions. Its audit planning also distinguishes mandatory external requirements from informative references.

These details offer a useful review agenda for engineering teams. Take one workflow that can alter a customer record, send a message or modify a system. Identify the service identity behind each step, the permission it uses and the evidence left behind. Then test whether the same action can slip through an alternative route without the intended approval.

A demonstration of the successful path will not answer those questions. A useful test should also include a misleading retrieved document, an unavailable tool and a partially completed action. The team needs to know how the workflow stops, what remains changed and who can safely resume it.

Keep the legal claim precise

Mint's November 4 reporting, citing an official with knowledge of the matter, describes the guidelines as binding on CERT-In-empanelled cybersecurity auditors rather than a new binding law for AI developers. The official said a decision to turn the framework into law would be a separate matter.

That distinction matters when discussing the release with customers. The document is a published audit framework. A claim that it immediately imposes a new universal AI law would go beyond that reported status. Organisations should establish which sector rules, contracts and audit requirements actually apply to their systems.

For existing incident-reporting duties, The Indian Express notes that the six-hour reporting requirement builds on CERT-In's 2022 cybersecurity directions. Teams should avoid treating an older obligation mentioned in a new framework as a newly created deadline.

Prepare evidence that survives an audit

A sensible first step is a short evidence pack for one important production workflow: its owner, allowed actions, connected services, approval points, test results and recovery procedure. Ask someone outside the implementation team to follow a recorded execution from request to final effect.

If they cannot explain why an action was permitted or what happened after a failure, that is a practical gap worth fixing. The work improves the ability to investigate an incident and answer a buyer's security questions, whichever legal or contractual audit route ultimately applies.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help AI teams explain security controls and technical tradeoffs clearly, with the evidence behind their claims.

Book a 30-minute call.