How self-hosted vLLM for HIPAA ePHI workloads fits your Security Rule program
vLLM can support several technical safeguards at the serving layer, but no product makes a deployment HIPAA compliant, because the Security Rule in 45 CFR Part 164 Subpart C places its obligations on covered entities and business associates. For a team keeping prompts and outputs that contain ePHI on infrastructure it controls, the useful question is which Security Rule standards the serving stack can help meet, which need a gateway or other controls, and which belong to the organization's own program. The technical safeguards in 45 CFR 164.312 are the best starting point because they describe the controls that touch model traffic directly. Unique user identification and the emergency access procedure are required implementation specifications, and the remaining specifications in that section are addressable.
The serving layer helps most with transmission and endpoint exposure. vLLM's OpenAI-compatible server offers an --api-key option, but the security documentation says it covers only the /v1, /v2, /inference and /cohere paths. It does not cover /metrics, /health, /invocations, /pause, /resume or /abort_requests, and the documentation warns against relying on the key alone. Plan a reverse proxy that allowlists only the endpoints users need, and test each excluded path from outside the network. Prometheus metrics at /metrics help with capacity and latency monitoring, but they count requests and tokens without identifying the user, so they should not be presented as the audit controls required by 164.312(b).
The gateway carries the user-level controls. A shared --api-key cannot give each person a unique identifier, so 164.312(a)(2)(i) and 164.312(a)(1) need an identity layer in front of vLLM. A gateway such as the LiteLLM proxy can issue per-user or per-team virtual keys, restrict keys to specific models and record requests. Confirm which features your chosen edition includes. The LiteLLM documentation places SSO beyond five users and audit logs under its Enterprise license, so those features belong in your quote. For multi-node runs, vLLM's documentation states that node-to-node traffic is insecure by default and must sit on an isolated network. Confirm how encryption in transit is handled at the proxy or load balancer, and where prompts and outputs are written in logs, caches and backups.
Compliance evidence sits in your program, not in a certificate. HHS states that no Security Rule standard requires an entity to certify compliance, and it does not recognize private certifications. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits, so your risk analysis, policies and access reviews must show how each addressable specification was assessed and, where it was not implemented, why and what equivalent measure was used. DeployOpen prepares systems, controls and evidence for these assessments. It does not issue audit reports, attestations or certifications, and independent assessors make those determinations. If a business associate handles ePHI during the work, confirm that its contract meets 45 CFR 164.314(a)(2)(i) before work starts.
Which HIPAA technical standards map to vLLM and what configuration each needs
This table maps the HIPAA technical safeguards that a self-hosted vLLM deployment touches to the documented vLLM behavior, the configuration each needs and the gap that remains. Read the requirement column first: unique user identification and the emergency access procedure are required, while automatic logoff and encryption are addressable and need a documented assessment under 164.306(d). The main takeaway is that vLLM covers only part of these safeguards, and the gateway and written procedures carry the rest.
| Requirement | vLLM capability | Configuration needed | Remaining gap |
|---|---|---|---|
| Access limits, 164.312(a)(1) | The --api-key option protects only /v1, /v2, /inference and /cohere endpoints | Set --api-key, allowlist user endpoints at a reverse proxy and block control and metrics paths for users | A shared key is not per-user access; the access policy must live in the proxy or gateway |
| Unique user identification, 164.312(a)(2)(i), required | vLLM has no per-user identity, so a shared API key cannot identify individuals | Issue a unique identity per user at the gateway and reach vLLM only through that gateway | Confirm the gateway ties every request to one named user, since vLLM cannot do this alone |
| Activity recording, 164.312(b) | The /metrics endpoint exposes aggregate Prometheus counters, latency and KV cache use | Require authentication for /metrics and add per-request logs with user identity at the gateway | Per-request audit records are not a documented vLLM feature; define what must be recorded and reviewed |
| Transmission protection, 164.312(e)(1) | Inter-node communication is insecure by default, with no authorization or encryption | Place all nodes on an isolated network and secure client traffic at the reverse proxy | Confirm the TLS options for your proxy and whether inter-node traffic needs added encryption |
| Encryption of ePHI in transit, 164.312(e)(2)(ii), addressable | The security docs describe no built-in client encryption setting for serving traffic | Encrypt client-to-gateway and gateway-to-vLLM links, then document the decision under 164.306(d) | Addressable: if encryption is not used, a documented equivalent measure is required |
| Emergency access procedure, required | vLLM is a serving engine and has no break-glass access model | Write and test a procedure for who reaches the serving host and gateway during an outage, and log that access | The procedure is a written policy that no vLLM feature supplies |
| Automatic logoff, addressable | vLLM has no documented user session that could time out | Set session timeouts and key rotation at the gateway identity layer where user sessions exist | Assess whether logoff applies to API clients, and document the decision under 164.306(d) |
Why the gateway sits in front of vLLM and where inter-node traffic stays
Users should never reach the vLLM API server directly. The reference layout places a gateway at the edge, where it authenticates each user and forwards only the routes meant for users to a vLLM API server on a private network segment. The reason is that vLLM's own --api-key option does not cover every endpoint. According to the vLLM security documentation, the key protects paths under /v1, /v2, /inference and /cohere, but not /invocations, /pause, /resume, /abort_requests, /metrics or /health. The documentation warns against relying on the key alone and recommends a reverse proxy that allowlists only the endpoints meant for users. Your gateway policy should deny everything else by default, and your team should list each allowed path in the design record before go-live.
Multi-node vLLM is a separate exposure. Pipeline parallelism across nodes runs over Ray or vLLM's multiprocessing backend, and the vLLM security documentation states that communication between nodes is insecure by default, with no authorization or encryption. The documented protection is to place those nodes on an isolated network. In practice, that means the inter-node ports stay off the user-facing segment and off any path the gateway uses. Decide which subnet hosts the worker nodes, which hosts may open connections to them, and how administrators reach them. Then test from a user-facing host and from the gateway host that the worker ports cannot be reached, and record the results as evidence.
LiteLLM is one gateway option that the supplied facts cover. Its virtual keys need a PostgreSQL database, which becomes part of your ePHI system boundary because it stores key and usage records. Once more than one proxy instance runs, LiteLLM's production guidance calls for Redis 7.0 or newer to share rate limits, router state and cache. Audit logs and IP allowlisting are listed as Enterprise-only items, so if your access rules depend on them, confirm the license scope before you choose the gateway. Whatever gateway you select, confirm in writing that the exact version can route to a self-hosted vLLM backend using the OpenAI request format and that it can enforce your route allowlist.
vLLM ships new minor releases about every two weeks, so the gateway and the engine will drift unless you control the change. Pin the vLLM version in your deployment manifests, and pin the gateway version as well. Before promoting any upgrade, rerun the route tests: a user token should reach the allowed inference paths, and the blocked paths, including /metrics, /health and the pause and abort endpoints, should be denied from the user segment. Route paths can change between releases, so a rule that passed last month may no longer match. Keep the test results with the change record, since they show the gateway policy still matches the engine you are running.
What evidence a self-hosted vLLM deployment can produce for auditors
A HIPAA assessment asks for proof that access, logging, transmission and configuration controls exist and were operated over time. vLLM supplies some of that proof directly, while most of it comes from the gateway, the secret manager, the network layer and your own governance records.
Gateway request records with user identifiers
Request logs written by the access layer in front of vLLM, such as a LiteLLM proxy with virtual keys, can tie each prompt to a unique user or key identifier. This supports the unique user identification specification in 45 CFR 164.312(a)(2)(i) and the audit controls standard in 164.312(b). Confirm which request fields vLLM writes to its own logs in the version you run, since those fields may differ from what the gateway records, and decide how the two sets of logs are correlated.
TLS and network configuration exports
Exported configuration showing TLS settings on the public endpoint, the reverse proxy allowlist of permitted paths, and the isolated network that carries traffic between vLLM nodes. This evidence supports the transmission security standard in 164.312(e). Because vLLM node-to-node communication is insecure by default, the export should show the isolation boundary, not just the public listener.
Secret and key inventory with manager references
A list of every credential the stack uses, including the gateway master key, provider keys, database passwords and TLS private keys, with the secret manager path or reference for each. The inventory should show owners and rotation dates, and it should contain references and never secret values. Auditors use it to confirm that access credentials are controlled and that no key sits in a configuration file.
Access review records
Periodic reviews showing who holds gateway admin rights, which virtual keys and teams are active, and which keys were removed after staff changes. Each review should be signed off by a named owner and retained with the evidence it relied on. Without these records, unique identifiers prove only that a user existed, not that the user was still authorized.
Pinned version and change records
The exact vLLM release, container image digest and gateway version in production, with a change log for each upgrade and the test evidence that preceded it. vLLM ships minor releases about every two weeks, so unpinned deployments can change behavior without a recorded decision. Keep the change records linked to the risk analysis so that each change can be traced to a reviewed assessment.
Written risk analysis and policies
The documented risk analysis, policies and procedures that the Security Rule requires covered entities and business associates to maintain, along with the rationale for each addressable specification that was not implemented as written. Operational metrics from the vLLM /metrics endpoint, covering request counts, token throughput, latency and KV cache use, support capacity reviews but do not identify users, so they cannot replace the access records above. Set log retention according to your own policy and counsel's advice.
How to document addressable specifications for vLLM without overclaiming
The point of an addressable specification is that the decision must be written down. Appendix A to Subpart C lists 36 implementation specifications across the administrative, physical and technical safeguards: 14 are required and 22 are addressable. For an addressable specification, 45 CFR 164.306(d) requires the covered entity or business associate to assess whether the specification is reasonable and appropriate for its environment. If it is not, the entity must document why and, where reasonable and appropriate, implement an equivalent alternative measure. For a self-hosted vLLM deployment, that assessment covers the gateway, the vLLM server and the logging path, because the controls sit across all three. Nothing in the vLLM documentation decides whether a specification is met, so each decision belongs in your own risk analysis.
Illustrative example: a hospital group runs vLLM for clinical summarization and its team reviews automatic logoff, which is addressable under the technical safeguards. The vLLM server does not tie sessions to individual clinicians, so the team first considers a timeout only in the client application. It concludes that a client-side timeout alone is not enough, because a user who leaves a shared workstation can still hold an open session. The team enforces an idle timeout at the gateway, which holds the user identity, and keeps the client timeout as a second layer. The record states the standard, the risk, the measure, the approved timeout value, the named owner, the review date and where the gateway configuration export is stored.
Overclaiming usually happens in the wording. A statement that vLLM enforces access control is too broad, because the --api-key option protects only some endpoints. The vLLM security documentation says the option covers /v1, /v2, /inference and /cohere, but not /invocations, /pause, /resume, /abort_requests, /metrics or /health, and it warns against relying on the key alone. The record should therefore describe the reverse proxy allowlist as the measure, name the endpoints it permits, and attach the proxy configuration along with a test showing that blocked endpoints are denied. Apply the same care to logging. The /metrics endpoint exposes request counts and latency, which support operations but do not replace the activity recording that 164.312(b) requires for systems that use ePHI.
NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule, published in February 2024, is a practical companion for writing these entries. For each standard it gives key activities, descriptions and sample questions, which help teams test whether their reasoning holds up. HHS lists the guide as informational and states that it is not legally binding, so it shapes your method but does not settle your obligations. Because no HIPAA certification exists, the written assessment is the record you would need to produce during an OCR complaint investigation or compliance review. Before it is final, confirm with your privacy and legal advisers how it fits your business associate agreements, and walk through each addressable entry with the people who will sign it.
Where self-hosted vLLM for HIPAA ePHI workloads still needs your controls
vLLM is a serving engine, not a complete HIPAA control set. The gaps below sit at the API surface, the identity layer, the cluster network, the organizational safeguards and the release process, and each one needs a named control and an owner before prompts or outputs containing ePHI reach the server.
Unprotected operational endpoints
The --api-key option protects the /v1, /v2, /inference and /cohere paths, but not /invocations, /pause, /resume, /abort_requests, /metrics or /health. The vLLM security documentation advises against relying on the key alone. Add a reverse proxy or gateway that allowlists only the endpoints users need, and deny the operational paths from user networks. Platform engineering owns the proxy rules, and the security team reviews them against the access model.
No per-user identity inside vLLM
vLLM does not model individual users, so a shared API key cannot show which clinician or service sent a given prompt. Under 45 CFR 164.312(a)(2)(i), each user or service needs a unique identifier. Put a gateway with per-user or per-service keys in front of vLLM, and tie those keys to your identity provider. The identity or security team owns the user lifecycle, including offboarding.
Unauthenticated inter-node traffic
The vLLM security documentation states that communication between nodes in a multi-node deployment is insecure by default, with no authorization or encryption. Place all nodes on an isolated network segment, restrict it with firewall rules, and confirm that no node is reachable from user or internet-facing networks. The infrastructure team owns the network design and the verification evidence.
Request logging and access review
Section 164.312(b) requires mechanisms that record and examine activity in systems that use ePHI. vLLM's /metrics endpoint exposes operational counters, not a per-user audit trail of prompts and outputs. Decide which events the gateway logs, where logs are stored and who reviews them, and confirm that logs do not capture ePHI unless your policy allows it. The security operations team owns log review.
Administrative, physical and contingency safeguards
The standards in 45 CFR 164.308 (administrative) and 164.310 (physical) sit with your organization, as do the contingency planning and facility controls that keep GPU hosts and their storage protected. Write risk analysis, workforce security, data backup and disaster recovery procedures for the inference cluster, and assign each to a named role. The compliance lead and facilities owner share this work.
Business associate agreements for providers
Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the provider to comply with the Security Rule, flow the same terms to subcontractors that handle ePHI, and report security incidents. Any hosting company, managed Kubernetes provider or support firm that can reach ePHI in the stack needs a signed agreement before onboarding. Legal and procurement own the contracts, and the compliance lead confirms which vendors are in scope.
Change control for a two-week release cadence
vLLM ships new minor releases about every two weeks, for example v0.28.0 on August 26, 2026 and v0.29.0 on September 9, 2026. Each release can change endpoints, defaults or model compatibility, so an unreviewed upgrade could alter controls you already tested. Set a change process with staging tests, a security review of release notes and a rollback plan, and decide which versions are approved for production. The platform team owns the process, and change advisory approves exceptions.
Configuration sequence for a HIPAA-scoped vLLM deployment
This sequence takes a self-hosted vLLM deployment from data mapping to a controlled, versioned configuration for ePHI. Each step ends with a check that produces evidence for your own compliance file. DeployOpen can implement these steps, while your organization keeps responsibility for the controls and the decisions behind them.
Map ePHI data flows and connected systems
Before anything is installed, list every place prompts and outputs containing ePHI enter, move and rest. Include client applications, the gateway, vLLM nodes, logs, caches, backups and any retrieval store. Name an owner for each system and the people or service accounts that reach it. Complete the risk analysis the Security Rule requires for these flows before any real data is connected. Done when the data-flow diagram and system inventory are signed off by the security officer and the platform owner, and every system that touches ePHI has a named owner and a documented purpose.
Isolate vLLM nodes and terminate TLS at the edge
Place vLLM servers and any multi-node traffic on a network segment that only the gateway and the monitoring path can reach. The vLLM security documentation states that communication between nodes is insecure by default, without authorization or encryption, so isolation is required before any multi-node run. Terminate TLS at the edge proxy, and document how internal hops are encrypted based on your risk analysis, since the Security Rule treats encryption of transmitted ePHI as an addressable specification. Done when a connectivity test from user subnets to vLLM and multi-node ports fails, and the TLS configuration is recorded.
Put an authenticated gateway in front of vLLM
Deploy a gateway, such as the LiteLLM proxy, that gives each user or service a unique identity and a virtual key scoped to approved models, budgets and rate limits. The vLLM --api-key option does not cover every endpoint and should not be relied on alone, so the gateway becomes the access control point. Configure the proxy to forward only the endpoints meant for users, such as chat completions, and deny all other paths. The Security Rule requires unique user identification, so shared keys should not be used for people. Done when a key for one user cannot call a model it was not granted, and a request to a non-allowlisted path is refused in testing.
Restrict metrics and health endpoints to monitoring
vLLM exposes Prometheus-format metrics at /metrics, and the --api-key option does not protect /metrics or /health. Limit these paths to an internal monitoring network or a dedicated scrape identity, and block them at the edge and gateway for user traffic. The same documentation lists /invocations, /pause, /resume and /abort_requests as unprotected by that option, so block those paths from user access as well. Review which metric labels could carry user or prompt content before exporting them to shared dashboards. Done when external requests to /metrics and /pause are refused and the monitoring system still scrapes successfully.
Configure request logging with user identifiers
Enable gateway request logging so each call records the authenticated user or service identifier, the model, the time, the outcome and the source. Decide with the security officer which fields are kept and whether prompt and output bodies are logged at all, because logged content can itself contain ePHI. Send logs to a store that the platform team can search and that access controls restrict. Confirm the retention period with your compliance lead and counsel. Done when a test request from a named test identity appears in the log with that identifier, and the access list for the log store has been reviewed.
Move gateway secrets into a secret manager
Store the LiteLLM master key, database credentials, model provider keys and signing material in a secret manager, not in configuration files, container images or shell history. The LiteLLM master key must start with sk- and should be injected at runtime. Restrict read access to each secret to the workload that needs it, and log secret access where the manager supports it. Confirm that the secret manager integration you plan to use is included in the edition you run, since LiteLLM documents some secret manager integrations as Enterprise features. Done when a search of repositories, images and manifests finds no key values and the gateway starts from injected secrets alone.
Test with synthetic data and keep PHI out of fixtures
Validate routing, identity, endpoint allowlists, logging and failure behavior using synthetic records that resemble clinical text without containing real patient information. PHI should never enter test fixtures, sample prompts, recorded traffic, bug reports or CI logs. Keep a written test plan that maps each test to the safeguard it checks. Connect real ePHI only after the risk analysis is complete and these tests pass in a non-production environment. Done when the test report shows each control passing against synthetic data, and the team has confirmed that no real records were copied into test artifacts.
Run access reviews and pin versions under change control
Review gateway identities, virtual keys, model grants and administrator accounts on a recurring schedule set by the security officer, and remove access that no longer matches a job role. vLLM ships new minor releases about every two weeks, so pin the vLLM and LiteLLM versions you validated and route every upgrade through change control with re-testing of the controls above. Record each change, its approver and its test result in a change register. Done when the signed access review record exists and every running component matches a version listed in the register.
What HIPAA enforcement and penalties mean for a self-hosted AI workload
A self-hosted vLLM deployment that handles ePHI falls within the Security Rule, so the practical question is how the HHS Office for Civil Rights (OCR) would test it. OCR enforces the Security Rule through complaint investigations, compliance reviews and audits. Its 2024 to 2025 HIPAA audits review 50 covered entities and business associates on the Security Rule provisions most relevant to hacking and ransomware. For an inference service, an examiner is likely to ask who can reach the endpoints, which user identities appear in logs, and how prompts and outputs move between nodes. Owning the hardware does not answer those questions, so the evidence should exist before anyone asks for it.
Penalty exposure is set by 45 CFR 102.3, which applies an inflation-adjusted civil money penalty to HIPAA violations. For penalties assessed on or after January 28, 2026, the range runs from $145 per violation where the entity did not know of the violation to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294 (91 FR 3666). The calendar-year cap limits total exposure for identical violations, so how an examiner counts violations across a multi-endpoint service matters as much as the penalty tier. Ask counsel how a gateway with several exposed endpoints would be counted. Document each safeguard in 45 CFR 164.312, including access control, unique user identification, audit controls and transmission security, so that any gap can be shown as known, scoped and corrected.
The Security Rule text may change. HHS proposed a major revision on January 6, 2025 (90 FR 898, RIN 0945-AA22), with comments due March 7, 2025. As of October 2026 no final rule has been published, and the latest Unified Agenda lists final action as projected for July 2027. Until a final rule is published, the current requirements in 45 CFR 164.302 to 164.318 are what an examiner applies. Confirm the current status of the proposal with counsel before the design review, and ask which proposed changes to access control, logging or encryption would affect the gateway and its log retention if finalized.
For EU readers, the closest comparison is GDPR enforcement. On September 3, 2026, France's CNIL fined Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34, finding that external access to its patient record system lacked VPN and multi-factor authentication and that access control ignored the care team's need to know. This example is illustrative and carries no HIPAA finding. The lesson transfers directly to a vLLM gateway: remote access to the administrative interface, the proxy and any metrics endpoint should go through a VPN or equivalent with multi-factor authentication, and access rights should follow the clinical role of each user.
What buyers ask before hiring help for self-hosted vLLM and HIPAA
Is vLLM HIPAA compliant out of the box?
No. No software product is HIPAA compliant on its own, because the Security Rule applies to the covered entity or business associate that creates, receives, maintains or transmits ePHI. vLLM is open-source inference software licensed under Apache-2.0 with no paid edition, so it carries no HIPAA status of its own. Compliance comes from how your organization configures access control at a gateway, records activity, encrypts traffic, isolates communication between nodes, signs the required business associate agreements and documents its policies. Several technical safeguards, including unique user identification and audit controls, must be designed around vLLM and evidenced by your team. Ask counsel to map each requirement to your deployment.
Does DeployOpen certify HIPAA compliance for our deployment?
No. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms in infrastructure you control, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent assessors and certification bodies issue those. HHS has stated that no Security Rule standard requires an entity to certify compliance and that it does not endorse or recognize private certifications. Ask for a written scope that lists the evidence we will prepare and the assessments your organization will commission separately.
What does a self-hosted vLLM HIPAA project cost?
The software has no license fee because vLLM has no paid edition. Cost comes from four areas: accelerator capacity (GPUs or other accelerators, bought or rented), surrounding infrastructure such as networking, storage, gateway and logging components, implementation work, and the people who operate the system after launch. Implementation is generally one-time, while accelerator capacity, infrastructure and operations recur. DeployOpen does not publish a price list. A quote follows the written scope, so ask for line items that separate build effort, accelerator and infrastructure assumptions, documentation and evidence preparation, and ongoing support.
How long does a HIPAA-aligned vLLM deployment take?
The timeline is set by the agreed scope, and no fixed duration applies to every project. The main drivers are the number of models and endpoints, accelerator hardware lead time, how many systems connect to the inference service, how many data flows need decisions, and how much policy and evidence work your organization completes in parallel. Fixed-scope engagements agree deliverables and timelines in writing before work starts. If a provider gives you a duration, ask for the assumptions behind it, the client tasks it depends on and the events that would change the date.
What does our team need to provide for the engagement?
Expect to name several owners before work begins: a security owner, an application owner for each consuming system, an infrastructure owner for the accelerator and network environment, and a privacy or compliance lead who signs off on policy decisions. You will also need network access to the environment, approved change windows, and decisions on which prompts and outputs contain ePHI, where they are stored, how long logs are kept and who can read them. Have counsel review business associate terms with any model or tooling vendor, along with the risk analysis you rely on. Confirm these items in the scope document.
Can our own engineers build a HIPAA-ready vLLM setup alone?
Yes, if your team has the skills to build, operate and evidence the controls. That means experience with Kubernetes or your chosen hosting platform, reverse proxy and identity configuration, TLS and network isolation between nodes, logging and monitoring, backups, and writing the policies and risk analysis the Security Rule expects. vLLM's security documentation says node-to-node communication is insecure by default and that the API key option should not be relied on alone, so a reverse proxy that allowlists user-facing endpoints is part of the job. Many teams combine internal staff with outside help for a clearly scoped part of the work.
Is HITRUST required for HIPAA compliance?
No. HITRUST is a separate framework, the HITRUST CSF, and HIPAA does not require it. The HIPAA Security Rule is a federal regulation with its own standards and implementation specifications. Some customers and contracts ask for HITRUST, and in that case the certification is issued through HITRUST's own assessment process. DeployOpen does not issue HITRUST certifications, and neither does the software vendor. If a partner asks you to pursue HITRUST, confirm in writing which requirement drives it and which assessor will issue the result.
How DeployOpen scopes and delivers HIPAA-oriented vLLM configuration and evidence
DeployOpen plans and implements self-hosted vLLM inside infrastructure you control, with the gateway, network isolation, logging and evidence set up around it. Because vLLM alone does not cover the HIPAA technical safeguards, we scope the controls that sit outside the engine and prepare evidence for your assessors.
How we scope
- The written scope names the ePHI data flows, users and workloads that reach the vLLM endpoint.
- It maps each 45 CFR 164.312 technical safeguard to the gateway, vLLM or surrounding infrastructure that addresses it.
- Engagements are fixed-scope, and ongoing support is available as a retainer.
How we build
- Place vLLM nodes on an isolated network, since vLLM's security docs treat inter-node traffic as insecure by default.
- Front vLLM with a reverse proxy that allowlists only user-facing endpoints, keeping /metrics and /health off user networks.
- Configure unique user identities, per-user keys and request logging at the gateway, then test that unauthorized calls are refused.
How we hand over
- A control map linking each safeguard to the component that implements it, its configuration owner and its evidence source.
- Runbooks for access reviews, log retention, key rotation and vLLM upgrades, which ship minor releases about every two weeks.
- Open items for your privacy and legal teams, such as business associate terms that DeployOpen cannot settle for you.
How we support
- Retainers can cover upgrades, patching and periodic review of configuration against the control map.
- Continuous security testing of the endpoint and gateway can run under a retainer, scoped in writing.
- Compliance readiness support prepares systems and evidence for your assessors; DeployOpen does not issue audit reports or certifications.
