HITRUST AI Security Certification Guide

Healthcare and enterprise buyers increasingly ask AI vendors for independent proof that a deployed AI system is secure, and a general security certificate does not answer that question. The HITRUST AI Security Assessment and Certification is one answer: a set of AI-specific security controls, assessed by an external assessor and quality-reviewed by HITRUST, that can stand alone or sit on top of an e1, i1 or r2 assessment. This guide explains what HITRUST has published about it, how it is structured, how to scope and prepare an AI system, and how it relates to ISO/IEC 42001, the NIST AI RMF and the OWASP Top 10 for LLM Applications. It is written for security and compliance leads at AI providers and for third-party risk teams reading the reports. Facts about the product come from HITRUST's own pages, checked on 27 October 2026; HITRUST updates its control sets, so confirm current details in MyCSF before planning.

Key takeaways

It certifies deployed AI systems, not AI governance. HITRUST positions the AI Security Assessment as proving whether AI systems are secure, while ISO/IEC 42001 addresses how AI is governed through a management system.
It is an add-on or a standalone. HITRUST says it can be pursued on its own or combined with an e1, i1 or r2 assessment, and that the certification period is one or two years depending on the assessment selected.
The control set is small and tailorable. HITRUST's comparison blog describes 44 AI security controls that can be tailored to use-case scenarios; the separate, non-certifiable AI Risk Management Assessment has 51 controls.
Inheritance matters. Controls validated at a HITRUST-certified AI or cloud provider can be inherited, which reduces effort for the application built on top.
Machine identities are central. An AI system is driven by API keys, service accounts, model endpoints and agent tool credentials; expect assessors to test how these are issued, scoped, rotated and logged.

What it is and who it applies to

HITRUST announced the AI Security Assessment with Certification as generally available on 19 November 2024, after unveiling it at HITRUST Collaborate 2024. The press release describes it as a prescriptive control specification for AI platforms and deployed systems, developed with industry working groups and an open request-for-comment process. HITRUST also launched the AI Risk Management Assessment in August 2024; the two are separate products.

Attribute	AI Security Assessment and Certification	AI Risk Management Assessment
Purpose	Secure and certify deployed AI systems	Explore AI risks and governance gaps
Controls (per HITRUST pages)	44 AI security controls, tailorable	51 controls aligned with ISO and NIST
Outcome	HITRUST AI certification after external assessment and HITRUST review	Not certified; self-evaluation allowed
Combination	Standalone or with e1, i1 or r2	Separate assessment
Best fit	Vendors who must show assurance to customers, regulators, insurers	Organisations early in AI adoption

Who asks for it: HITRUST names AI system and platform providers across industries, organisations building applications on AI subsystems, and the TPRM, procurement, legal and executive teams that review vendor AI assurance. Healthcare is the obvious market because HITRUST is already common in health supply chains, but the product is not limited to healthcare. HITRUST lists generative AI, agentic AI and machine learning among the system types it addresses.

Structure and key requirements

The certification uses the standard HITRUST assurance mechanics; only the control content is AI-specific.

Base assessment choice: e1 (43 core controls, one-year validity), i1 (182 control requirements, one year) or r2 (risk-based, two years), as described on HITRUST's pages. The AI controls are added to that scope or assessed alone.
Harmonised framework: HITRUST says its AI controls align with AI security elements from NIST, ISO/IEC and OWASP, and that its shared framework reflects ISO/IEC 23894:2023 and the NIST AI RMF.
Threat-adaptive updates: HITRUST says it updates control sets as AI threats evolve, using threat intelligence. Plan for the control set to change between your certifications.
Testing definitions: the press release refers to defined measurement, testing and validation criteria, third-party external assessment, and centralised HITRUST quality review, scoring and award.
Platform: assessments run in HITRUST's MyCSF platform; results are shared through its results distribution system.
Inheritance: Inherited Security Controls let customers rely on controls already validated at a HITRUST-certified AI or cloud provider.

HITRUST's public pages do not list the individual AI control statements. The authoritative text is the control set inside MyCSF for the CSF version you assess against. The themes below are the areas any AI security control set must cover; use them to prepare, then reconcile against the actual requirements.

Control theme	What an assessor will want to see	Related OWASP LLM 2025 risk
AI system inventory and scoping	Models, versions, endpoints, data stores, agents and tools in scope	LLM03 Supply Chain
Input and output protections	Filtering, output handling before use by downstream systems	LLM01 Prompt Injection; LLM05 Improper Output Handling
Data protection	Training and retrieval data classification, sensitive data leakage controls	LLM02 Sensitive Information Disclosure; LLM08 Vector and Embedding Weaknesses
Model and data integrity	Provenance of models and datasets, change control	LLM04 Data and Model Poisoning
Agent permissions	Tool scopes, approval steps for high-impact actions	LLM06 Excessive Agency
Prompt and configuration secrecy	No secrets in system prompts, protected configuration	LLM07 System Prompt Leakage
Resource controls	Rate limits, quotas, cost alerts	LLM10 Unbounded Consumption
Logging and monitoring	Per-request logs tied to identities, anomaly alerting	Cross-cutting

The OWASP column is NHI Mgmt Group's mapping for preparation, not a HITRUST mapping. See the OWASP Top 10 for LLM Applications Guide.

Identity and NHI requirements

Deployed AI systems authenticate almost entirely as machines. Before assessment, make the following explicit, because these are where AI evidence most often falls short.

Model provider credentials: API keys for hosted model services should live in a secrets manager, be scoped per environment and rotated on a schedule. Prefer workload identity federation where the provider supports it. See the Cloud Secrets Managers Guide.
Agent tool credentials: each agent should act under its own identity with least-privilege scopes for each tool, not under a shared integration account. See the Agentic AI Identity Guide.
Retrieval data access: the retrieval service account should not read more than the requesting user may see; enforce document-level permissions at query time.
Pipeline identities: CI/CD and training pipelines that push models need signed artefacts and separate identities from runtime.
Logging attribution: logs must show which identity (human, service, agent) triggered each model call and tool action.
Ownership: every NHI in scope has a named owner and a decommissioning trigger. See the NHI Ownership Guide.

Implementation steps

Decide the combination: standalone if you already hold a HITRUST certificate for the platform; add-on to e1 for a first certification with modest scope; add-on to r2 where customers already demand r2.
Define the AI system boundary: list models, hosting, data sources, vector stores, agents, tools, interfaces and the people and NHIs that operate them. Exclude what you cannot evidence and say so.
Identify inheritance: check whether your cloud or model provider has HITRUST-certified systems whose controls you can inherit, and request inheritance in MyCSF.
Run a readiness assessment: self-score against the AI controls in MyCSF; treat gaps in identity, logging and agent permissions first.
Remediate in a pilot environment: introduce input/output controls, secret rotation and agent scope reductions behind feature flags so you can roll back if model quality or latency degrades.
Collect evidence for operation: configuration alone rarely suffices for the higher assessments; gather logs, tickets and test results over the required period.
Engage an authorised external assessor: agree sampling and test approach for AI-specific controls early, since these are newer for assessors too.
Submit for HITRUST quality review: respond promptly to queries; delays here extend the timeline.
Maintain: track control set updates, change management for new models and agents, and interim obligations of the base assessment.

Choosing the base

Situation	Sensible choice	Trade-off
Start-up AI vendor, first enterprise deals	AI Security plus e1	Lower effort; some buyers will still want i1 or r2
Established health-tech vendor with i1	AI Security added to i1	Reuses existing evidence; one-year cycle
Vendor with r2 demanded by payers or providers	AI Security added to r2	Highest effort; two-year validity
AI platform already HITRUST certified elsewhere	Standalone AI Security	Fast; relies on clear boundary with the other certificate

Evidence and assessment

Policies and procedures: AI acceptable use, model change management, data handling for prompts and outputs.
Configuration evidence: secrets manager entries and rotation settings, agent tool scopes, rate limits, guardrail configuration.
Operational evidence: logs showing per-identity model and tool calls, alerts raised and handled, rotation events.
Test evidence: adversarial and prompt-injection testing results with remediation records. See the Prompt Injection Guide.
Supply chain evidence: model and dataset provenance, model cards, AI-BOM where you maintain one. See the AI Supply Chain and AI-BOM Guide.

Metrics that show the programme works

Percentage of AI-system NHIs with an owner and a rotation date inside policy.
Number of agents with tool scopes reviewed in the last quarter.
Prompt-injection test findings open beyond their remediation target.
Percentage of model and tool calls attributable to a distinct identity in logs.
Inherited controls as a share of total in-scope AI controls.

Timeline expectations

HITRUST does not publish a fixed duration for the AI add-on. In practice, readiness and remediation dominate: an organisation with mature secrets management, per-agent identities and complete logging can move straight to external assessment, while one running shared API keys and unscoped agents needs months of engineering first. Build the plan backwards from the customer deadline, allowing time for the assessor's fieldwork and HITRUST's quality review, and do not schedule fieldwork during a major model migration, because evidence collected on the old architecture may not describe the system you then certify.

Mapping to other frameworks

Framework	Relationship	Practical use
ISO/IEC 42001	HITRUST calls it complementary: management-system governance versus technical security of deployed systems	Hold both where buyers want governance and system assurance. See the ISO/IEC 42001 Guide
ISO/IEC 23894:2023	Reflected in HITRUST's harmonised framework, per HITRUST	Risk method behind control selection
NIST AI RMF 1.0	Reflected in the harmonised framework, per HITRUST	Govern, Map, Measure, Manage functions frame the risk programme. See the NIST AI RMF Guide
OWASP Top 10 for LLM Applications 2025	OWASP named among aligned sources	Threat checklist for testing
NIST CSF 2.0	Not a stated mapping	PR.AA-01, PR.AA-05 and PR.PS-04 cover the identity and logging evidence above
MITRE ATLAS	Not mentioned by HITRUST	Use for adversarial test planning. See the MITRE ATLAS Guide

Reading a vendor's AI certification as a buyer

Third-party risk teams receiving a HITRUST AI certificate should check five things before relying on it:

Scope statement: does the certified AI system match the product and deployment you are buying, including the agent features and integrations you will enable?
Base assessment: was it paired with e1, i1 or r2, or standalone? A standalone AI certificate says little about the vendor's general security hygiene unless another certificate covers it.
Dates: issue and expiry, and whether material model or architecture changes have happened since.
Inherited controls: which controls rest on a model or cloud provider, and whether that provider's certification is current.
Your residual responsibilities: controls the vendor expects you to operate, such as configuring data access, user permissions and logging retention in your tenant.

Combine the certificate with your own questions on data retention for prompts and outputs, model training on customer data, and how the vendor revokes credentials if an agent misbehaves. See the AI Agent Tool and Plugin Security Guide for the agent-side questions.

Common pitfalls

Treating HITRUST CSF certification as AI coverage: a base e1, i1 or r2 does not address AI-specific threats; buyers asking for AI assurance want the AI controls.
A boundary that excludes the agents: scoping only the model endpoint while agents with broad tool permissions sit outside the certificate.
Shared API keys: one model provider key used by every service, so logs cannot attribute calls and revocation breaks everything.
Assuming inheritance covers your configuration: a provider's certified controls do not cover how you configure guardrails, data access or prompts.
Ignoring control set updates: HITRUST adapts the controls to new threats; a programme built against last year's set may have gaps at recertification.
Confusing the two AI products: the 51-control AI Risk Management Assessment is not a certification.

Practitioner checklist

Confirm with customers whether they need the AI Security certification, a base HITRUST certificate, ISO/IEC 42001, or a combination.
Choose standalone or add-on to e1, i1 or r2, and note the resulting validity period.
Document the AI system boundary, including agents, tools and retrieval sources.
Identify inheritable controls from certified providers.
Inventory every NHI in scope with an owner, scopes and rotation schedule.
Run adversarial testing against the OWASP LLM risks and record remediation.
Ensure logs attribute each model call and tool action to a distinct identity.
Track HITRUST control set updates and plan for change before recertification.

HITRUST AI Security Certification Guide: Scope, Controls and Preparation