What the HITRUST AI security certification asks an AI system to prove
A customer or regulator asking for evidence that a deployed AI system is secured usually wants proof that the system's controls hold up in operation, not only that a policy exists. The HITRUST AI security certification answers that request with ai1 when combined with an e1 or i1, and ai2 when combined with an r2. It adds AI-specific requirement statements on top of the base assessment, so the system is tested for risks that a conventional application assessment does not cover. HITRUST states that the certification can also be pursued as a standalone certification, so confirm with your assessor which route fits the request in front of you. The risks these statements target are the ones that make AI systems different to scope. Prompt injection can redirect a model's behavior through user input or retrieved content. Data leakage can expose training data, system prompts or information from other users. Unsafe tool use occurs when a model can call functions, APIs or downstream systems with more authority than its task needs. Model misuse covers outputs that are used beyond their intended purpose. These risks cross the boundary between application, data pipeline, model provider and third-party service, which is why the first scoping question is usually which components, prompts, retrieval sources and tools belong inside the assessed system.
To pass, the AI security requirement statements have to reach a minimum average score. In ai1 that average must be at least 83, and in ai2 it must be at least 62. As of CSF v11.4.0, the certification added up to 44 AI-specific requirement statements to an e1, i1 or r2, and the exact number is set by tailoring questions, so your scope answers determine how much work the AI component adds. CSF v11.9.0 added an Agentic AI selectable factor for systems where a model plans and acts across tools, which matters if your system takes actions rather than only producing text. Check the current selectable factors and version details in the HITRUST AI Security Assessment help page before you agree a scope. HITRUST issues the certification, and only an authorized HITRUST External Assessor can perform the validated assessment that supports it. DeployOpen does not issue reports or certificates. Its role, where engaged, is to prepare the system, controls and evidence for that assessor, such as logging, access records and test results. Before you commit, ask your assessor how they will sample AI-specific evidence, which system boundary they will accept, and what documentation they expect for model and tool inventories.
Which AI systems, data and third parties fall in scope
The AI Security Certification adds AI-specific requirement statements to an e1, i1 or r2, or stands alone. The scope decisions below determine which systems are assessed, how many statements apply and who must produce the evidence.
Deployed systems and model endpoints
Start by listing every AI system in production or in a pilot that serves real users or data, along with each model endpoint it calls. Include internal tools, customer-facing features and batch jobs that score records. Document the owner, the hosting location and the version of each model. An endpoint left off the inventory is usually discovered during fieldwork, when it can delay the validated assessment window.
Retrieval data and knowledge sources
Decide whether vector stores, document indexes and search connectors that feed prompts are in scope. These sources often hold regulated data and carry access rules that differ from the source system. Confirm with your assessor how retrieved content is classified, who can change indexed material and how deletions propagate to the index.
Agent tools and actions
Agents that call APIs, write to databases or send messages extend the attack surface beyond the model. List each tool an agent can invoke, the permissions it runs under and whether a human approves high-impact actions. Since CSF v11.9.0 added an Agentic AI selectable factor, confirm with your assessor whether your agents trigger it.
Vendor-hosted models and third parties
Decide how externally hosted models, managed AI APIs and labeling vendors are handled. Some controls may be inherited from a provider's own HITRUST or SOC 2 results, while others remain your responsibility, such as prompt handling and output filtering. Gather each provider's shared responsibility documentation before scoping, and record which statements rely on it.
Ownership of prompts and evaluations
Name the team that owns each system prompt, guardrail rule and evaluation suite. Security, data science and product teams often each hold part of the control, and gaps appear where none of them owns it. Assign an accountable owner to each control, define who approves prompt changes and keep a dated record of evaluation runs that assessors can sample.
Tailoring sets the statement count
The AI-specific statements are not a fixed block. Tailoring questions determine how many apply to your environment, with up to 44 statements added to an e1, i1 or r2 as of CSF v11.4.0. Answer the questions against your written inventory, not your intentions, and keep the answers with the scope document so the count can be defended.
How an authorized assessor tests AI security controls
This table compares the areas an authorized External Assessor examines for AI security certification, the evidence it typically requests and the findings that most often stall fieldwork. Read it as a preparation checklist: each row names an area where your evidence must show both design and operation. Fieldwork runs at most 90 days, and HITRUST performs quality assurance before any report is issued.
| Test area | Evidence the assessor typically requests | Common findings |
|---|---|---|
| System inventory and scope | Current register of AI systems in scope, data flows, model and provider dependencies, and the tailoring answers that set the AI statement count | Shadow AI tools missing from the inventory, or systems in production that were never scoped into the assessment |
| Access control to models and tools | Role assignments for model endpoints, prompt stores, vector databases and agent tool permissions, plus access review records | Shared API keys, service accounts with broad tool permissions, or no review of who can change model configurations |
| Input and output handling | Documented input validation and output filtering rules, sample test cases and results showing how they behave on malicious or malformed inputs | Rules described in design documents but not tested, or outputs passed to downstream systems without any control |
| Testing evidence, including adversarial and red team results | Test plans, scope, tool configurations, raw results and records showing findings were triaged and remediated before the assessment | Testing performed once with no defined scope, results without remediation tracking, or no coverage of agentic or tool-use behavior |
| Logging and monitoring | Samples of logs for model calls, retrieval steps and tool executions, alert rules and evidence that someone reviewed alerts | Logs that omit prompts, outputs or tool actions, retention periods that are undocumented, or alerts with no documented response |
| Change management for models and prompts | Version history for models, prompts and system instructions, approval records, rollback procedures and re-testing after material changes | Prompt edits made directly in production, no link between a model change and new security testing, or no record of who approved the change |
| Governance and ownership | Named owners for each AI system, risk acceptance records and policies that cover acceptable AI use | Ownership assigned to a team that does not operate the system, or risk accepted without a documented decision |
How to implement AI security controls before the validated assessment
This sequence turns an AI system into a bounded, tested and traceable scope that an assessor can evaluate under the ai1 or ai2 requirement statements. Each step produces a record that feeds the next one, so the validated assessment starts from evidence rather than reconstruction.
Define the AI system boundary
Name the AI system that falls under the certification, including the application, the model endpoints it calls, the users and the business process it supports. Decide which components sit inside the boundary and which are inherited from a provider. The security or platform lead owns this decision, with input from the product owner and data owner. The step is done when a signed boundary statement lists every in-scope component and every excluded component with a reason, so an assessor can trace each requirement statement back to a named system.
Inventory models, data sources and tools
Build a register of every model, prompt template, retrieval index, training or fine-tuning dataset, plugin, tool connector and external API the system uses. Record the owner, hosting location, version, data classification and whether the component is self-hosted or consumed as a service. For self-hosted open-source components, record the exact version and the source of the artifact. The output is a system inventory that serves as the basis for every later mapping and for the tailoring questions that set the AI requirement statements.
Map existing e1, i1 or r2 controls to the AI system
Take the baseline you already certify against (e1, i1 or r2) and determine which controls apply to the AI system's infrastructure, identity, data protection, logging and change management. Many of these controls extend to the AI components without change, while others need a new implementation note. Confirm with your assessor how the AI system's scope interacts with the parent assessment, since the ai1 or ai2 add-on is taken together with an e1, i1 or r2. The output is a tailored scope record that shows each parent control, its owner and the AI components it covers.
Add AI-specific controls for inputs, tools and outputs
Implement controls targeted at the risks the AI requirement statements address: input validation and prompt handling, least-privilege access for every tool and connector the model can call, human approval for consequential actions, and output filtering before responses reach users or downstream systems. For the Agentic AI selectable factor added in CSF v11.9.0, document how agents are limited in actions and credentials. Each control needs a configuration record, a named owner and a test case. Confirm with the assessor which selectable factors apply to your system before building beyond the baseline.
Run and record AI security testing
Test the system against the threats the scope identifies, including prompt injection, jailbreaks, data leakage, toxicity and hallucination. Open-source probes such as garak (Apache-2.0) can exercise language models for these categories and write a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a weakness. Testing should be performed by someone independent of the team that built the controls where practical. The output is a dated test report with each finding, its severity, the remediation ticket and the retest result, which becomes evidence for the assessor.
Remediate findings and retest
Triage each finding from the test report, assign it to an owner, and fix it in the affected component or document a compensating control with its residual risk. Retest the same probes after the change to confirm the weakness is closed and that the fix has not broken an earlier control. Keep the before and after records together so an assessor can follow the path from finding to closure. The step is complete when no open finding lacks an owner, a decision and a retest result, and the decision log is kept under change management.
Set up tracing and logging baseline
Instrument the AI system so each request can be reconstructed end to end. Open-source tracing tools such as Langfuse (MIT) capture each trace with its LLM calls, retrieval steps, tool executions and custom logic, including timing, inputs, outputs, token usage and metadata. Decide what is logged, how long it is retained, who can access it and how sensitive content is masked. Verify that logs are forwarded to your central logging platform and that tampering is detectable. The output is a logging baseline document and a sample trace set that demonstrates each control working as designed.
Assemble the evidence pack for the assessor
Gather the boundary statement, system inventory, tailored scope record, control implementation records, test reports, remediation log and logging baseline into one indexed evidence pack keyed to the requirement statements. Check that each piece is dated, versioned and owned, and that the sampling population an assessor would draw from is complete. Your internal reviewer should walk the pack against the requirement statements before the assessor arrives. Your implementation partner can prepare this pack, but only the independent HITRUST External Assessor performs the validated assessment and HITRUST issues the certification.
How security testing produces evidence for AI statements
For AI security statements, testing results carry most of the weight. A written policy that says a model resists prompt injection tells an assessor what the organization intends, but it does not show that the model resists injection. Assessors expect recorded test activity that ties each AI requirement statement to something that was run, what it found and what was done about it. The organization owns that evidence, and an implementation partner can help set up the tooling and collection, but only the independent HITRUST External Assessor reviews it and decides whether it is sufficient.
The evidence usually falls into four kinds. The first is attempt logs from a probing tool, showing which adversarial prompts were sent and how the system responded. garak, an Apache-2.0 scanner, writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. The second is that hit log itself, which assessors read closely because it shows the failures the team knew about. The third is remediation records linking each hit to a fix, a retest and an owner. The fourth is trace records of production or staging calls. Langfuse, an MIT-licensed tool, captures timing, inputs, outputs, token usage and metadata for each operation, including LLM calls, retrieval steps and tool executions. Treat both tools as examples. Confirm with your assessor that their file formats, retention periods and sampling approach fit your environment and the evidence windows in your assessment.
Plan the evidence before the fieldwork window opens, not during it. Decide which AI systems fall in scope, which agentic tool calls the Agentic AI selectable factor covers, and where logs are stored, who can alter them and how long they are kept. Confirm that a single test run can be traced to a model version, a configuration and a date, because a retest after a model change will need its own record. The reader should also ask the assessor, in writing, which artifacts they will sample and whether they accept scanner output as is or need it reproduced under controlled conditions.
Evidence artifacts that satisfy AI security statements
An AI security assessment is only as credible as the records behind it. The six artifacts below are the ones assessors most often ask to see, and each one needs an owner and a refresh routine so it still reflects the deployed system when the validated assessment is submitted and again before renewal.
AI system inventory and scope record
This is the register of every AI system in scope, with its owner, purpose, data classes, hosting location, model sources and the boundary where the certification applies. Assessors use it to confirm that the systems they test are the systems you run. Between assessments, tie each entry to change tickets so new models, endpoints or agents are added the day they go live, and review the register at each release. Confirm with your assessor how they expect scope changes to be recorded.
Model and prompt change records
Each change to a model version, fine-tuned weight set, system prompt, retrieval source or safety configuration should have a dated record showing what changed, who approved it and what testing ran before release. Assessors compare these records with the versions observed during fieldwork. Store prompts and configurations in version control so the history is reproducible, and make approval a required step in your pipeline rather than a manual reminder.
Adversarial and red team test reports with hit logs
Adversarial test reports show which attack categories were run against each model or application, how often they succeeded and what was fixed. Open-source probe tools such as garak write a full attempt log and a separate hit log of successful attacks, and those files are the raw evidence assessors want. Rerun the same probe set after every material model or prompt change, and keep the reports from each run so you can show trend lines rather than a single snapshot.
Trace and log samples showing operations and tool use
Traces show what the AI system actually did for a given request: model calls, retrieval steps, tool executions and the inputs and outputs of each. Assessors use sampled traces to confirm that tool use and data access match the approved design. Observability platforms such as Langfuse can capture this per request, so keep a dated sample set from production or a representative environment, and confirm your retention period and redaction rules with your assessor before you rely on them.
Access control reviews for model endpoints and tools
Access reviews list who and which service identities can call each model endpoint, invoke each agent tool and read each retrieval source, then record the approval and the outcome of the review. Assessors check that privileged access is limited and that stale accounts and API keys are removed. Run the review on a fixed schedule and after staff or integration changes, and include service accounts and machine credentials, since they are often the largest gap.
Remediation tickets
Every finding from adversarial testing, trace review or access review should have a ticket that records the root cause, the fix, the retest result and the closure approval. Assessors look for a clear path from finding to verified fix, and for findings that were accepted with a documented rationale. Link each ticket to the test report or log that raised it, and review open items before each release so that no known issue carries into a validated assessment unexplained.
What meeting the AI security certification costs
This table compares the cost components of an ai1 or ai2 pursuit, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No fees or durations are stated because none were supplied, so use the rows to build the scope you request from assessors and advisers. The main takeaway is that the assessor fee is only one part of total spend, and the internal engineering and testing work often carries more of the effort.
| Cost component | Who is paid or who bears it | One-time or recurring, and what drives it |
|---|---|---|
| Assessor fees for the validated AI security assessment | Authorized HITRUST External Assessor organization | Mostly one-time per assessment cycle. Driven by the number of AI systems in scope and the tailoring result. Ask the assessor to price each AI system separately. |
| HITRUST licensing for MyCSF | HITRUST, through a MyCSF subscription | Confirm with HITRUST whether this recurs and at what tier. Driven by the number of users and the assessment type you combine with ai1 or ai2. |
| Internal engineering time for AI controls and evidence tracing | Your own staff, or an implementation partner under a written scope | One-time build, then recurring upkeep. Driven by the number of models, prompts, retrieval sources and agent tools that need traceable controls. |
| Recurring AI security testing | Your internal red team, a testing provider or a partner | Recurring. Driven by release frequency and the number of agentic workflows. Garak-style probing and trace review can reduce spend on tooling but still need skilled operators. |
| Evidence upkeep between assessments | Your compliance and engineering teams | Recurring. Driven by log retention, change records for model and prompt versions, and how often you rotate evidence for AI-specific statements. |
| Remediation of gaps found in readiness or assessment | Your engineering teams, plus any vendor used for fixes | One-time per gap cycle, but gaps can recur after a CSF version update. Driven by the number of statements below the required average and the complexity of fixes. |
| Open-source tooling for evidence | Usually no license fee for self-hosted tools such as garak (Apache-2.0) or Langfuse (MIT) | Infrastructure and staff time remain. Self-hosting removes license spend but not hosting, storage or operating effort. |
Open-source tools that produce AI security evidence
garak is an Apache-2.0 licensed scanner that probes language models for weaknesses such as prompt injection, data leakage, hallucination, misinformation, toxicity generation and jailbreaks. For an AI security assessment, its value is repeatable testing evidence: you can show which probes were run against which model configuration, what the model returned, and where a vulnerability was found. Results are written as a JSONL report that records every attempt and its evaluation, along with a hit log of the attempts that succeeded.
- Attempt and evaluation report: A JSONL file lists every probe attempt and its evaluation, which supports a claim that testing covered the stated categories rather than a sample chosen after the fact.
- Hit log: A separate log of attempts that found a vulnerability gives you a starting list for remediation tickets and retest records.
- Repeatable runs: Recording the model name, version, configuration and run date alongside each report lets an assessor compare results before and after a change.
- Prompt injection and jailbreak coverage: These probe families map directly to the adversarial testing questions in the AI security requirement statements.
- Limits: A probe run is a point-in-time sample. It does not prove that a model is free of a weakness, and it does not test your application's tools, data stores or authorization logic.
Confirm the installed version, the probe families you intend to run, and the Apache-2.0 license terms that apply to your build and any bundled dependencies before you rely on the output in an assessment.
Langfuse is an MIT-licensed observability platform for LLM applications. Its traces capture each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, along with timing, inputs, outputs, token usage and metadata. For an assessor, this answers a different question from probing: what the deployed system actually did with a given request, which tools it invoked, and what data passed through each step.
- Step-level traces: Each trace shows the sequence of LLM calls, retrievals and tool executions for one request, which supports reviewing agent or workflow behavior.
- Inputs and outputs: Recorded prompts and responses let you check whether controls such as input filtering or output handling were applied in production.
- Token and timing metadata: Usage and latency data support capacity reviews and help spot unusual request patterns during monitoring.
- Custom spans: Your own authorization or policy checks can be recorded as spans, so their outcomes appear in the same trace.
- Limits: Traces show what happened, not whether it was allowed. Logged prompts can also contain personal or confidential data, so retention, access and masking decisions must be made deliberately.
Confirm how your deployment stores and protects trace data, including retention, redaction and access roles, and check the MIT license terms and the self-hosting setup against your own environment.
The two tools are most useful together. Probing shows whether a model or application is vulnerable under test conditions, and tracing shows how the same system behaves when real requests arrive. An assessor reviewing AI security evidence typically wants both a controlled test record and an operational record that links back to the tested configuration. This tab covers how the outputs connect, not what either tool guarantees on its own.
- Shared configuration identifiers: Tag garak runs and Langfuse traces with the same model, prompt template and release identifiers so results can be matched.
- Retest after remediation: Use the hit log from a failed run to define a retest, then confirm in traces that the fixed behavior is what production now does.
- Change records: Store reports and trace exports with the change ticket that introduced a new model or prompt, which ties evidence to the configuration it covers.
- Evidence packaging: Keep the raw JSONL and trace exports under your own retention policy, and write a short index that explains what each file shows.
- Scope gaps: Neither output replaces a risk assessment, access review or governance evidence that the AI security requirement statements also expect.
Confirm with your assessor which evidence formats and retention periods they accept, and which of the requirement statements in scope they expect to see supported by testing, tracing or other records.
Where AI security assessments usually fall short
Most AI security findings trace back to a few gaps: the system is not clearly bounded, its parts are not inventoried, and its controls are not evidenced over time. Each card below names one gap, why it matters for the AI Security Certification, and the fix to put in place before fieldwork begins.
Undefined AI system boundaries
Assessors test the system the organization names, so a vague boundary makes every later control question hard to answer. Teams often leave out the retrieval index, the prompt store, the evaluation pipeline or the vendor-hosted model endpoint. Fix it by drawing one boundary diagram that lists every component in scope, the data that crosses it and the owner of each part, then confirm that the tailoring answers match that diagram.
No inventory of tools and data sources
An agent or assistant is only as safe as the tools and data it can reach, and many teams cannot list them. Plugins, connectors, vector stores and third-party APIs get added during development and never recorded. Keep a current register of each tool, data source, owner, data classification and access path, and tie every entry to a review date so the inventory stays accurate through the assessment window.
Testing done once, with no evidence trail
A single penetration test or red-team exercise before launch shows a control worked on one day, not that it keeps working. Assessors look for repeatable test runs, recorded results and tracked remediation. Schedule recurring adversarial tests for prompt injection, data leakage and jailbreaks, store each run's output with its model version, and log how each finding was closed.
Prompts and model versions changed without records
Changing a system prompt, swapping a model version or adjusting a guardrail can alter behavior that earlier testing covered. Without change records, the organization cannot show which configuration was live when a result or incident occurred. Put prompts, model identifiers and guardrail settings under version control, require a documented review before each change, and retest the affected behavior after every release.
Agent tool permissions broader than needed
Agentic systems often run with service accounts that can read, write and delete far more than a given task requires. Because the Agentic AI factor now sits in the certification, assessors will ask what each agent can do and why. Grant each tool the narrowest scope the workflow needs, separate read and write actions, require human approval for high-impact calls, and review permissions on a set schedule.
Missing logs for model calls
When a prompt is misused or an output causes harm, the organization needs a record of the request, retrieved context, tool actions and response. Many deployments log only the application's final answer. Capture each model call with timing, inputs, outputs, token use and the identity that made the call, store the logs under retention and access controls, and test that you can reconstruct a sample transaction end to end.
What buyers ask before adding AI security to a HITRUST assessment
Does AI security need its own HITRUST assessment?
No. The AI security certification is not a separate assessment you run on its own calendar. It is added to an e1, i1 or r2 assessment, and HITRUST also describes it as available as a standalone certification. The practical question is therefore which base assessment you already hold or need, and whether the AI systems in scope are part of the environment that base assessment covers. If an AI system handles regulated data but sits outside the assessed boundary, it will not be credited. Confirm the boundary with your assessor before fieldwork starts, because a boundary decision made late usually means rework in evidence collection.
How do ai1 and ai2 differ from e1, i1 and r2?
The AI security certification is called ai1 when it is combined with an e1 or i1, and ai2 when it is combined with an r2. The base assessment still tests the organization's general security program, while the AI add-on tests AI-specific requirement statements. As of CSF v11.4.0, the add-on added up to 44 AI-specific requirement statements, with the exact number set by tailoring questions. The scoring thresholds differ: AI security requirement statements must average at least 83 in ai1 and at least 62 in ai2. Expect the ai2 threshold to be lower because it sits on the more tailored r2 structure, but confirm the current thresholds for your CSF version in the Assessment Handbook before planning.
What drives the cost and effort of AI security certification?
Cost has several components: the base assessment, the AI add-on, the external assessor's fees, and your internal preparation time. The main drivers are the number of AI-specific statements the tailoring questions select, how many AI systems and model pipelines are in scope, how many third parties supply models or hosting, and how mature your existing logging and change records are. Assessor fees are paid to an Authorized HITRUST External Assessor organization, and HITRUST issues the certification after its central quality assurance, so the assessor does not issue the certificate. When you request a quote, ask for the line items separately, the number of AI statements assumed, the evidence sampling approach and what is re-performed in a later interim or recertification cycle.
How long does AI security work take and what does it need from the team?
The validated assessment fieldwork window is at most 90 days for e1, i1 and r2, according to the Assessment Handbook, but preparation usually takes longer than fieldwork and happens before it. Preparation needs an owner who can pull model inventories, access records, prompt and output logging, change approvals, and incident records for each AI system in scope. Engineers must be able to show how evidence is produced, not just where it is stored. Ask your assessor which AI evidence they expect in the first request list, and plan for at least one cycle of gap remediation. Given the 90-day fieldwork ceiling, delays are almost always caused by evidence that is missing or inconsistent, not by the assessment itself.
Can our team run AI security assessment work in-house?
Your team can prepare evidence and controls in-house, but the validated assessment itself must be performed by an Authorized HITRUST External Assessor organization, and HITRUST performs central quality assurance before issuing reports. Internal staff cannot substitute for that independent assessment. What the team can own is the control design, the AI system inventory, the logging configuration and the remediation plan. Where skills are thin, an implementation partner such as DeployOpen can plan, configure and document self-hosted tooling and evidence inside your own infrastructure. DeployOpen does not issue audit reports, attestations or certifications. Decide early which tasks are owned internally, which are outsourced to a partner, and which belong to the assessor.
How does AI security relate to NIST AI RMF and ISO 42001 work?
They overlap but answer different questions. The NIST AI Risk Management Framework is voluntary and has no certification, and ISO/IEC 42001 is an AI management system standard that can be certified by an accredited body. The AI security certification tests security requirement statements harmonized to NIST, ISO and OWASP, including the CSF v11.9.0 Agentic AI selectable factor and the OWASP Top 10 for Agentic Applications 2026 mapping. If you already run an AI risk program against the NIST AI RMF or an ISO 42001 management system, reuse its risk register, policies and ownership records as inputs, then test whether the security controls behind them can be evidenced. Confirm the mapping with HITRUST and your assessor rather than assuming it.
Which evidence tools can support AI security testing and tracing?
Two open-source tools commonly produce evidence for this work. garak, under Apache-2.0, probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability, which gives assessors a repeatable record. Langfuse, under MIT, captures traces of each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. Tools produce evidence only when retention, access control and review are defined in your own policy. Confirm how each tool is licensed and hosted in your environment before adoption, and treat tool output as one input rather than the whole control.
How DeployOpen scopes and prepares AI security evidence
The sequence below turns an AI system into a documented, tested and traceable body of evidence that an authorized HITRUST External Assessor can review. DeployOpen prepares the evidence; the assessor and HITRUST decide the outcome.
Agree a written scope before any work starts
DeployOpen and the organization define which AI systems, agents, models, data flows and hosting environments fall inside the assessment, and which parent assessment (e1, i1 or r2) the AI security certification will sit alongside. The scope names deliverables, responsibilities and the assessor the organization has selected. Work does not begin until the scope is agreed in writing, and the quote follows directly from that document. The output is a signed scope statement that both parties can measure progress against.
Map AI requirement statements to the environment
Using the scope, DeployOpen reviews which AI-specific requirement statements apply once the tailoring questions are answered, and identifies which systems, teams and documents each one touches. The organization confirms its ownership of each control, since it remains accountable for its own controls. The output is a control-to-system register that shows which owner, system and artifact answers each statement. Ask the assessor early whether they want this register in a specific format.
Prepare controls and documentation in your infrastructure
DeployOpen configures and hardens the self-hosted platforms and AI components inside the client's own cloud accounts, data centers or air-gapped networks, and updates the policies, procedures and runbooks that describe them. Access control, model and data inventories, change records and logging settings are brought to a state the organization can demonstrate. The check that closes this step is a readiness review of each in-scope control, with open gaps logged against an owner.
Test AI systems and agents for security weaknesses
DeployOpen runs security testing against the in-scope models, applications, APIs and agents, covering prompt injection, data leakage, unsafe outputs and tool misuse. Open-source probing tools such as garak can produce a JSONL record of every attempt and evaluation, plus a hit log of attempts that found a weakness. Findings are triaged with the organization, and remediation is tracked to closure. The output is a test report and a remediation log tied back to the control register.
Set up tracing and evidence collection
DeployOpen configures observability for the AI workload so that requests, retrieval steps, model calls and tool executions are recorded with timing, inputs, outputs and metadata. Langfuse is one open-source option for this, and the organization should confirm how long traces are retained and who may access them. Retention, access and redaction rules are written down so the evidence is reproducible. The check that closes this step is a sample trace review confirming that a single request can be followed end to end.
Assemble the evidence package for the assessor
DeployOpen organizes the policies, configuration records, test outputs, trace samples, training records and change history against each requirement statement, with an index that lets the assessor find each item quickly. The organization reviews the package for accuracy and confirms that every artifact reflects the environment as it actually runs. The output is a complete, indexed evidence set that the organization approves before it is released.
Hand over evidence to the authorized assessor
The organization gives the evidence package to its chosen Authorized HITRUST External Assessor, which performs the validated assessment and its fieldwork within the limits set in the HITRUST Assessment Handbook. DeployOpen answers technical questions about the systems but does not issue reports, attestations or certificates. Only the assessor's submission goes to HITRUST for central quality assurance, and HITRUST issues the outcome. Confirm with the assessor, before work starts, which evidence formats and access methods they accept.
