Regulation mapping

Compliance teams ask how an AI agent is overseen and how its actions are recorded. This page maps Parmana to the provisions they cite: the EU AI Act’s human oversight and record keeping articles, the NIST AI Risk Management Framework, ISO/IEC 42001, and the Reserve Bank of India’s IT and AI guidance. What Parmana is, for these purposes. Parmana is not itself an AI system. It sits between an AI agent and the systems it acts on, refuses any action a person has not approved, and signs a record of each action and each refusal. It is a technical measure a provider or deployer of an AI system can use to meet oversight and logging obligations for the actions an agent takes. It does not make a system compliant on its own, it does not cover the model, and this page is not legal advice. Ratings, as on the OWASP mapping:

Supports: Parmana provides a technical measure that meets 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, training or process. Parmana can record it, not do it.

Evidence refers to sections of docs/CLAIMS.md, threats in THREAT-MODEL.md, and attack scenarios you can run with npm run evaluate -- EV-xx (Evaluate Parmana).

EU AI Act

Articles 12, 14 and 26 apply to high-risk AI systems. Under the Digital Omnibus on AI, in force since July 2026, the high-risk obligations apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Check the current text and your system’s classification with counsel.

Provision	What it asks	Rating	What Parmana provides	Evidence	What stays with you
Art. 14(1)	The system can be effectively overseen by natural persons while it is used, including through suitable tools.	Supports	A person is placed before every action: no agent action runs without a signed approval from a registered approver for that action and resource, and the amount where the policy names one. Reads included.	2.42, 2.47; T2; EV-04	Designing the agent and its use so that the actions that matter go through Parmana.
Art. 14(4)(a)	Overseers can monitor operation and detect anomalies.	Partly	Every action and every refusal has a signed record a person can read and verify offline; callers’ requests are in a hash chained audit trail. Approvers can be told when a request waits on them.	2.5, 2.6, 2.46; T12; EV-14	Understanding the model’s capacities and limits; dashboards and alerting on the records.
Art. 14(4)(b)	Overseers stay aware of automation bias.	Organizational	The approver signs one specific action, resource and amount, not a standing permission.	2.42	Training approvers.
Art. 14(4)(c)	Overseers can correctly interpret the output.	Partly	What an approver signs names the action, the resource and the amount in plain values, so the approver sees what will happen, not the model’s reasoning.	2.42	Explaining the model’s output.
Art. 14(4)(d)	Overseers can decide not to use, disregard or override the output.	Supports	An action the agent proposes does not run unless a person signs for it; not signing is a refusal, recorded and signed.	2.47; T2; EV-04	Reversing an action that already ran is a business process in the target system.
Art. 14(4)(e)	Overseers can intervene or stop the system.	Partly	Remove an agent’s key to stop it acting (effective on restart or redeploy); revoke an approver or an external connector through maker checker; approve a policy version that refuses. An approval already signed expires within its lifetime.	2.16, 2.45, 2.49; T1, T11	Stopping the agent itself; an action already released is not recalled.
Art. 12	The system automatically records events (logs) over its lifetime, to identify risks and monitor operation.	Supports	Each approved action has a signed Execution Trust Record (the decision, the policy and its version, the approval, the authorization, the result), each refusal a signed Refusal Record, and each caller request a chained audit event. Records verify offline with only the public key.	2.5, 2.6, 2.19; T12, T14; EV-14	Logging inside the model and the agent.
Art. 26(1), (2)	Deployers use the system as instructed and assign oversight to people with the necessary competence, training and authority.	Partly	Approvers are registered keys, added and revoked through maker checker, so who may approve is explicit and recorded.	2.45; T11	Choosing and training approvers. Approvers are not yet limited to particular actions or policies (G-50).
Art. 26(6)	Deployers keep the system’s logs for at least six months.	Partly	Records are stored in the deployer’s own database; no repository has a delete method, and a deleted row breaks the hash chain.	Limitations: audit tampering	Setting and enforcing retention, and backups.

NIST AI Risk Management Framework (AI RMF 1.0)

Subcategory	What it asks	Rating	What Parmana provides	Evidence	What stays with you
GOVERN 3.2	Roles and responsibilities for human-AI configurations and oversight are defined.	Partly	The roles are enforced in software: an agent can propose, only a registered approver can approve, and policy and approver changes need a second person.	2.26, 2.45, 2.47; T11; EV-13	Defining the roles in your organization; per action approver limits (G-50).
MAP 3.5	Processes for human oversight are defined, assessed and documented.	Supports	Each action’s policy states, in a versioned file approved through maker checker, which approval it needs; the record shows the approval used.	2.26, 2.42, 2.47	Documenting why each oversight level was chosen.
MANAGE 2.4	Mechanisms exist to supersede, disengage or deactivate an AI system whose outcomes are inconsistent with intended use.	Partly	Actions can be stopped by removing the agent’s key, approving a refusing policy version, or revoking a connector or approver.	2.16, 2.45, 2.49	Stopping the model or agent itself.
MEASURE 2.7	Security and resilience are evaluated and documented.	Supports	A threat model, 16 runnable attack scenarios, a public security challenge, mutation and fuzz tests.	THREAT-MODEL.md; `npm run evaluate`; docs/MUTATION-TESTING.md	Evaluating the model and your deployment.
MEASURE 2.8	Transparency and accountability risks are examined and documented.	Supports	Each action is attributable: the record names the caller, the approver, the policy version and the result, signed. Claims and open gaps are published.	2.5, 2.6; CLAIMS.md, VERIFICATION-GAPS.md	Accountability for decisions made outside Parmana.
MANAGE 4.1	Post-deployment monitoring, including override, incident response and change management.	Partly	Refusals are recorded and signed; policy changes go through maker checker with a signed approval record; records can be replayed and verified.	2.26, 2.7	Monitoring and incident response processes.

ISO/IEC 42001 (AI management system), Annex A

Control	What it asks	Rating	What Parmana provides	Evidence	What stays with you
A.3.2 AI roles and responsibilities	Define and allocate responsibilities for AI activities.	Partly	Approver and maker checker roles are enforced and recorded.	2.26, 2.45	The allocation itself; G-50.
A.6.2.6 AI system operation and monitoring	Operate and monitor the AI system.	Partly	Every action is checked against its policy and approval before it runs, and recorded after.	2.47, 2.5	Monitoring the model’s performance.
A.6.2.8 AI system recording of event logs	Record event logs across the life cycle.	Supports	Signed Execution Trust Records, Refusal Records and a chained caller audit trail, verifiable offline.	2.5, 2.6, 2.19; EV-14	Retention, and logs inside the model.
A.9 Use of AI systems	Use AI systems responsibly and as intended.	Partly	Each agent’s key is limited to the actions it is meant to take, each action to its policy, each policy to an approval.	2.16, 2.22, 3.16; EV-12	Defining intended use.
A.10 Third-party and customer relationships	Manage AI related risks with suppliers and customers.	Partly	External systems are reached only through connectors registered by maker checker, with signed releases.	2.49, 2.50	Supplier agreements and assessment.

Reserve Bank of India (RBI)

For banks, NBFCs and payment system operators using AI agents, for example an agent that issues refunds through the Paytm connector (Connectors). Three RBI texts are relevant, with different status:

The Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (7 November 2023, in force from 1 April 2024) is binding on the banks, NBFCs, credit information companies and all India financial institutions it names.
The FREE-AI Committee report (Framework for Responsible and Ethical Enablement of AI, 13 August 2025) makes 26 recommendations. It is a committee report, not a direction.
The draft Guidance on Regulatory Principles for Model Risk Management, 2026 (24 June 2026, consultation closed 24 July 2026) covers AI and machine learning models. It is a draft; check the final text.

Provisions are summarized, not quoted, and FREE-AI recommendations are given a number only where it was confirmed. Read the source texts.

Provision	What it asks	Rating	What Parmana provides	Evidence	What stays with you
IT Direction, audit trails	Applications that can access or affect critical or sensitive information have audit and system logging and provide audit trails; logs are monitored to detect unauthorised activity.	Supports	Each approved action has a signed Execution Trust Record, each refusal a signed Refusal Record, each caller request a chained audit event; a refused write to the audit trail refuses the request.	2.5, 2.6, 2.19, 2.32; T12; EV-14	Monitoring the records; retention; logs of systems that do not go through Parmana.
IT Direction, cryptographic controls	Key lengths, algorithms, cipher suites and protocols used for data and authentication are strong.	Supports	Records and approvals are signed with Ed25519, optionally together with ML-DSA-65 (post quantum); each key is bound to its algorithm.	2.13, 2.14, 3.13	TLS configuration; key storage and rotation in your key management system.
FREE-AI, board approved AI policy	The board approves an AI policy covering governance, the AI lifecycle, risk controls and vendor liability.	Organizational	Each action’s policy is a versioned file approved through maker checker, so the policy in force for every action is recorded.	2.26, 2.34	The board policy itself.
FREE-AI Rec. 21, business continuity for AI systems	Fallbacks such as human in the loop review, and periodic tests of the fallback.	Partly	Parmana fails closed: when the policy, the approval or the signing key is missing or invalid, the action is refused, not run without checks. A human approval can be required for any action.	2.12, 2.17, 2.47; T2	The manual process that takes over when the agent is stopped, and testing it.
FREE-AI Rec. 22, AI incident reporting	Report AI incidents to a sector framework in time.	Partly	Signed records of what the agent did and what was refused, verifiable by a third party, to support an incident report.	3.11; EV-14	Detecting incidents and reporting them.
FREE-AI Rec. 24, AI audit framework	AI systems are audited, internally and by third parties.	Supports	An auditor can verify every record offline with only the public key, without access to your systems. Claims, tests and open gaps are published.	2.5, 3.11; CLAIMS.md	Running the audit; auditing the model.
FREE-AI Rec. 25, disclosures	Disclose AI governance, adoption and consumer protection, for example in the annual report.	Organizational	Records can show how many actions were approved and refused, and by which policy.	2.5	The disclosure.
Draft MRM guidance, kill switch	A malfunctioning AI model can be suspended or deactivated at once.	Partly	An agent’s actions can be stopped: approve a policy version that refuses, revoke a connector or an approver, or remove the agent’s key (effective on restart or redeploy). An action already released is not recalled.	2.16, 2.45, 2.49; T1, T11	Stopping the model or agent itself.
Draft MRM guidance, documented human oversight	Human oversight of model use is documented, with periodic human review of outputs.	Supports	No agent action runs without a signed approval from a registered approver; the record names the approver, the policy version and the result.	2.42, 2.47; T2; EV-04	Periodic review of the model’s outputs that do not become actions.
Draft MRM guidance, model inventory and named roles	Every model is in an approved inventory with a named owner, developer, validator and approver.	Organizational	Approvers are registered keys added and revoked through maker checker, so the people who approve agent actions are named and recorded.	2.45; T11	The model inventory. Approvers are not yet limited to particular actions or policies (G-50).
Draft MRM guidance, customer disclosure	Customers are told when they deal with AI and can switch to a human.	Organizational	Nothing directly.		The disclosure and the hand over to a person.

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.
Each rating has evidence you can check: run the attack scenarios, read the claim and its tests.
Open issues that matter here: approvers are not yet limited to particular actions or policies (G-50); facts an agent declares are not checked against another system and can only refuse (G-51). See Limitations.
This is a mapping, not a certification or legal opinion. The provisions are summarized; read the source texts: Regulation (EU) 2024/1689, NIST AI RMF 1.0 and ISO/IEC 42001:2023, the RBI IT Governance Master Direction and the FREE-AI report.

​EU AI Act

​NIST AI Risk Management Framework (AI RMF 1.0)

​ISO/IEC 42001 (AI management system), Annex A

​Reserve Bank of India (RBI)

​Reading this page

EU AI Act

NIST AI Risk Management Framework (AI RMF 1.0)

ISO/IEC 42001 (AI management system), Annex A

Reserve Bank of India (RBI)

Reading this page