EVIDENCE TRAIL
Data classification with tool-access allow-lists
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The title "data classification with tool-access allow-lists" is Helmwart's normalised label for a control that spans NIST SP 800-60 impact categorisation, NIST SP 800-53 AC-4 information flow enforcement, and the OWASP AI Exchange least-model-privilege principle. No single upstream source covers all three dimensions; the combination is Helmwart's composition.
Last cross-checked against upstream sources: · 7 sources
References
Each entry shows what the source supports and what it does not prove.
NIST SP 800-60 Volume I, Revision 1 — Guide for Mapping Types of Information and Information Systems to Security Categories
§1.0 Introduction
"The identification of information processed on an information system is essential to the proper selection of security controls and ensuring the confidentiality, integrity, and availability of the system and its information."
Supports: States categorisation of information as a prerequisite for selecting security controls — the upstream rationale for why data-classification tags must precede access-control decisions in any system, including agentic ones.
Does not prove: Predates agentic AI by 15+ years. Does not address per-tool or per-agent allow-lists. The federal classification framework (low / moderate / high) maps to impact levels, not directly to the public / internal / confidential / restricted labels common in commercial deployments.
NIST SP 800-60 Volume I, Revision 1 — FIPS 199 Categorisation Criteria (Table 7)
§4.2.1 FIPS 199 Security Categorization Criteria — Table 7: Categorization of Federal Information and Information Systems (Confidentiality row)
"The unauthorized disclosure of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. [LOW] … a serious adverse effect … [MODERATE] … a severe or catastrophic adverse effect … [HIGH]"
Supports: Defines the three-tier impact scale (low / moderate / high) that is the federal canonical basis for classification labels. Establishes that confidentiality impact determines the protective regime applied to each information type — exactly the property that per-tool allow-lists enforce at the retrieval seam.
Does not prove: Defines impact thresholds for federal systems; commercial deployments must author their own label-to-tier mappings. Does not prescribe how enforcement is implemented at runtime.
NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
Control AC-4 INFORMATION FLOW ENFORCEMENT — Control statement and opening Discussion paragraph
"Enforce approved authorizations for controlling the flow of information within the system and between connected systems based on [Assignment: organization-defined information flow control policies]. … Information flow control regulates where information can travel within a system and between systems (in contrast to who is allowed to access the information) and without regard to subsequent accesses to that information."
Supports: AC-4 is the canonical NIST control for classification-driven flow enforcement. The explicit contrast — "where information can travel … in contrast to who is allowed to access the information" — names the data-side scope this mitigation adds on top of role-based access control. The assignment parameter maps directly to per-tool allow-list policies.
Does not prove: Does not mention agents, LLMs, or retrieval-augmented generation. The "connected systems" framing is network/boundary-centric; Helmwart applies the same principle at the vector-store retrieval seam and MCP tool boundary.
OWASP AI Exchange — General Controls
§General Controls — #DATA MINIMIZE
"Data minimize: remove data fields or records (e.g. from a training set) that are unnecessary for the application, in order to prevent potential data leaks or manipulation because we cannot leak what isn't there in the first place"
Supports: States the foundational principle underlying classification-based allow-lists: the safest way to prevent leakage of a data class is to ensure agents that do not need it cannot reach it. "We cannot leak what isn't there" is the data-side analogue to least-privilege.
Does not prove: The DATA MINIMIZE control targets training-set reduction, not runtime retrieval allow-lists. Applying it to inference-time retrieval seams is Helmwart's extension of the principle, not the control's literal scope.
OWASP AI Exchange — General Controls
§General Controls — #LEAST MODEL PRIVILEGE
"Least model privilege: Minimize what a model can do (trigger actions or access data), to prevent harm in case the model is manipulated, or makes a mistake by itself."
Supports: Names "access data" explicitly as a dimension of model privilege alongside "trigger actions" — the two axes this mitigation restricts separately (role-side via RBAC, data-side via classification allow-lists). The manipulation / mistake framing matches T2 Tool Misuse and T15 Human Manipulation threat scenarios directly.
Does not prove: Does not specify classification tiers, label schemas, or retrieval-filter mechanics. "Minimize" is directional guidance, not a normative standard with prescribed implementation.
MITRE ATLAS AML.M0019 — Control Access to AI Models and Data in Production
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Names restricting access to AI models and the data they consume in production as a named mitigation — the production-deployment framing of the allow-list principle. Directly cited in the MDX independentEvidence field.
Does not prove: Live URL returns 404 at time of cross-check (2026-05-29); verbatim excerpt could not be retrieved. No fabrication. The mitigation ID and name are drawn from the MDX frontmatter atlasMitigations list, which was authored against a prior-version catalogue.
MITRE ATLAS AML.M0026 — Privileged AI Agent Permissions Configuration
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Names agent-level permission scoping as a dedicated mitigation — the agent-permissions framing that per-tool, per-agent allow-lists implement. Cross-referenced in the MDX frontmatter atlasMitigations list alongside AML.M0019.
Does not prove: Live URL returns 404 at time of cross-check (2026-05-29); verbatim excerpt could not be retrieved. No fabrication.