HITRUST AI Security Assessment and Certification Specification

Verification of origin and integrity of AI assets

HITRUST CSF requirement statement [?] (07.10mAISecOrganizational.2)

To help ensure that unsafe assets are not introduced into the AI system, the 
organization checks the cryptographic hashes and/or digital signatures on downloaded AI
(1) models; 
(2) software packages (e.g., those for model creation, training, and/or deployment); 
(3) datasets (e.g., training datasets); and
(4) language model tools (e.g., agents, plugins)
before use, as applicable.

Evaluative elements in this requirement statement [?]
1. To help ensure that unsafe assets are not introduced into the AI system, the 
organization checks the cryptographic hashes and/or digital signatures on downloaded 
AI models before use, if applicable.
2. To help ensure that unsafe assets are not introduced into the AI system, the 
organization checks the cryptographic hashes and/or digital signatures on 
downloaded AI software packages (e.g., those used for model creation, training, and/or 
deployment) before use, if applicable.
3. To help ensure that unsafe assets are not introduced into the AI system, the 
organization checks the cryptographic hashes and/or digital signatures on 
downloaded AI datasets (e.g., training datasets) before use, if applicable.
4. To help ensure that unsafe assets are not introduced into the AI system, the 
organization checks the cryptographic hashes and/or digital signatures on 
downloaded language model tools (e.g., agents, plugins) before use, if applicable.


Illustrative procedures for use during assessments [?]

  • Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.

  • Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.

  • Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample based test where possible for each evaluative element. Example test(s):
    • For example, review the AI system to ensure the organization verifies the cryptographic hashes and/or digital signatures on downloaded AI models, software packages (e.g., those for model creation, training, and/or deployment), datasets (e.g., training datasets), and language model tools (e.g., agents, plugins) before use, as applicable.

  • Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
    • For example, measures indicate if the organization verifies the cryptographic hashes and/or digital signatures on downloaded AI models, software packages (e.g., those for model creation, training, and/or deployment), datasets (e.g., training datasets), and language model tools (e.g., agents, plugins) before use, as applicable.

  • Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.

Placement of this requirement in the HITRUST CSF [?]

  • Assessment domain: 07 Vulnerability Management
  • Control category: 10.0 – Information Systems Acquisition, Development, and Maintenance
  • Control reference: 10.m – Control of Technical Vulnerabilities

Specific to which parts of the overall AI system? [?]
AI application layer:
  • AI plugins and agents
AI platform layer:
  • The deployed AI model
  • Model engineering environment and model pipeline
  • AI datasets and data pipelines

Discussed in which authoritative AI security sources? [?]

Discussed in which commercial AI security sources? [?]

  • Databricks AI Security Framework
    Sept. 2024, © Databricks
    • Where:
      • DASF 10: Version data
      • DASF 11: Capture and view data lineage
      • DASF 22: Build models with all representative, accurate and relevant data sources to minimize third-party dependencies for models and data where possible
      • DASF 27: Pretrain a large language model (LLM) on your own IP
      • DASF 53: Third-party library control
      • DASF 42: Data-centric MLOps and LLMOps promote models as code using CI/CD.

  • Snowflake AI Security Framework
    2024, © Snowflake Inc.
    • Where:
      • Model poisoning > Mitigations > Bullet 1
      • Self-hosted OSS LLMs Security > Mitigations > Cryptographic signing

Control functions against which AI security threats? [?]
Additional information
  • Q: When will this requirement included in an assessment? [?]
    • This requirement will always be added to HITRUST assessments which include the
      Security for AI systems regulatory factor.
    • No other assessment tailoring factors affect this requirement.

  • Q: Will this requirement be externally inheritable? [?] [?]
    • Yes, fully. This requirement may be the sole responsibility of the AI platform provider and/or model creator. Or, depending on the AI system’s architecture, only evaluative elements that are the sole responsibility of the AI platform provider and/or model creator apply.