How to Use the Intelligence Navigators

Start here

1. Keep the Intelligence Navigators launch page open as your navigation hub.
2. Select one of the five stage areas on the graphic. Each stage opens in a new browser tab. On a desktop, hover over an area to reveal its label; on a touch device, tap the stage.
3. For a complete review, work from 1 AI Risk through 5 AI Assurance. You can also enter at the stage that matches your immediate question.
4. Record entry names and identifiers as you go, then return to the launch page to open the next stage. The tools do not pass your selections between stages or build a shared assessment for you.

Search & filter controls

The Risk, ATLAS, Vulnerability and Assurance Navigators share the same basic grid behavior:

• Filtering and searching dim nonmatching cards; they do not remove them from the grid.
• Category and search conditions apply together. Select All and clear the search box to reset the view. In Assurance, also choose Show All for frequency.
• Click a card to open its detail panel. Selecting another card replaces the panel content; close it with its × button.
• Framework tags behave differently across tools: some open sources, some show explanatory text on hover, and others are labels only. Use the panel's action buttons, or return to the launch page, when a tag is not a link.

Stage 1AI Risk

Purpose: identify the risk conditions relevant to your AI system. The table contains 60 risks across Data, Model, Agent, Security & Ops, and Governance.

Open AI Risk Navigator ↗

1. Select a category or use Search risks to find a name, risk code or keyword. Search also recognizes several mapped framework identifiers and vulnerability class IDs.
2. Click a risk cell to open its intelligence panel. Review the description, likelihood, impact, risk score, mitigation guidance and framework mappings.
3. Hover over a NIST tag to read its subcategory text. Use ATLAS and OWASP links where provided. "No direct" means no direct relationship is assigned in that entry.
4. Select a related-risk chip to explore connected conditions. Record the risk code and your own system-specific consequence before moving on.

Stage 2AI Threat / MITRE ATLAS

Purpose: examine how an adversary could attack an AI-enabled system. The Navigator contains 51 technique entries, including selected subtechniques. It is a curated reference, not the complete MITRE ATLAS knowledge base.

Open ATLAS Navigator ↗

1. Search by technique name, full ATLAS identifier, tactic or keyword. Use the tactic-group buttons to focus the grid.
2. Click a technique card. Review its description, illustrative attack scenario, likelihood and impact scores, mitigations and framework mappings.
3. Select Related techniques to explore possible attack-chain relationships. A relationship is a prompt for analysis; it does not establish that the whole chain is feasible in your system.
4. Use View on ATLAS to open the source entry. Record the technique identifier and the access, permissions or conditions an attacker would need.

Stage 3AI Vulnerability

Purpose: understand what a weakness, attack technique or risk condition means for an AI system. The Navigator contains 49 class records across Model, Data, Application, Agent, Infrastructure, Governance and Agentic Amplification.

Open Vulnerability Navigator ↗

1. Select a domain or use Search to find a class ID, name, keyword, cited CVE or mapped ATLAS identifier.
2. Click a card and review its TYPE label, description and example scenario. Not every entry describes a product-specific vulnerability or has a CVE.
3. Read CVE / CWE References, Mitigations, AI Amplification Factors and NIST AI 100-2 Classification. Decide whether the described component and exposure conditions apply to your system.
4. Follow source links for individual CVEs, CWEs, ATLAS techniques and OWASP mappings. Use related-vulnerability chips to inspect connected records.
5. Record applicable class IDs and any specific CVEs separately. Carry relevant controls to stage 4 and class IDs to stage 5 for assurance activity searches.

The three SOAI measures

Reading the KEV indicator

A red dot means at least one CVE cited in that record appears in the embedded CISA Known Exploited Vulnerabilities (KEV) catalog snapshot, labeled 2026.10.04. KEV membership applies to the cited CVE, not to the whole vulnerability class or to your deployed system.

Open the record to see which CVEs are flagged. A missing dot does not mean safe: the entry may have no specific CVE, or a cited CVE may not be in that snapshot. Use the CISA KEV and NVD buttons to check current information before any time-sensitive decision.

Stage 4Mitigation & Defense

Purpose: turn risk, threat and vulnerability findings into candidate defensive actions. Stage 4 currently opens the Mitigation & Defense reference page. A full interactive Defensive Controls Navigator is in development; the current page has no searchable card grid or control scoring.

Open Mitigation & Defense ↗

1. Review the nine control domains and their Specific Actions.
2. Select the actions relevant to the weakness you identified and to your system's architecture. Adapt scope, implementation and frequency to your operating context.
3. Use Defends against links to inspect associated vulnerability records.
4. Record each selected action, its owner, the planned implementation and how its effectiveness will be tested.

Make each control testable

Replace a broad statement such as "use human oversight" with a verifiable requirement: "The assistant may prepare an email, but the sending service requires an authorized user to approve the recipient, message and attachments before transmission."

Treat the page's intervals and technical measures as candidate guidance. Do not assume a listed action is sufficient by itself, or that its frequency is mandatory for every environment.

Stage 5AI Assurance

Purpose: select activities that produce evidence about whether defenses work under defined conditions. The Navigator contains 49 activities across Model, Data, Application, Agent, Infrastructure, Governance and Operational assurance.

Open Assurance Navigator ↗

1. Choose a domain and, if useful, a Frequency: Continuous, Periodic or Event-Driven. Select Show All to remove the frequency filter.
2. Search by activity name, activity ID, vulnerability class ID or mapped framework identifier. Searching a class such as APP-02 highlights activities mapped to it.
3. Click an activity. Start with its assurance question, Evidence produced and How to perform this assurance activity.
4. Review Tools & Techniques, Artifact Produced, Key Insight and Assurance Claim Supported. The page provides guidance; it does not run tests or collect artifacts.
5. Review framework crosswalks and Related assurance activities. Combine activities where one test alone would leave material gaps.
6. Define the test boundary, configuration, test data, acceptance criteria, owner and required evidence. Perform the activity in an authorized test environment and keep the actual results in your assessment records.

Assurance scoring

Evidence Strength is the SOAI rating of evidence rigor and repeatability, out of 10. Coverage is the SOAI rating of breadth addressed, out of 10.

Assurance Confidence = (Evidence Strength × Coverage) ÷ 4  → out of 25

For example, Evidence Strength 8 and Coverage 8 give 16/25 (rounded to one decimal place where needed). These predefined values describe the reference activity's relative contribution. They do not measure evidence you have collected, the security of your deployed system or compliance.

Schedule the evidence work

Passing a test supports a bounded claim under the tested conditions. Record failures, coverage limits, unresolved risks and follow-up actions. Reassess when models, data, tools, permissions or operating conditions change.

Example walkthrough

Scenario: an engineering assistant reads supplier documents, searches project files and drafts email. Management is considering letting it send messages. The question: could instructions embedded in a supplier document cause an unauthorized action?

Reference: AI-RMF, Ch. 10 includes a Prompt Injection and RAG Test Checklist for this kind of scenario.

Record one traceable finding

For each finding, keep:

• System and version
• Review date
• Risk code and consequence
• ATLAS technique
• Vulnerability class and applicable CVE/CWE
• Selected control and owner
• Assurance activity
• Acceptance criteria
• Evidence location
• Result
• Coverage limits
• Residual risk
• Next review trigger

Preserve source links and source dates alongside the SOAI interpretation.

Reference: AI Assurance, Appendix B provides templates for this record, including an Assurance Evidence Register.

Common questions

Further reading

The method behind the Navigators is described in the Security of AI™ book series:

• Security of AI: The Convergence of AI Governance, Security and Assurance
• AI-RMF: Operationalizing AI Risk Management Through Security of AI
• AI Assurance: The Proof Pillar of Security of AI