Why an AI gateway for the public sector starts with records, not routing
An AI gateway for the public sector is first a records system and only second a router. Many departments already call hosted models through individual accounts, so leadership needs one controlled entry point that enforces department allowlists, spend limits and a usable record of every call. The gateway earns its place when it can answer three questions on demand: which department called which approved model, what it cost, and what evidence exists for the request. Routing and failover matter, but they come after those answers are reliable. Public bodies face more record-keeping obligations than most other industries, and the obligations depend on the data and the service model. Agencies that run on federal frameworks work from the NIST SP 800-53 control catalog, where baselines in SP 800-53B select 149, 287 and 370 controls and enhancements for low, moderate and high systems. FedRAMP applies when a cloud service creates, stores or processes federal information on behalf of an agency as a shared service, so a hosted model API reached through a gateway needs a scope decision. CJIS Security Policy applies to criminal justice information, and CUI handling under 32 CFR 2002 points to NIST SP 800-171. In the EU, NIS2 treats public administration as a high-criticality sector, and the AI Act requires automatic logs from high-risk systems. Confirm with counsel and your assessor which of these apply before choosing a log schema.
Practically, the platform answer is LiteLLM for virtual keys, per-team budgets, model restrictions and request logging, backed by PostgreSQL and, once more than one proxy instance runs, Redis. Confirm which LiteLLM features your agency needs, since SSO beyond the free limit, SCIM, audit logs and team-level guardrails depend on an enterprise license, and verify the current terms with the vendor. Where the agency already operates Apache APISIX as its API gateway, it can front the same models with its openid-connect plugin for government SSO and keep one enforcement point for traffic. Decide early where prompt logs are stored, who can read them, and how long they are retained, because that decision shapes every audit answer that follows.
Which public sector rules shape the gateway build
This table maps each public sector requirement to its source and to what it means for an AI gateway build. Read it as a checklist of evidence to prepare, and confirm with your assessor or authorizing body which baseline and scope apply to your agency.
| Requirement and source | What it asks for | What it means for the gateway build |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines (SP 800-53B) | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively | Pick the baseline from the system's impact level first, then map gateway controls such as access control, audit logging and configuration management to it |
| FedRAMP scope (OMB M-24-15) | Cloud products that create, collect, process, store or maintain federal information on behalf of an agency | Confirm whether each hosted model provider behind the gateway handles federal information; self-hosted models inside agency accreditation boundaries are assessed differently |
| CJIS Security Policy v6.1 encryption | FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI outside physically secure locations | Use validated cryptographic modules for TLS, database and Redis encryption and key storage; confirm module certificates with the vendor |
| CJIS Security Policy v6.1 vulnerability scanning | Vulnerability scanning at least monthly | Schedule scans across the gateway hosts, PostgreSQL, Redis and container images, and keep scan reports as assessment evidence |
| 32 CFR 2002.14(h)(2) and NIST SP 800-171 | Agencies use NIST SP 800-171 for CUI on non-federal systems unless the CUI authority prescribes other safeguards | Where a contractor or partner runs the gateway with CUI prompts, apply SP 800-171 requirements to the gateway environment and to prompt log storage |
| WCAG 2.1 Level A and AA (ADA Title II, 28 CFR 35.200) | State and local web content and mobile apps, including contracted ones, must meet WCAG 2.1 AA from 26 April 2027 for large entities | Test the admin UI, key request forms and any user-facing portal built on the gateway for WCAG 2.1 AA; confirm your entity's population tier and date |
| EU AI Act Articles 12 and 19 | High-risk systems must allow automatic event logging over their lifetime, and providers keep logs for at least six months unless other law requires longer | For EU agencies, design gateway logs with timestamps, model identifiers and request identifiers, and set retention to meet the longer of these rules and records law |
| Assessment evidence versus authorization | Independent assessors and authorizing officials decide on authorizations and certifications | DeployOpen prepares configurations, control mappings and evidence for your assessor; it does not issue authorizations, attestations or certifications |
What data flows through the gateway in each agency
Public information is material already published or releasable without restriction, such as program descriptions, published statistics and open meeting notices. Because it carries no confidentiality requirement, an agency can usually permit a broader set of models for this class, including hosted services, provided the agency has approved the provider. The gateway still matters here because it records which model answered which request, which supports transparency and cost reporting even when the content itself is harmless.
- Model access: Allow approved hosted and self-hosted models through named model allowlists per department.
- Prompt logs: Store prompts and responses in agency-controlled storage, since logs can reveal what staff were researching even when the source material is public.
- Boundary: Hosted models are reached through the gateway only, so the agency tenancy never sends traffic directly to a provider.
- Spend and attribution: Tag requests by department so cost reports and transparency records can be produced without reading content.
- Retention: Apply the same retention schedule as other logs, because the agency's records rules still govern them.
Confirm with records and legal staff whether the agency treats such prompts as public records, and which records schedule applies to gateway logs.
Internal documents include memos, draft policy, procurement files and operational guidance that are not public but do not fall into a regulated category. This class usually calls for a tighter boundary than public information. The safe default is that these documents reach only models running inside agency tenancy or in an authorized cloud environment, and that the gateway blocks any endpoint not on the approved list for the department.
- Model access: Limit retrieval-augmented and chat use to models served in agency tenancy, such as vLLM or Ollama on agency hardware, or to a cloud service the agency has approved for this data.
- Prompt logs: Keep logs in agency storage with role-based access, because prompts often quote the internal document itself.
- Boundary: Use the gateway to refuse routes to external providers for tagged documents, so the boundary is enforced in configuration rather than left to user judgment.
- Document stores: Keep embeddings and indexes in the same boundary as the source files.
- Access control: Map gateway keys to the same groups that govern file share permissions so users cannot query content they could not open directly.
Ask the security team whether the agency's own policy classifies these documents above or below the level that permits hosted models.
Personal data covers information that identifies or can reasonably be linked to an individual, including applicant records, benefits files, case notes and staff data. Its handling depends on the legal basis, the program's statute and the agency's privacy obligations, so this tab describes controls to confirm rather than a single answer. The gateway can enforce which models may receive such data, but it cannot decide lawfulness on its own.
- Model access: Route personal data only to models inside agency tenancy or to a cloud service that the agency has assessed and approved for this purpose.
- Redaction: Use guardrails for PII detection before any external call, and test detection accuracy on agency samples before relying on it.
- Prompt logs: Treat logs as personal data, with the same access restrictions, purpose limits and deletion rules as the source system.
- Boundary: Record in the gateway configuration which tenant or cloud region each allowed model runs in, so privacy reviews can trace the path.
- Subject requests: Confirm how the agency will locate and delete prompt logs that contain a specific person's data.
Confirm with the agency privacy office which legal basis and assessment are required before any personal data reaches a model.
Criminal justice information (CJI) and controlled unclassified information (CUI) carry the strictest requirements. CJI is governed by the FBI CJIS Security Policy, and CUI by the NIST SP 800-171 requirements that federal agencies apply to non-federal systems. For CJI, version 6.1 of the policy requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for data in transit and at rest outside physically secure locations. Where a cloud service is used, it must meet the applicable federal cloud authorization requirements, and the agency should confirm the exact authorization level with its own compliance team.
- Model access: Permit only on-premises models served with vLLM or Ollama inside the criminal justice network, unless the provider environment is explicitly authorized for that data class.
- Encryption: Confirm that the gateway, its database and Redis store use approved cryptographic modules and 256-bit AES keys.
- Prompt logs: Keep logs inside the same enclave, with the same access controls and audit trail as the source records.
- Boundary: Keep the gateway, the models and the logs in one authorized boundary, with no route to a hosted provider.
- Scanning: Include the gateway host and containers in the monthly vulnerability scanning cycle that the policy requires.
Confirm the authorization status and cryptographic validation of every component with the agency's CJIS Information Security Officer before any data is routed.
Gateway logs are often treated as operational telemetry, but they hold the prompts and responses that staff typed or pasted, and those can contain any of the four data classes above. A log that records a CJI query or a personal data extract becomes regulated data in its own right. Agencies should classify logs at the highest level of the content they hold, or separate metadata logs from content logs so that only the content logs carry stricter rules.
- Classification: Assign each log store the highest data class it may contain, and document that decision.
- Retention: Set retention for prompt content by records schedule and privacy rules, separate from retention for cost metadata.
- Access: Limit who can read prompt content, and log every access to the logs themselves.
- Metadata split: Keep model, department, token count and cost fields in a store with broader access, and keep full prompts in a restricted store.
- Deletion: Verify that backups, replicas and analytics copies follow the same deletion rules as the primary store.
Ask the records officer and the security team to agree on one classification for gateway logs before the first department goes live.
Which open-source gateway fits a government deployment and why
A government gateway has to enforce model allowlists, record every call and sign users in through agency identity. The options below cover the gateway itself, the identity and traffic layer in front of it, and the trace and model components behind it. Each choice carries its own license, database and identity dependencies that procurement and security teams should check before a build starts.
LiteLLM as the model gateway
LiteLLM sits between agency applications and model providers, enforcing per-key and per-team budgets, model restrictions and rate limits. Its core is MIT licensed, but the enterprise directory uses a separate license, so confirm which features the agency needs before deciding. Virtual keys and budgets require PostgreSQL. Running more than one proxy instance needs Redis 7.0 or newer for shared rate limits and router state.
Enterprise license scope for SSO and audit
The free LiteLLM tier includes SSO for up to 5 users, so a department-wide rollout needs an Enterprise license for SSO beyond that limit. SCIM provisioning, audit logs, organization and team RBAC and secret manager integrations are also Enterprise features. Ask the vendor to confirm the current terms in writing, since packaging changes between releases, and budget the license as a recurring cost.
Apache APISIX for identity and traffic
APISIX provides the front door in agency networks, with its openid-connect plugin validating tokens from Keycloak, Microsoft Entra ID, Okta or Google before traffic reaches LiteLLM. It runs under Apache-2.0 as an Apache Software Foundation project. Choose standalone mode for a file-driven, etcd-free setup, or decoupled mode when separate data and control planes are required. Confirm the agency's patch and support expectations, since the downloads page does not mark any release as long-term support.
Kong Gateway as the alternative
Kong Gateway is Apache-2.0 licensed and fits agencies that already run Kong for API management, since one team can operate both. Its AI capabilities and plugin coverage should be compared against APISIX for the specific guardrail, logging and identity flows the agency needs. Check which Kong features are open source and which require a commercial subscription before writing the requirement into a tender.
Langfuse for trace records
Langfuse stores prompts, outputs, latency and cost traces in the agency's own storage. Its core is MIT licensed, but the ee directories carry separate terms, so confirm which edition the deployment uses. Retention periods and access roles for trace records are a records management decision that the agency should set and document, not a default to accept from the tool.
Phoenix only if the license fits
Arize Phoenix offers LLM tracing and evaluation, but its Elastic License 2.0 prohibits providing the software to third parties as a hosted or managed service. A government agency that runs Phoenix for its own staff may be within the terms, while a shared service for other agencies or contractors may not be. Have counsel review the exact use before selecting it.
vLLM or Ollama for in-agency models
Models that never leave agency infrastructure need a serving layer. vLLM, under Apache-2.0, suits shared GPU servers that serve many users, while Ollama, under MIT, suits smaller or single-host deployments. Both expose endpoints the gateway can route to. Confirm model weight licenses separately, since the serving engine's license does not cover the models it runs.
Open WebUI branding limits
Open WebUI is a common chat front end, but its license clause 4 prohibits altering or removing branding except for deployments with no more than 50 end users in any rolling 30 day period, with written permission, or under other listed exceptions. An agency rolling out a branded assistant to a whole department will likely exceed that limit. Read the license text and either obtain permission or choose a front end with terms that fit.
How a public sector gateway rollout moves from pilot to audit
The sequence turns a gateway from a technical proof of concept into a controlled service with a documented baseline, tested controls and an evidence pack that an assessor or Inspector General can review. Each phase closes with a named output that the next phase depends on.
Scope the control baseline and data classes
The agency's security office, records officer and program owners agree which systems and data classes the gateway will carry, and which control baseline applies, such as a NIST SP 800-53 low, moderate or high baseline if federal rules govern the system. DeployOpen maps the data classes to the approved routing rules and records the scope in a written architecture record. The step is done when the security office signs off the scope, the baseline and the list of data classes that must never reach an external model.
Pilot with two departments and one approved model
Start with two departments and a single approved model, served either from the agency's own infrastructure or through a contracted endpoint the agency has already assessed. DeployOpen configures the gateway with a model allowlist for each pilot department, virtual keys, and spend and rate limits set by the program owner. The output is the first model allowlist, a dated record of who approved it, and a log of every pilot request so the team can confirm that only the allowed model was called.
Configure SSO and provision keys
Connect the gateway admin interface and user access to the agency's identity provider, so that department membership in the directory determines which models and budgets a person or application receives. LiteLLM's admin UI SSO supports Google, Microsoft Entra ID, Okta and generic OIDC, and the free tier is limited to 5 users, so the agency should confirm early whether it needs an Enterprise license for SSO, SCIM and JWT authentication. Confirm that LITELLM_MASTER_KEY sits in a secret manager and that key provisioning is traceable. The step closes when a test identity from each pilot department reaches only its allowed models.
Configure logging and retention
Decide what the gateway records for each model call, including the user or application identity, model, department, token counts, cost, timestamp and policy decisions, and whether prompt and response content is stored. Set retention in line with the agency's records schedule and any applicable law, and confirm where the logs live and who may read them. DeployOpen configures the log sink, access controls and retention settings so that the records are kept under the agency's control. The output is a logging specification and a test showing that a sample transaction can be traced from the user to the model and the cost record.
Test security controls
Run security testing against the gateway and its surrounding components, including authentication bypass attempts, key scoping, model allowlist enforcement, rate limit behavior, admin interface exposure and the handling of prompts that contain sensitive data. Where the baseline calls for it, include vulnerability scanning on the schedule the baseline requires. Findings are logged, prioritized and retested after remediation. The output is a test report with each control mapped to its result, plus a remediation record that shows which findings were fixed and which were accepted by the agency with a named owner.
Package evidence for the assessor
Assemble an evidence pack that the agency's assessor, auditor or Inspector General can follow without a tour of the system. It includes the architecture record, the approved data classes, the model allowlist history, the SSO and key provisioning configuration, the logging and retention specification, the test results and the remediation log. DeployOpen prepares the evidence and documents the controls, but independent auditors and certification bodies issue any assessment outcome. The step closes when the agency's security office confirms that every control in the scope has an artifact and an owner.
Expand in controlled stages
Add departments, models and data classes one at a time, and repeat the allowlist approval, identity mapping, logging check and targeted testing for each addition. Keep a change record for each expansion so that the evidence pack stays current rather than being rebuilt at audit time. Ongoing upgrades, testing and documentation can be covered by a retainer if the agency wants continuous support. The output is an expansion log tied to the architecture record, so the agency can show at any point which department used which model, under which approval and with which controls in place.
Which records auditors and the public will ask for
Which models was each department allowed to call, and who approved them?
The allowlist itself is the first record an inspector general will request, and the gateway holds the operational copy of it. Model access is enforced through per-key or per-team model restrictions in LiteLLM virtual keys, which need a PostgreSQL database, so the configuration can be exported and compared with the approval record. The gateway does not decide who approved a model. The agency must keep signed approval memos, the risk assessment behind each approval, and a change history that links each allowlist entry to a named approver and date. Confirm with your implementation partner how allowlist changes are versioned and whether they are stored outside the gateway's own database.
How do auditors see usage and spend by department?
Spend is recorded per key, user and team in PostgreSQL, which is where LiteLLM virtual keys store budgets and usage. Auditors can reconcile that spend against each department's budget approval and cost center. Budget increases should be logged with a reason and approver, because LiteLLM supports temporary budget increases and the gateway records the change only as far as your configuration captures it. Ask your partner how spend updates are batched at scale, since LiteLLM recommends batching spend updates to the database every 60 seconds at high volume, which can affect how current a live report is.
What access logs does the gateway produce, and which ones need a separate source?
Two layers produce access evidence. APISIX access logs record client requests at the edge, including source, route and response status, and its admin API changes are tracked separately from traffic. LiteLLM audit logs for admin actions are an Enterprise feature, so confirm that the license covers them before relying on them. Neither layer proves that a named human made a request unless identity is passed through from government SSO. The agency must document log fields, retention periods and who may read the logs.
Who changed admin settings, keys or routing rules, and how is that recorded?
Admin changes need an audit trail that names the actor, the time and the before and after values. LiteLLM Enterprise lists audit logs and organization and team RBAC among its features, which is where this evidence is expected to come from. APISIX configuration changes made through its Admin API should also be captured, and in file-driven standalone mode, changes to conf/apisix.yaml are only traceable if the file sits under version control. Ask your partner to show a sample admin change record before go-live.
Can a SIEM receive gateway logs, and what does the agency still document?
Yes, in principle, the gateway logs can be forwarded to a security information and event management system, but the export path, log schema and delivery guarantees must be confirmed for the specific LiteLLM and APISIX versions in use. The agency must document which events are exported, how long the SIEM retains them, and who reviews alerts. Keep the SIEM and gateway log retention schedules consistent with the agency's records schedule. Confirm this with your partner during design rather than assuming it is available.
How long are prompt logs kept, and who can read them?
Prompt and response logs are the most sensitive records, and retention is a policy decision the agency makes, not a default the gateway imposes. Define a period for each log type, separate transparency records from prompt content, and restrict read access to named roles. For high-risk AI systems in the EU, Article 19(1) of the EU AI Act requires providers to keep logs for at least six months unless other law provides otherwise, so a non-EU agency should check its own records and public information laws before choosing a figure. Any retention period needs approval from the records officer and legal counsel.
What evidence supports a public records request without exposing sensitive prompts?
A public records officer usually needs aggregate and governance records, not raw prompts. Useful records include the model allowlist, approval memos, spend summaries by department, and counts of blocked requests. The gateway can produce these from PostgreSQL and access logs, but the agency must decide what is releasable and redact personal or confidential content before publication. Ask counsel to define the release rules in advance, because exemptions depend on the jurisdiction and the content of each record.
Which parts of the audit evidence will DeployOpen prepare, and which must the agency own?
DeployOpen plans, implements, configures and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports or attestations, and independent auditors or inspectors general make those judgments. Under a fixed-scope engagement, the written scope should list the log sources, export formats, retention settings and runbooks to be delivered. The agency still owns policy decisions, approvals, retention periods and the final evidence package. Ask for these items in the written scope before work starts.
What to ask an implementation partner before a public sector build
Start by asking how the partner maps the chosen NIST SP 800-53 baseline to concrete gateway configuration. The SP 800-53B baselines select 149 controls for low, 287 for moderate and 370 for high, so the number alone tells you little. Ask which controls land on the gateway itself (access control, audit logging, configuration management, transmission protection), which land on the LiteLLM database, Redis and secret store, and which stay with the agency's operations. Ask for the control-to-setting mapping in writing, including where LITELLM_MASTER_KEY is held and how it is rotated. For FedRAMP and CJIS, ask the partner to classify each model provider separately. A hosted provider that stores or processes federal information on the agency's behalf may fall within FedRAMP scope, and CJIS Security Policy v6.1 requires FIPS 140-3 validated modules or AES with at least 256-bit keys for CJI at rest and in transit. Ask which providers the partner would block for CJI traffic by default and who confirms each authorization status.
Ask how SSO with the government identity provider is tested, not just whether it is supported. LiteLLM's admin UI SSO covers generic OIDC, and the APISIX openid-connect plugin supports authorization code and PKCE flows, but group-to-role mapping, token expiry, and deprovisioning need explicit test cases. Ask for the test plan covering a removed user losing access, a user outside the allowed department being refused a model, and an admin session timing out. Ask how keys and budgets map to departments: which virtual keys sit under which team, who can raise a budget, and whether temporary increases require a second approver. Ask where prompt and response logs are stored, who can read them, and what the retention period is set to, since the agency's records schedule and transparency obligations decide that answer, not the gateway. Ask which features need a paid license: LiteLLM's free SSO tier covers up to 5 users from v1.76.0, and SCIM, JWT authentication, audit logs, RBAC and secret manager integrations sit in the Enterprise license. Ask for the quote in writing.
Finally, ask who holds admin credentials at each layer, including the gateway admin UI, the Kubernetes cluster, the database and the secret manager, and how break-glass access is logged. Ask how the gateway scales across instances: LiteLLM's production guidance calls for PostgreSQL as the primary database and Redis 7.0 or newer once more than one proxy instance runs, so ask how shared rate limits and router state are tested under failover. Ask for an exit plan. Virtual keys, budgets, routing rules, and the log archive should be exportable in open formats, and the partner should demonstrate that a second gateway, such as one built on APISIX, can take over the same model routes and keep the audit trail continuous. Request that exit be tested, not described, and that the test result becomes part of the accepted deliverables.
How much does a public sector AI gateway cost and what does it need from us?
What drives the cost of a public sector AI gateway?
The main drivers are the number of departments and applications that need access, the number of model providers to connect, and the identity and audit features you need. Each department adds allowlists, budgets, and onboarding. Each provider adds routing rules and credential handling. Licensing matters because LiteLLM's SSO is free for up to 5 users under its published terms from v1.76.0, and beyond that an Enterprise license is needed. That license also covers SCIM, audit logs, and team RBAC, which most agencies will need. Hosting, security testing, and evidence work add further cost. Ask for each of these as separate line items in a quote.
Which costs are one-time and which recur?
One-time costs usually include design, integration with government single sign-on, gateway configuration, initial model onboarding, testing, and documentation. Recurring costs include cloud or data center hosting, PostgreSQL and Redis operation, software license renewals, model provider usage, patching and upgrades, and support. Compliance evidence collection also recurs, because logs and control records must be kept current. Ask the partner to separate these in the written scope so you can budget each year accurately.
Can an agency build and run this without a partner?
Yes, many agencies with platform engineering teams can deploy LiteLLM or Apache APISIX themselves, but the work is more than installation. You need to design the routing and budget model, connect identity, set up secret management, run PostgreSQL and Redis for shared state, and produce security and audit evidence. Confirm your staff capacity for patching and on-call support over the lifetime of the system. A partner can cover part of the work, such as implementation or security testing, while your team keeps operational control. Decide which parts you will own before requesting a quote.
How long does a public sector AI gateway deployment take?
Timing depends on the number of departments, the number of providers, the state of your identity integration, and how much evidence work is required. DeployOpen does not publish fixed durations. Most engagements are fixed-scope, so scope, deliverables, and timelines are agreed in writing before work starts. Ask for a phased plan that shows when the pilot department goes live, when each additional department is onboarded, and which approvals your agency must give at each step. Treat any timeline without a written scope as unverified.
What does our agency need to provide before work starts?
Prepare access to your identity provider, including the metadata and test accounts needed to configure SSO and any SCIM provisioning. Provide a data classification for the workloads that will pass through the gateway, so the allowlists and guardrails match the sensitivity of each request. Name the approvers for model allowlists, budgets, and log retention. Arrange network approvals for connections to model providers and to the hosting environment. Early decisions on these items usually shape the quote more than any technical choice.
Does FedRAMP apply, and does DeployOpen issue FedRAMP authorizations?
FedRAMP applies to cloud products and services that create, collect, process, store, or maintain federal information on behalf of an agency, and the scope rules are set out in OMB memo M-24-15. Whether it applies to your gateway depends on where it runs and who operates it, so confirm this with your authorizing official and FedRAMP guidance before design. DeployOpen does not issue FedRAMP authorizations, audit reports, or certifications. DeployOpen can prepare systems, controls, and evidence for assessment, and independent assessors and authorizing officials make the determination.
What do we need to request in a quote for a public sector AI gateway?
Ask for a written scope that lists the departments and applications in scope, each model provider and self-hosted model, the identity integration method, and the audit and log retention design. Request the licensing assumptions for LiteLLM Enterprise features or the APISIX configuration you plan to use. Require separate line items for implementation, hosting assumptions, security testing, evidence preparation, and ongoing support. Ask which deliverables are fixed and which are optional, and how changes to scope are priced. Confirm which controls the work supports so that your compliance team can map the evidence.
Which federal or state control baselines should the gateway design reference?
Agencies commonly map gateway controls to NIST SP 800-53 Revision 5, using the low, moderate, or high baseline that matches the data sensitivity. SP 800-53B defines those baselines, and the current catalog release is 5.2.0. If criminal justice information is involved, the FBI CJIS Security Policy version 6.1 sets requirements for encryption and vulnerability scanning. Confirm the baseline with your security office and authorizing official, and ask the partner to state which controls the implementation supports and which remain with your agency.
How DeployOpen scopes and supports a public sector gateway
DeployOpen starts with a fixed scope agreed in writing before any work begins. For a public sector gateway, that scope should name the departments onboarded first, the model providers and self-hosted models in the allowlist, the identity provider used for government SSO, the logging destination and retention period, and who in the agency owns each decision. DeployOpen then plans and deploys the gateway, typically LiteLLM with PostgreSQL and Redis, inside the agency's own cloud account, data center or air-gapped network. Where the gateway is fronted by Apache APISIX, the deployment mode and the openid-connect configuration are part of the same written scope. Quotes follow from that scope. DeployOpen does not publish a price list, so the reader should ask for line items that separate installation, identity integration, hardening, testing and any recurring support.
Hardening and operations are where most of the agency's risk sits. DeployOpen configures the Admin UI and LITELLM_MASTER_KEY handling in a secret manager, restricts virtual keys to approved models per department, sets budgets and rate limits, and takes backups of the PostgreSQL database that holds keys and spend records. Security testing covers the gateway itself, its routes and plugins, and the model endpoints behind it, including prompt injection and data leakage checks where guardrails are in place. Documentation and evidence preparation follow, so that assessors can trace each control to a configuration, a log and a test result. The agency should confirm which evidence its own assessors expect, since the control baseline it is measured against decides that list.
DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations. After go-live, the agency can choose an optional retainer for upgrades, patching and continuous testing, which should be scoped in writing with response expectations the agency can verify. Before signing, ask the partner to confirm how changes to the allowlist, budgets and logging settings are recorded, and who approves them.
