> ## Documentation Index > Fetch the complete documentation index at: https://docs.parmanasystems.com/llms.txt > Use this file to discover all available pages before exploring further. # CERT-In AI security audit guidelines mapping > How Parmana maps to the draft Artificial Intelligence Security Auditing Guidelines proposed by CERT-In, India's cybersecurity agency, with what is covered, what is partly covered and what is not. 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](https://docs.parmanasystems.com/security/regulation-mapping.md): * **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](https://docs.parmanasystems.com/security/limitations.md)). | ## 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](https://docs.parmanasystems.com/security/operator-kill-switch.md). | 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](https://docs.parmanasystems.com/security/limitations.md)). * **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](https://docs.parmanasystems.com/security/limitations.md#inbound-agents-that-reach-your-systems-directly) | | 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](https://github.com/pavancharak/parmana-core/blob/main/docs/internal/CLAIMS.md). * **The draft may change.** Check the final CERT-In text and your system's risk class with counsel. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.