Every CISO and AI risk lead we speak to in 2026 is being asked the same three questions in the same week: are we aligned with NIST AI RMF, are we ready for an ISO/IEC 42001 audit, and do we cover the OWASP Top 10 for Agentic Applications. The honest answer is that the three frameworks operate at three different altitudes. NIST AI RMF is a process function model. ISO/IEC 42001 is a management system standard. OWASP ASI 2026 is a technical risk catalogue. A team can be compliant with one and silently non-compliant with the others.
This post is a crosswalk — not another framework. It shows how a single AgentGuardian posture report (96 probes against a target agent, sharded across ASI01-ASI10, scored with AIVSS) yields evidence that maps to NIST AI RMF MANAGE-2.3 and MEASURE-2.6, to ISO/IEC 42001 Annex B controls B.6 through B.9, and to all ten OWASP ASI 2026 categories. The intent is to make a compliance memo reusable across three audit boards rather than three.
Why compliance teams need a crosswalk, not another framework
The proliferation of AI governance frameworks since late 2024 has produced an awkward outcome for second-line risk: the same finding has to be re-described three times to satisfy three audiences. A prompt injection that hijacks a customer-service agent is, at once: an ASI01 Goal Hijack finding (developer vocabulary), a MEASURE-2.6 deviation (process auditor vocabulary), and a B.6.2.4 control gap (management-system auditor vocabulary). The technical evidence is identical. The narrative wrappers are not.
Three real costs follow. First, the same incident gets logged in three trackers and reported in three boards with no shared ID, making aggregate trend analysis impossible. Second, controls get implemented at the wrong altitude — teams write a one-paragraph policy to satisfy ISO 42001 and skip the runtime probe that would have satisfied OWASP ASI. Third, evidence packs balloon — the same SARIF file is exported into three formats because the ingestion pipeline downstream of each audit does not share a schema.
A crosswalk solves the first two of these problems and reduces the third. The shape we recommend is: one technical evidence artefact, three narrative views, one shared finding ID. The rest of this post walks through what each view looks like, what evidence backs it, and which controls land cleanly versus which still require human narrative.
NIST AI RMF: MANAGE and MEASURE mapped to ASI categories
The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) structures risk management into four functions: GOVERN, MAP, MEASURE, and MANAGE. The two that map cleanly to a runtime red-team scan are MEASURE (analyse risks and effectiveness of controls) and MANAGE (allocate resources, treat residual risk). The functions we crosswalk most often are MEASURE-2.6, MEASURE-2.7, MANAGE-2.3, and MANAGE-4.1.
MEASURE-2.6 is the explicit call-out for AI safety and security testing — "the AI system is evaluated regularly for safety risks including those that emerge from interaction with humans and other systems". A 96-probe ASI01-ASI10 corpus run on a release candidate with an AIVSS score, signed evidence bundle, and date-stamped target SHA is the lowest-friction satisfaction of this measure we have seen in production. MEASURE-2.7 covers security and resilience — penetration testing and adversarial testing of the AI system. The same artefact serves both with one cross-reference in the cover memo.
MANAGE-2.3 ("mechanisms are in place and applied to sustain the value of deployed AI systems") and MANAGE-4.1 ("post-deployment monitoring") are where the runtime tier of AgentGuardian Enterprise comes in. A point-in-time scan satisfies MEASURE; a continuous monitor with policy enforcement and audit logs satisfies MANAGE. Teams that have only the first part check MEASURE but leave MANAGE narrative-only.
The clean mapping we use today:
We do not claim this is a complete NIST AI RMF mapping — GOVERN and MAP are explicitly out of scope for a technical scan. Those two functions are policy and inventory, which require human artefacts (charters, role descriptions, system cards) regardless of how good the runtime testing is. Treat the technical evidence as a necessary condition for MEASURE and MANAGE, not a sufficient condition for the whole framework.
ISO/IEC 42001: Annex B controls that align to runtime evidence
ISO/IEC 42001:2023 is the international management system standard for artificial intelligence. The body of the standard mirrors other ISO management systems (clauses 4 through 10: context, leadership, planning, support, operation, performance evaluation, improvement). The action is in Annex A (control objectives) and Annex B (implementation guidance). The Annex B controls that an agentic red-team report satisfies most cleanly are:
- —B.6.1.2 — AI system impact assessment: a posture scan with per-category AIVSS breakdown provides the empirical input that an impact assessment narrative is otherwise written from gut feel.
- —B.6.2.3 — Verification and validation: the SARIF artefact, the probe-by-probe pass/fail table, and the deterministic AIVSS score together constitute the verification evidence for the AI system component of the management scope.
- —B.6.2.4 — Deployment: gating deployment on a CI check (
--fail-above 25) provides the operational record that the verification step is not optional and is consistently applied. - —B.6.2.6 — AI system operation and monitoring: the runtime tier (Enterprise) closes this control with policy logs that an internal auditor can sample at quarterly intervals.
- —B.7.2 — Data quality for AI systems: the ASI06 probe shard (memory poisoning, RAG injection, vector bleed) provides direct evidence of data integrity controls under adversarial conditions, which an opinion-based data quality narrative cannot.
- —B.9.2 — Reporting concerns: signed evidence bundles with verifiable hashes provide the chain-of-custody that internal audit needs when a finding is escalated.
The controls that are not satisfied by a technical scan and require separate narrative are B.5 (leadership commitment), B.6.1.4 (resources for AI), B.8 (third-party relationships), and most of B.9 except B.9.2. These are management controls and require minutes, signed policies, and supplier-due-diligence records that no scanner produces. We are explicit about this in every compliance memo we ship because conflating the two is the fastest way to lose an auditor's trust.
OWASP ASI 2026: where it fills gaps the others leave open
Neither NIST AI RMF nor ISO/IEC 42001 names a single attack technique. Both are technique-agnostic by design — they want to outlive the current state of adversarial research. The cost of that design is that a developer reading either document gets no guidance on what to test for. The OWASP Top 10 for Agentic Applications 2026 (ASI01-ASI10) is the catalogue that names the techniques, and it fills three specific gaps:
- —Memory and state (ASI06): NIST AI RMF mentions "data integrity" once. ISO/IEC 42001 references "data quality" without prescribing tests. OWASP ASI 2026 ships thirteen probe shapes covering RAG corpus injection, persistent triggers in long-term memory, cross-tenant vector bleed, and HITL-bypass — the concrete failure modes a reviewer can sign off against.
- —Agent-to-agent (A2A) compromise (ASI07): neither NIST nor ISO names multi-agent topologies. Both assume a single AI system. ASI07 names supervisor impersonation, message-bus spoofing, confused-deputy, and protocol downgrade as testable patterns when more than one agent is in scope.
- —MCP and tool supply chain (ASI04): the Model Context Protocol ecosystem is too new for either NIST or ISO to address. ASI04 includes MCP server poisoning, registry spoofing, plugin hijack, and poisoned fine-tune checkpoints — the categories that an MCP-reliant agent must defend before going to production.
The way we describe this in compliance memos is that NIST and ISO tell you what good looks like in process, while OWASP ASI 2026 tells you what bad looks like in technique. A mature programme cites both, because an auditor that asks "how do you know your memory layer is not poisoned" is not satisfied by a paragraph from B.7.2 — they want a probe trace.
NIST and ISO tell you what good looks like in process. OWASP ASI 2026 tells you what bad looks like in technique. Cite both.
AgentGuardian evidence packs: one artefact, three views
Every AgentGuardian scan produces a five-file evidence directory: an HTML report for humans, a PDF for boards, a SARIF 2.1.0 file for security tooling, a JSON file for pipelines, and an evidence sub-directory with per-finding traces. Every finding inside carries three labels — OWASP ASI category, MITRE ATLAS v5.4.0 technique ID, and CSA Agentic AI Red Teaming Guide category — and a deterministic AIVSS contribution.
A concrete sample of a single finding header from a SARIF run on an MCP-backed agent:
{
"ruleId": "asi06-rag-corpus-injection-permission-revoke",
"level": "error",
"properties": {
"tier": "T1",
"owasp_asi": "ASI06",
"mitre_atlas": "AML.T0020",
"csa_agentic_rt": "RT-02-memory-rag-poisoning",
"aivss_severity": "critical",
"aivss_contribution": 1.0,
"nist_ai_rmf": ["MEASURE-2.6", "MEASURE-2.7", "MANAGE-2.3"],
"iso_42001_annex_b": ["B.6.2.3", "B.7.2"]
}
}The two compliance-framework fields on the right are added by the crosswalk emitter — they are a pure function of the OWASP ASI category and tier. That means the mapping is deterministic and audit-reproducible: an external assessor can re-derive the framework tags from the underlying ASI tag without trusting the scanner's mapping. We publish the crosswalk table in the OSS repo so it is verifiable in the same way the AIVSS formula is.
The same evidence pack is then rendered into three views by the Enterprise tier:
- —NIST view: findings grouped by RMF function (MEASURE / MANAGE), with a cover narrative tying each group to MEASURE-2.6, MEASURE-2.7, and MANAGE-2.3 verbatim from AI RMF 1.0.
- —ISO 42001 view: findings grouped by Annex B control, with a control-by-control evidence table suitable for internal audit's working papers.
- —OWASP view: findings grouped by ASI category, the developer-facing default, with MITRE ATLAS technique IDs and a remediation playbook per category.
All three views are generated from the same SARIF source. The finding IDs are identical across views. When an internal auditor and a developer talk about asi06-rag-corpus-injection-permission-revoke they are talking about the same row in the same database, regardless of which audit framework triggered the conversation.
What is explicitly not mapped today
Transparent positioning matters more than coverage in compliance tooling. AgentGuardian's crosswalk emitter today covers OWASP ASI 2026, MITRE ATLAS v5.4.0, CSA Agentic AI Red Teaming Guide, and the MEASURE/MANAGE subset of NIST AI RMF, plus the runtime controls of ISO/IEC 42001 Annex B. The list of things it does not do today is also worth stating:
- —EU AI Act conformity: we do not map findings to Article 9 (risk management) or Article 15 (accuracy, robustness, cybersecurity) because the harmonised standards are still being finalised. We expect to ship this mapping once the CEN-CENELEC JTC 21 harmonised standards are published.
- —NIST AI RMF GOVERN and MAP: these are policy and inventory functions. A technical scanner does not produce a charter or a system card. We render the relevant fields blank in the NIST view rather than fabricating them.
- —ISO/IEC 42001 clauses 4-10 body: the management system body covers leadership commitment, planning, and improvement loops. Our evidence packs are an input to the management review, not a substitute for it.
- —Sector regimes (MAS, APRA, RBI, OJK, BNM, BSP, HKMA): we ship sector-specific evidence packs in Enterprise for the APAC regulators we support, but these are bespoke per jurisdiction and are not generated by the OSS crosswalk emitter.
We list these explicitly because the failure mode we see most often in third-party AI governance tools is silent over-claiming — the report renders a "EU AI Act Article 15 compliant" stamp because the field was hard-coded to true. An auditor catches that once and the tool's credibility is gone. Better to render the field blank with a "not mapped" annotation and let the human write the narrative.
A sample compliance memo, drawn from a single posture report
What does the artefact look like end-to-end? Here is the opening of a compliance memo we generated from a single AgentGuardian posture report against a customer-service agent built on LangGraph with a Postgres-backed memory and three internal MCP tools. We have anonymised the target and rounded the numbers.
To: Risk and Compliance Committee
From: AI Platform Engineering
Subject: Pre-release adversarial posture for release candidate cs-agent-2026.05.12
Evidence: AgentGuardian posture report ag-evidence-9f4c1a82
Release candidate cs-agent-2026.05.12 was subjected to the full 96-probe OWASP ASI 2026 corpus in full mode against a production-equivalent staging environment on 2026-05-28. The run produced an AIVSS posture score of 18 out of 100 (lower is better), below our internal gating threshold of 25.
For NIST AI RMF, this run satisfies MEASURE-2.6 (regular safety testing) and MEASURE-2.7 (adversarial testing). MANAGE-2.3 (sustained value) is satisfied through the continuous monitor attached to the production deployment, reviewed at every release. GOVERN and MAP are covered separately by the AI governance charter (rev 2026-Q1) and the AI system inventory.
For ISO/IEC 42001 Annex B, this evidence pack supports B.6.1.2 (impact assessment), B.6.2.3 (verification), B.6.2.4 (deployment gating), B.7.2 (data quality under adversarial conditions), and B.9.2 (reporting concerns). Annex B controls B.5 (leadership), B.8 (third-party relationships), and B.9.1 (continual improvement) are addressed in the standing management system documentation, not this artefact.
For OWASP ASI 2026, the residual findings cluster in ASI06 (memory poisoning, two medium-severity findings under HITL-bypass) and ASI09 (trust exploitation, three low-severity findings under output-reflection). Mitigations are tracked in the linked Jira board and re-tested at the next release.
That memo is roughly three hundred words and was generated in under a minute from one SARIF file. It satisfies three audiences, uses three frameworks' vocabularies precisely, and over-claims none of them. That is the bar we hold the crosswalk to.
Operationalising the crosswalk
Three practical recommendations for teams adopting this pattern, whether they use AgentGuardian or build the crosswalk themselves:
- —Make the OWASP ASI category the primary key. Treat it as the technical finding ID. Derive NIST and ISO tags from it. Auditors are happier with a deterministic derivation than a hand-authored mapping, and developers can actually fix the bug if they know the technique.
- —Keep MANAGE and B.6.2.6 honest. Point-in-time scans are not continuous monitoring. If your evidence ends at a CI gate, mark MANAGE-2.3 and B.6.2.6 as partial. A truthful partial is more credible than an inflated full.
- —Publish the crosswalk table. Whether internal or external, the mapping from ASI to NIST to ISO has to be inspectable. The OSS AgentGuardian repo publishes its crosswalk YAML alongside the AIVSS formula precisely so that an external assessor does not have to trust us — they can re-derive every framework tag from the source OWASP tag.
Compliance for agentic AI is not a single-framework problem and will not be solved by waiting for one framework to win. The crosswalk is the engineering response to a regulatory landscape that has settled on three vocabularies. Build it once, in a deterministic way, and the cost of the next audit board is the cost of a re-render rather than the cost of a re-write.