CERT-In AI security audit guidelines mapping

CERT-In, India’s national cybersecurity agency, has proposed a draft framework of Artificial Intelligence Security Auditing Guidelines. The draft classifies AI systems by risk (low, moderate, high and critical), puts particular weight on AI agents, and asks for least privilege, a kill switch for high-risk agentic systems, continuous monitoring and independent audits for critical systems, and reporting of AI security incidents within six hours. This page maps Parmana to the provisions of that draft as reported. It is a draft, so the final text may differ. Read the source text from CERT-In before relying on any row. This page is a mapping, not a certification or legal opinion. What Parmana is, for these purposes. Parmana is not an AI model. It sits between an AI agent and the systems it acts on, refuses any action that a registered person has not approved under a versioned policy, and signs a record of each approved action and each refusal. It covers actions that go through its gateway. It does not see inside the model, the training data or the content the model produces. Ratings, as on the regulation mapping:

Supports: Parmana provides a technical measure for the requirement, for actions that go through it, with evidence you can check.
Partly: Parmana provides part of it. The rest is named.
Organizational: the requirement is about people, process or documentation. Parmana can record it, not do it.
Not covered: the requirement is outside what Parmana does.

Agents and least privilege

Draft provision	What it asks	Rating	What Parmana provides	Evidence	What stays with you
Least privilege: agents operate with only the access their task needs	Agents get only the permissions they need.	Partly	Each agent’s key is limited to the actions it is meant to take, each action to its policy, and each policy to an approval. Reads are approved too.	2.16, 2.22, 3.16; EV-12	Choosing the minimum set of actions for each agent. Approvers are not yet limited to particular actions or policies.
No inherited permissions: agents do not automatically inherit permissions from users, tools or other agents	A user’s or another agent’s permissions do not pass to an agent by default.	Partly	An approval is for one specific action, resource and amount, signed by a registered approver. It is not a standing permission that the agent carries. This applies to actions through the gateway. An agent that calls a system directly is not covered.	2.42, 2.47; T2	Keeping agents on the gateway. Direct agent-to-system paths are an open gap (see Limitations).

Risk classes and high-risk agents

Draft provision	What it asks	Rating	What Parmana provides	Evidence	What stays with you
Risk classification: low, moderate, high or critical	Each AI system is classed by risk, and controls scale with the class.	Partly	Policies are per action and versioned, and a human approval can be required for any action. A stricter class can be enforced by a stricter policy. Parmana does not assign risk classes itself.	2.47, 2.45	Deciding each agent’s class and writing the policy that matches it.
Kill switch for high-risk agentic systems	Operators can stop the system when necessary.	Partly	An operator kill switch is live in production. A trip refuses new execution requests, transactions and approvals with `KILL_SWITCH_ACTIVE`. The stop is stored in the database, so it survives restarts, and a reset needs two different operators. Other routes to the stop are removing an agent’s key, or revoking a connector or approver. See Operator kill switch.	2.16, 2.45, 2.49, 2.58; T1, T11	Stopping one agent alone, since the switch stops every caller. Halting a tool reached without Parmana. The switch status is not yet signed.
Least-privilege and kill-switch tests	Controls are tested.	Supports	The kill switch is probed every 15 minutes from a scheduled workflow outside Parmana, and every probe result is kept. Attack scenarios are runnable with `npm run evaluate`.	2.58; EV-04	Running the checks against your own deployment and reading the results.

Model development, data and outputs

Draft provision	What it asks	Rating	What Parmana provides	Evidence	What stays with you
Scrutiny of training data, bias and the development lifecycle	Data sourcing, bias handling and safeguards across development.	Not covered	Nothing. Parmana does not see the model or its training.	None	The model provider and the deployer.
Hallucination mitigation, and harmful, biased or copyrighted outputs	Outputs are checked for accuracy, harm, bias and copyright.	Not covered	Parmana checks the action an agent proposes, not the content of the model’s output.	None	Output quality, content review and copyright checks.
Labelling or watermarking of AI-generated content	Synthetic content is labelled where the context requires it.	Not covered	Nothing.	None	Labelling at the point the content is produced or published.

Monitoring, audit and incident reporting

Draft provision	What it asks	Rating	What Parmana provides	Evidence	What stays with you
Continuous monitoring for critical-risk systems	Ongoing monitoring of the system’s behaviour.	Partly	Every approved action and every refusal has a signed record, and each caller request has a chained audit event. These are the raw material for monitoring. Alerting and dashboards are not part of Parmana.	2.5, 2.6, 2.46; T12	Monitoring, alerting and response on the records.
Independent security audit by a CERT-In-empanelled organisation	An independent audit of the AI system.	Organizational	Records verify offline with only the public key, so an auditor can check them without access to your systems. Claims, tests and open gaps are published. The reviews so far are internal, not an independent audit, and a third-party check is an open item.	2.5; EV-14	Commissioning and paying for the audit. Choosing an empanelled auditor.
Six-hour reporting of AI security incidents to CERT-In	Report AI-related security incidents within six hours.	Partly	Signed records show what was authorized, what ran and what was refused, and a third party can verify them. Parmana does not detect incidents or send reports.	2.5, 3.11; EV-14	Detecting the incident, deciding that it is reportable, and sending the report within the window. Plan how quickly records can be pulled.
Lifecycle coverage across training, development, deployment and monitoring	Oversight across the whole AI lifecycle.	Partly	Covers the deployment and operation stage for actions that go through Parmana, from approval to recorded result.	2.47, 2.5	Every other stage.

Open items that matter here

Direct agent paths. An agent that reaches a system without going through Parmana is outside the controls above (see Limitations).
Approver scope. Approvers are not yet limited to particular actions or policies.
Signed status. The kill switch status and audit events are not yet signed.
Independent assurance. No third-party audit has been completed.

Gaps and opportunities

The gaps below are the ones the tables above name. Each is a candidate for work, and none is a commitment.

Gap	Affects	Opportunity	Reference
Agents that call systems directly are outside the controls	Least privilege, no inherited permissions	Bring inbound agent calls under authorization, so the gateway is not the only route	G-129, RFC-0024. Limit documented 2026-11-05; see Inbound agents
Approvers are not limited to particular actions or policies	Least privilege, risk classes	Scope each approver to named actions, policies and amounts	G-50 (#397)
The kill switch stops every caller at once	Kill switch	Add a per-agent halt, so one agent can be stopped without stopping the rest	G-122
Kill switch status and audit events are not signed	Kill switch, six-hour reporting	Sign status and audit events with a build-bound signing key	G-118
Connector credentials can be read by code on the same host	Least privilege	Move connector credentials out of reach of the host process	G-128
No risk-class assignment in the product	Risk classification	Provide policy templates for low, moderate, high and critical classes	G-137 (#429)
No alerting or dashboards on the records	Continuous monitoring	Provide an alerting hook or export on approvals, refusals and kill switch trips	G-138 (#430)
No record export designed for a six-hour reporting window	Six-hour reporting	Provide a bounded export of the records for a given window, with verification instructions	G-139 (#431)
No independent third-party audit; two-person reset not yet exercised with real keys	Independent audit, kill switch	Commission an empanelled third-party review, and run a two-person reset drill	G-122
Output content (hallucination, bias, copyright, labelling) is outside Parmana	Model development, outputs	Out of scope for the gateway; point to model-level controls and document the boundary	Not covered
Partial execution: an action in flight, or stopped without a recorded result, leaves the outcome unknown	Halt, and recovery after a halt	Report the outcome as unknown to the caller, and add reconciliation with external systems and provider idempotency keys	Partly; G-125
Approval fatigue: reviewers see too many approvals to review each one	Confirm (human approval)	Batch or threshold low-risk approvals, and measure approval volume per approver	G-135 (#427)
The kill switch is all or nothing; there is no safe pause state	Degrade gracefully	Pause new work to a checkpoint, or route it to a person, before a full stop	G-136 (#428), related G-122
Memory and reasoning are not recorded	Observe and investigate	Decide what to retain and for how long; the retention choice has legal consequences	G-140 (#432)
Content the agent reads can carry instructions	Input integrity	Each write still needs a signed human approval, and the agent cannot approve its own request. The agent still reads the content, so this limits the effect rather than preventing it	G-141 (#433)

Reading this page

Only actions that go through Parmana are covered. Give agents credentials only to Parmana, so it is the one route to your systems.
Cross-reference. DSCI’s discussion paper on AI liability for agentic AI (2026) covers the same instruments and gaps, including approval fatigue, partial execution and the kill switch’s position in a hierarchy of controls. It is a consultation draft.
Each rating has evidence you can check. Claim numbers refer to the claims register.
The draft may change. Check the final CERT-In text and your system’s risk class with counsel.

Self hosted

Deploy

Security

Operate

CERT-In AI security audit guidelines mapping

Agents and least privilege

Risk classes and high-risk agents

Model development, data and outputs

Monitoring, audit and incident reporting

Open items that matter here

Gaps and opportunities

Reading this page

​Agents and least privilege

​Risk classes and high-risk agents

​Model development, data and outputs

​Monitoring, audit and incident reporting

​Open items that matter here

​Gaps and opportunities

​Reading this page

Agents and least privilege

Risk classes and high-risk agents

Model development, data and outputs

Monitoring, audit and incident reporting

Open items that matter here

Gaps and opportunities

Reading this page