HITRUST LLM Requirements for Identity, Data, and Evidence

HITRUST LLM requirements begin with scope. An assessor needs to know which application uses the model, which people can invoke it, what information enters a prompt, and which endpoint receives the request. The selected HITRUST assessment then determines the applicable requirements for that defined environment.

The HITRUST CSF is a broad information-security and privacy framework. HITRUST describes e1 as a 43-control foundational assessment and i1 as a 182-requirement assessment. The r2 assessment is tailored to the organization's risk profile and scope. Those assessment facts matter because there is no single freestanding checklist called "HITRUST requirements for every LLM."

TL;DR

• HITRUST LLM requirements depend on the assessment type, system scope, risk profile, and current HITRUST materials.
• The request path needs verified identity, classified prompt data, approved model destinations, controlled configuration, and per-decision evidence.
• Provider assurance supports inherited controls but does not prove a local user's authority for one prompt.
• Local tools, model development, endpoints, and human workflow controls remain outside an HTTP gateway.

Scope the application and model path

Name the business owner and technical owner. Record the application's purpose and users. Add the model provider, endpoint, region, account, and retention configuration. Identify prompt sources and output recipients.

Then draw the HTTP path. An authenticated user reaches the application. The application assembles context and sends a request through the policy point. The approved provider returns a response, which enters a named downstream workflow.

The drawing should show bypass routes in red. A direct provider SDK call is a separate path. A local model is another. The assessor needs to know which traffic receives the claimed control and which traffic needs different evidence.

The NIST AI Risk Management Framework is a voluntary supporting reference for AI-specific risk work. NIST says it is intended to bring trustworthiness considerations into the design and use of AI systems. It can organize supporting analysis while HITRUST remains the selected assurance framework.

The HITRUST AI controls mapping gives a domain-level map. This article states the concrete requirements for the LLM request itself.

Require identity on every model request

The application is responsible for authentication. It should supply the verified human or workload identity to the enforcement point. Shared provider API keys are service credentials. They rarely prove which employee or agent initiated one request.

The authorization record should include the originating principal and acting agent. It should also include role and approved purpose. Policy can then decide which model and route are permitted for that identity.

Test at least two roles. Send an allowed request for the first role. Send a denied request for the second role under the same data condition. Preserve both events. The pair shows that the control made an identity-bound decision before transmission.

An identity claim without a signature or trusted application path is weak evidence. Document how the gateway validates the supplied context and how keys are rotated.

Classify the assembled prompt before egress

LLM context is assembled at runtime. It can include user text and retrieved records. It may also include tool output or prior model messages. Classification should inspect that final outbound body, because a reviewed system prompt cannot predict every field retrieved later.

Define classes that match the organization's data policy. PHI and credentials may require different routes. Internal business data may be permitted only on a contracted endpoint. Public text can use a wider model set.

The control outcome can be permit or refuse. It may also redact selected content or route the request to a private endpoint. Record the detected class and transformation. Keep the minimum evidence needed for review so the audit store does not become an uncontrolled copy of protected data.

The AI data-classification guide covers taxonomy design and request-time enforcement.

Restrict model destinations and provider settings

Maintain an approved model register. Each entry should name the provider and endpoint. It should also record region and account, retention position, training-use term, data classes, and owner.

Dynamic routing deserves a specific control. One application URL can send traffic to several providers. The decision record must preserve the chosen endpoint for each request. A procurement record proves what was approved; the runtime record proves what was used.

Network egress should support the policy. Restrict direct provider access from the application tier where the architecture permits it. Otherwise, a developer can bypass the policy point with a new SDK configuration.

Review provider changes as controlled changes. A new model version or region can alter the risk analysis even when the vendor name stays the same.

Control policy and configuration changes

Model allowlists and identity mappings are security configuration. So are prompt-classification rules and response controls. Store them as versioned artifacts with named owners and approval history.

Every request decision should retain the active policy version. When a rule changes at 16:20, the team can then distinguish requests evaluated before and after that change.

Emergency change is still controlled change. Record the approver and reason. Set an expiry when the exception is temporary. Run a synthetic test and keep the result beside the change ticket.

My opinion is that a policy screenshot has almost no audit value unless the team can connect it to a real decision event. The version number is that connection.

Preserve evidence outside the calling application

The calling application should not be the sole custodian of its authorization history. An independent write path gives the assessor stronger evidence that the application did not silently remove denied events.

For each request, preserve event ID and time. Add the originator, agent, purpose, content class, destination, policy version, outcome, and integrity state. Link the event to the application trace without copying every trace field.

Retention and access need their own rules. Full prompt storage can create a second sensitive repository. A content hash and detected spans may support many reviews. Selected systems may justify encrypted prompt retention under tighter access.

Prepare incident and recovery evidence

The incident plan should define which AI events trigger escalation. Repeated refused attempts can matter. So can a direct route or an unexpected destination. A provider retention mismatch and sensitive output sent downstream are separate event types.

Preserve the original decision and configuration before containment. Record the changed policy and test it with a denied synthetic request. The HITRUST AI incident reporting guide describes the evidence sequence and owner split.

Recovery should validate approved traffic as well. One blocked test proves the unsafe path is closed. One allowed test proves the required business path still works.

External notice duties depend on law and contracts. HITRUST scope supports the control assessment but does not create one universal incident deadline.

Separate inherited controls from local responsibility

A provider's certification can support controls inside the covered provider environment. Contract terms can support security and retention commitments. The deploying organization still owns the local purpose and user authorization. It also owns prompt minimization and destination approval.

An HTTP gateway has a specific boundary. It can govern requests routed through it between authenticated users or agents and LLM endpoints. It cannot inspect a local Python function or STDIO tool. It cannot secure an employee laptop or validate model training data. Those responsibilities need other controls and evidence owners.

Write that division into the system description. Clear boundaries reduce double counting and show the assessor where to ask the next question.

DeepInspect

DeepInspect governs HTTP AI traffic routed between authenticated users or agents and LLM endpoints. It can evaluate supplied identity and prompt classification, enforce approved model destinations, and write a tamper-evident record for every decision.

Those mechanisms can contribute to HITRUST evidence within a broader control program. DeepInspect does not choose the assessment scope or legal basis. It does not secure local execution, endpoints, model development, or human decisions outside the request path.

Book a technical deep dive at deepinspect.ai.