Why LLM guardrails for customer-facing SaaS features differ from internal assistants
For a SaaS vendor shipping a chat or generation feature, the practical answer is to run NeMo Guardrails or Guardrails AI inside the vendor's own infrastructure, enforced at an AI gateway that sits between the application and every model provider. The guard layer inspects prompts before inference and responses before they reach a customer, and it records each block or redaction. An internal assistant serves one employer whose staff share one set of policies. A customer-facing feature serves many tenants at once, so a single leaked prompt, a single embarrassing answer or a single misapplied rule reaches a customer's users, their administrators and, often, their security reviewers. That changes what the guardrails must prove.
Three differences matter most. First, multi-tenant data separation: retrieved context, conversation history and uploaded files for one tenant must never appear in another tenant's prompt or output, and the guard layer should check that responses do not echo identifiers, document fragments or system prompt content belonging to someone else. Second, brand-facing output: jailbreaks and off-topic answers become public incidents, so topic rails, output moderation and content checks carry reputational weight that an internal tool does not. Third, per-customer policy: enterprise customers often require different topic scopes, languages, retention rules or blocked terms, so the team needs a policy model that can be versioned, scoped by tenant and rolled back without a full application release. The guard layer is not a substitute for tenant authorization in the application. Guardrails classify text; they do not decide whether a user may read a record. Access checks must happen before data is placed into a prompt, using the same identity and tenant scoping the rest of the product enforces, and retrieval must be filtered at the source. Before committing to a design, confirm with your engineering and security leads which tenant boundaries the model can see, where per-tenant policy files will be stored and who approves changes to them.
Requirements customers and regulators bring to a SaaS guardrail layer
This table maps each requirement that customer security reviews and regulators raise to its source, then explains what it means for the guardrail build. Read it as a list of design inputs to agree before writing policies. The main takeaway is that per-tenant policy, redacted logs and retained guard decisions usually have to be designed in from the start, because assessors ask for evidence of them.
| Requirement | Source | What it means for the guardrail build |
|---|---|---|
| Security and confidentiality controls | SOC 2 Trust Services Criteria, security and confidentiality categories, common criteria CC1 to CC9 | Guards are part of the system description. Document which input and output rails protect tenant data, and show evidence that they operate over the review period. |
| Tenant isolation of prompts and context | SOC 2 confidentiality expectations and customer contract terms | Apply policies and retrieval scopes per tenant so one customer's content cannot reach another's prompt. Test cross-tenant leakage explicitly. |
| Processor instructions and data minimization | GDPR Article 28(3) processor contract duties | Guard configuration must follow documented customer instructions. Redact personal data before inference where the contract requires it, and record which instructions each tenant received. |
| Security of processing | GDPR Article 32 and the security controls in your contract | Show that guard models, policy stores and logs are protected in transit and at rest, and that access to guard decisions is restricted. |
| Record of automatic events for high-risk features | EU AI Act Article 12(1) and Article 19(1) | If the feature is high-risk, log guard decisions automatically over the system lifetime and keep logs for at least six months unless other law sets a longer period. Store logs with redacted prompts so the record does not create a new privacy exposure. |
| Network-facing service operator duties | NIS2 Annex I and Commission Implementing Regulation (EU) 2024/2690, for cloud, data center, managed and online platform providers | If you operate as one of these provider types, expect Article 21(2) technical measures to apply to the platform around the guardrails. Confirm scope with counsel before assuming it applies. |
| Vulnerability handling for shipped software | Cyber Resilience Act reporting duties and product obligations for software with digital elements | If the guard layer ships as part of a product sold to customers, track its components, patch known vulnerabilities and plan reporting. Confirm which obligations apply to your product and dates with counsel. |
| Customer-facing evidence pack | Customer security questionnaires built on the sources above | Keep versioned policy definitions, test results for injection and leakage, and a sample of redacted guard decision logs ready for review. Describe what each guard does not catch. |
How tenant data leaks across prompts and how input rails stop it
In a multi-tenant generation feature, tenant data leaks through a handful of predictable paths, and guardrails only address some of them. The first is retrieved context: if a retrieval step pulls chunks from a shared index without a tenant filter, the model may quote another customer's documents. The second is shared caches, where a semantic or prompt cache keyed only on the question returns an answer generated from a different tenant's context. The third is cross-session memory, where conversation summaries carry one customer's details into another customer's session. The fourth is system prompts exposed by jailbreaks, which can reveal internal instructions, tool names or configuration. The fifth is logs: prompts, retrieved chunks and outputs stored for debugging are often readable by support and engineering staff far beyond the customer's own scope.
Input and output rails reduce these paths at the point where text enters and leaves the model. NeMo Guardrails provides input rails and output rails, and retrieval rails that act on each retrieved chunk before it reaches the prompt, so a chunk tagged to another tenant can be dropped and logged. Guardrails AI validators can check outputs for patterns such as account identifiers or internal hostnames before the response is returned. Tenant-scoped configurations matter here: each tenant or plan tier should load its own policy set, so one customer's blocked terms or allowed topics do not change another's behavior. Confirm with your guardrail vendor or implementation partner how a tenant identifier is passed into rails and whether it is available to custom actions.
Guardrails reduce risk. They do not replace tenant isolation in the data layer. A classifier can miss a leaked fragment, a paraphrased secret, or a jailbreak that was not in its training data, so the authoritative control is that a tenant's query never reaches another tenant's data: separate indexes or partitions, row-level access enforced by the data store, per-tenant encryption keys where your requirements call for them, and cache keys that include tenant identity. Treat the rails as a second layer that catches what the first layer misses, and test both layers separately. *Illustrative example:* a retrieval filter bug returns a competitor's contract clause to your customer, and an output rail that checks for the contract's party names is a backstop, not the fix.
Which open-source guardrail and gateway platforms fit a SaaS product
A customer-facing feature needs a guard library that inspects prompts and responses, a gateway that forces every model call through those checks, and traces that show what was blocked. The platforms below cover one layer each, and they fit together only if you decide early which layer enforces policy and which one records evidence for customers' security reviews.
NeMo Guardrails for dialog and safety rails
NeMo Guardrails is Apache-2.0 licensed and organizes checks into five rail types: input, dialog, retrieval, execution and output. Policies are written in Colang, where Colang 1.0 is the default and Colang 2.x is supported, but NVIDIA's migration tool output still needs manual review before you rely on it. The library includes jailbreak and injection detection models, and it can run as a server with an HTTP API from a Docker image. Confirm which detection models your tenants' languages and content types need, and whether they run without outbound calls in your environment.
Guardrails AI for validators and structured output
Guardrails AI is Apache-2.0 licensed and builds guards from validators published on Guardrails Hub, such as regex matching or toxicity detection, which you install separately and chain together. It also generates output that matches Pydantic models, which suits product features that return JSON to a front end. It can run as a standalone Flask REST service started with guardrails start. Check each validator's license and maintenance status on the hub before you ship it, and decide whether anonymous metrics reporting is acceptable, since the setup command asks.
LiteLLM as the enforcement point
LiteLLM is an AI gateway that calls more than 100 LLM APIs in OpenAI format and includes cost tracking, guardrails, load balancing and logging. It is MIT licensed except for its enterprise directory, so confirm which features your deployment needs sit outside that directory. Placing it between your application and every model provider means a feature cannot reach a model without passing the guard checks. Test that the guardrail hooks fail closed when a guard service is unreachable, and that per-tenant keys and budgets are enforced at the gateway.
Apache APISIX as an edge gateway
Apache APISIX is a cloud-native API gateway and AI gateway licensed under Apache-2.0. Where your product already routes customer traffic through an edge gateway, APISIX can authenticate tenants, apply rate limits per tenant and forward chat requests to the guard layer before they reach your application. This limits abuse and prompt flooding at the edge, while content checks stay in the guard layer. Confirm which AI-specific plugins your version provides and whether they cover the guard calls you plan to make, rather than assuming parity with LiteLLM.
Langfuse for guard traces and evaluation
Langfuse is an open source LLM observability and evaluation platform licensed under MIT, except for its ee directories. It records traces, prompts, outputs and scores, which lets you show a customer's security team how often each guard fired, what it blocked and how that changed after a policy update. Decide what goes into traces before launch, because prompts can contain tenant personal data. Keep the trace store in your own infrastructure and set retention to match your customer contracts.
Phoenix licensing limits for SaaS
Arize Phoenix is an LLM tracing and evaluation tool licensed under the Elastic License 2.0, which prohibits providing the software to third parties as a hosted or managed service. A SaaS vendor that exposes Phoenix dashboards to customers, or runs it as part of a service sold to them, should get a licensing review before adopting it. Internal use for your own engineering team is a different question from providing it to tenants. Have counsel confirm how your service is structured before you choose Phoenix over Langfuse for traces.
Blocking jailbreaks that embarrass the brand without blocking real users
Jailbreak and prompt injection attempts against a customer-facing feature fall into a few categories that need different controls. Direct jailbreaks ask the model to ignore its instructions or adopt a persona. Prompt injection hides instructions in content the feature processes, such as a pasted email or a support ticket. Off-topic requests pull a product assistant into writing essays, legal opinions or code it was never meant to produce. Competitor-disparaging or brand-damaging output is the category that generates screenshots. In NeMo Guardrails, input rails screen the user message, output rails screen the reply, and dialog rails keep the conversation on the flows the vendor defined. Jailbreak and injection detection is available in the library, but the vendor must decide which of these categories each rail covers and in what order they run.
The hardest design choice is the false positive trade-off. A rail that blocks too eagerly turns a sales question about a competitor's feature comparison, or a support message that quotes a jailbreak phrase in a complaint, into a refusal that a paying customer experiences as the product failing. Topic checks should be written against the feature's purpose statement, and the vendor should review which legitimate customer intents sit close to each blocked topic. Dialog rails and topic checks work best when the allowed scope is narrow and documented, but narrow scope also raises the rate of benign refusals, so the two need to be tuned together.
Before any rail moves from logging to blocking mode, run it in observe-only mode on the vendor's own production-like traffic, sampled with consent and privacy terms that match its customer agreements. Measure the share of blocked requests per rail, a reviewed sample of blocked and passed messages labeled by a human, the refusals that real customers would consider legitimate, and the latency each check adds. Record the rail configuration version alongside each decision so changes can be traced. Confirm with the guardrail vendor or implementation partner how thresholds are exposed, how a rail can be disabled quickly if it misfires, and how false positive reviews feed back into the Colang flows or validators. Results from a test set are not a substitute for this measurement on your own traffic.
How a SaaS team rolls out guardrails in production
The sequence moves from a per-feature threat model to gateway-enforced, per-tenant policies that are tested, staged and reviewed after launch. Each phase produces an artifact that the product, security and customer-facing teams can check before the next phase starts.
Model threats and scope policy per feature
The product owner, security lead and privacy counsel list each chat or generation feature, the data it can reach, the tenants it serves and the actions it can trigger. They map the risks to be covered, such as cross-tenant data disclosure, jailbreaks, unsafe output and structured-output failures, and decide which must be blocked and which only logged. The step closes with a signed threat model per feature that names the owner of each policy decision. Illustrative example: a support assistant that can read ticket history needs a tenant-boundary rule that a marketing copy generator does not.
Capture baseline traffic in shadow mode
Before any guard blocks a request, the team runs the candidate input and output checks in shadow mode against real traffic and records what each rail would have decided. Prompts and responses are stored only in redacted form, with tenant identifiers pseudonymized and personal data masked, so the baseline itself does not become a new leakage path. The team reviews a sample of flagged and unflagged exchanges to estimate false positives on its own language and workload. The step closes when the baseline report shows, per feature, which rails would fire and on what share of sampled traffic.
Configure and version rails as code
Engineers write the rail definitions in config.yml and Colang files, with Python actions for custom checks and validators where needed. If a configuration is migrated from Colang 1.0 to 2.x, the team uses the nemoguardrails convert tool and then manually reviews every converted rule, because NVIDIA states that converted configurations still need review. All files go into version control with a named reviewer for each change, and the release record ties each guard version to the feature version it protects. The step closes when a reviewed, tagged configuration can be deployed and rolled back independently of the application.
Build the red-team set and regression suite
The security team assembles a test set of known jailbreaks, prompt injections, tenant-crossing requests, data extraction attempts and malformed structured-output cases, and refreshes it from the blocked-request log over time. Every change to a rail, validator or model runs the full suite in continuous integration, and any drop in detection or rise in false positives fails the build. The step closes with a passing baseline score recorded for each feature, plus a list of known gaps that the product owner accepts in writing. Testing of this kind is also a core part of DeployOpen's security testing services for AI systems.
Enforce rails at the gateway with per-tenant policy
The guard checks run at the AI gateway, not only inside each application, so every model call passes through the same enforcement point. Policies are keyed by feature and by tenant or tenant tier, which lets a regulated customer receive stricter output filtering than a standard one without forking the codebase. The platform and security teams confirm that tenant identity comes from the authenticated session, not from the prompt text, and that the gateway fails closed when a guard service is unavailable. The step closes when a test tenant cannot reach another tenant's context through any prompt used in the red-team set.
Roll out in stages with alerting
The team enables enforcement for a small share of traffic or a limited set of tenants first, watching block rates, latency at the guard step and user complaints against thresholds agreed before launch. Alerts go to the on-call security and product owners when block rates, guard timeouts or tenant-boundary events move outside the baseline. Expansion to more tenants or features happens only after the owners sign off on the previous stage's results. The step closes when enforcement covers all in-scope features and the rollout record shows each stage's metrics and the approver.
Review blocked requests and retune regularly
On a recurring schedule, the security and product teams review a sample of blocked requests, false positives reported by customers and newly observed attack patterns, then update rails, validators and the red-team set through the same reviewed change process. Blocked and redacted decisions are retained in the organization's own logs under the retention period set by its compliance team, since these records also serve as evidence for customer security reviews. The step closes with a dated review record and a changelog that customers can be shown on request.
Obtain customer-facing sign-off
Before a feature goes to customers, the customer-facing team signs off on what the assistant will refuse, how refusals are worded, which data is logged and for how long, and how customers can report a bad block or a suspected leak. Legal and privacy confirm the processor terms and the handling of prompts and logs against the customer contract. Support confirms the escalation path for tenant-boundary incidents. The step closes when these four approvals are on file for each feature, because customer security questionnaires will ask for the same answers.
Evidence customers' security reviews ask for and which component produces it
This table maps each evidence item a customer's security review commonly requests to the component that produces it and the party that signs off on it. Read it as a checklist for what to build into the guardrail stack from day one, since retrofitting logs or change history rarely satisfies a reviewer. DeployOpen prepares this evidence, but SOC 2 reports are issued by independent auditors, and a Type 1 report covers control design at a point in time while a Type 2 report also tests operating effectiveness over a period.
| Evidence item | What the reviewer asks | Producing component | Notes for the review |
|---|---|---|---|
| Policy versions and change history | Which guard rules were live on a given date and who approved each change | Guard configuration (NeMo Guardrails config.yml, Colang files, Guardrails AI validators) kept in version control | Tag each release, link merge approvals and keep the deployed commit hash in the gateway record |
| Blocked and allowed decision logs | What the guard blocked, allowed or modified, and whether personal data appears in the log | AI gateway (for example LiteLLM or APISIX) and the guard service, with redaction applied before storage | Confirm retention periods and access controls on the log store; customers often ask who can read raw prompts |
| Injection and jailbreak test results | How the guards were tested, what passed, what failed and what remains open | Red-team reports from security testing against a versioned prompt suite, rerun after each policy change | Record the suite version, the model and guard versions tested, and the known gaps with owners |
| Tenant isolation test evidence | Whether one customer's data can appear in another customer's prompt, retrieval or response | Test cases run against the gateway, retrieval layer and session store, with results stored per release | Include cross-tenant prompts, shared cache checks and retrieved chunk filtering by tenant identifier |
| Data processing terms and sub-processor list | Which processors handle prompts and outputs, and whether they act only on documented instructions | Contracts and data processing terms prepared with the client's legal team, aligned to GDPR Article 28(3) | Self-hosted guard models reduce the sub-processor list; list any hosted model or logging vendor explicitly |
| SOC 2 control evidence for change management | Whether guard and prompt changes follow approval, testing and rollback controls | Ticketing, pipeline approval records and deployment logs, mapped to the security common criteria | Auditors issue the SOC 2 report; ask whether the customer needs Type 1 (design) or Type 2 (operating effectiveness) and over what period |
What customer security questionnaires ask about AI features
Customer security questionnaires for AI features usually start with where the model runs and what happens to the data. Expect questions on model hosting location (which regions, which cloud accounts or data centers, and whether any inference call leaves that boundary), whether prompts or outputs are used to train third-party models, how long prompts, files, outputs and guard decisions are retained and where backups sit, and whether one tenant's documents, embeddings, conversation history or cached responses can reach another tenant. Before answering, confirm each of these in your own architecture: which model provider contracts forbid training on your traffic, what the retention settings are in your gateway, observability and vector store, and how tenant identifiers are enforced at retrieval time, not only in the application layer.
Guard coverage is the question security teams press hardest. They want to know which risks the input and output rails address (prompt injection, disclosure of other customers' data, unsafe or off-topic output), which checks run on every request versus sampled traffic, what happens when a guard fails open or closed, and how the team tests that each rail still works after a policy change. Describe the rails by name, for example the input and output rails in NeMo Guardrails or the validators chained in Guardrails AI, and be clear about what they do not cover. Incident response for AI misuse is the other frequent topic: who triages a jailbreak report, how blocked and flagged requests are logged, and how a customer is notified. Write these answers as a runbook your team has tested.
On reports, a SOC 2 Type 1 or Type 2 report is generally restricted in use, so most customers will ask for it under NDA rather than receive it publicly. A general-use SOC 3 report is broader in distribution but gives less detail, so it rarely answers an AI questionnaire on its own. Confirm with your auditor which Trust Services Criteria the examination covers and whether AI-specific systems fall inside the system description, because a report that omits the guardrail layer will leave questions open. Do not describe certifications you do not hold. For ISO/IEC 27001, ask the accredited certification body for the scope statement and certificate status, and state only what that document says.
How much does it cost to add LLM guardrails to a SaaS feature?
What drives the cost of adding LLM guardrails to a SaaS feature?
The cost follows the scope of what is guarded: the number of AI features and entry points, the languages customers use, how many tenants need their own policies, the latency budget per request, and how often the guards are tested. Each of these adds engineering, compute and testing work. Open-source guardrail libraries such as NeMo Guardrails and Guardrails AI carry no license fee for the software itself (both are Apache-2.0), so most of the spend is people and infrastructure. Ask any quote to break out the work by feature, by language, by tenant policy and by test cycle, so you can see which lever changes the total.
How long does it take to get the first guard into production?
The first guard usually takes longer than the library setup suggests, because the time goes into defining the policy, testing it against real customer-style inputs and tuning false positives. Installation is quick in comparison. The duration depends on how many risks the first release covers and whether the team already runs a gateway that can enforce the guards. Ask for a timeline tied to a written scope with named milestones: policy definition, a test set built from your own data, a staging rollout and a production cutover. Treat any timeline without those milestones as incomplete.
What does the vendor team need from our side to deliver guardrails?
The delivery team needs access to the feature's prompt and response flow, a sample of representative customer inputs (with personal data removed or handled under your data processing terms), the tenant model and any per-tenant policy requirements, and a named owner who can approve policy changes. It also needs staging environments in your own cloud account or data center, access to the AI gateway or application code where checks are enforced, and a decision on where logs of blocked requests are stored. Put these inputs in the statement of work so delays from missing access do not get billed as scope changes.
Can one internal engineer build and run guardrails alone?
A single engineer can build a narrow first version, such as one feature with a few input and output checks, if they know the application well and the library documentation. Running it safely over time is harder. Policy changes, false positive review, handling new jailbreak patterns and testing each release need more than one person, and the work depends on whoever knows the policies. Before deciding, ask who will own policy changes when the engineer is unavailable and how the guard behavior is tested after each model or prompt change. A partner engagement can cover build, handover and documentation so the internal team is not carrying the knowledge alone.
What recurring work comes after the guardrails go live?
Recurring work includes reviewing blocked and allowed requests, tuning validators and rails when false positives appear, updating policies when product behavior or customer requirements change, and upgrading libraries. Red-team testing repeats on a cadence you set, because new injection techniques appear regularly and each model or prompt change can shift guard behavior. Ask the quote to separate one-time build effort from a recurring retainer, and to state what is covered per release and per quarter. Compute for self-hosted classifier models is also recurring, since it runs for as long as the feature does.
Should we build guardrails in-house, use a partner or buy a hosted API?
The choice depends on whether customer data may leave your infrastructure, how many tenants need distinct policies, and how much in-house AI security capacity you have. Hosted moderation APIs remove setup work but send content to a third party, which customer contracts or security reviews may not allow. Building in-house keeps data in your environment but moves policy, testing and maintenance onto your team. A partner can implement self-hosted open-source guardrails in your cloud account and hand over runbooks, which splits the one-time build from the ongoing ownership. Compare the three options on the same written list of features, languages, tenants and test cadence.
Which security review questions affect guardrail cost and scope?
Customer security reviews often ask where prompts and outputs are processed, how blocked requests are logged, how tenant data is kept apart in prompts, and how guard effectiveness is tested. Each answer may require extra work, such as tenant isolation checks, log retention settings or documented test results. SOC 2 examinations assess controls against the AICPA 2017 Trust Services Criteria, but DeployOpen prepares systems and evidence for those assessments and does not issue the reports, which independent auditors produce. Confirm which of these items your customers require before the quote, because they change the evidence work in the scope.
Questions to ask an implementation partner before a SaaS guardrail project
Ask how tenant-scoped policies are versioned before anything goes live. For a multi-tenant SaaS feature, each customer may have its own topic restrictions, blocked terms or output schemas, and a partner should be able to show where those rules live, who can edit them and how a change to one tenant is kept from affecting another. Ask whether policy versions are stored in source control, whether every blocked request can be traced to the policy version that produced it, and how a rollback works if a new rule starts rejecting legitimate traffic. Ask who owns policy updates after launch: your product team, your security team, the partner under a retainer, or a shared model. Get that split written into the statement of work. An undefined owner is one of the most common reasons guardrails drift out of date.
Ask how false positives are measured on your own traffic, not on the partner's demo prompts or a public benchmark. A reasonable answer names a labeled sample drawn from your staging or consented production logs, the metrics reported (blocked legitimate requests, missed attacks and the review queue size), and who labels the data. Ask where the classifier models run, whether they are self-hosted in your cloud account or called through a hosted API, and what happens to customer prompts sent to either. Ask how the partner measures the added latency of each guard check against the budget you set per request. For logs, ask which fields are redacted before storage, how long blocked prompts are kept, who can read them and whether the retention period matches your customer contracts and data processing terms.
Ask how the partner tests bypasses. Look for a recurring red-team process that covers direct and indirect prompt injection, multi-turn jailbreaks, encoding tricks and attempts to pull another tenant's data, with results tracked as regression tests. Ask how a Colang or validator change is released: whether it goes through version control, code review, a staging run against the regression suite and a canary tenant before general release, and whether a rollback path exists. Red flags include any guarantee that all jailbreaks will be blocked, a refusal to share test results, no named owner for policy changes, detection models that cannot be located or versioned, and a plan that treats guardrails as a one-time setup. Ask for these answers in writing before you sign a fixed-scope agreement.
How DeployOpen scopes and supports SaaS guardrails
This sequence takes a SaaS vendor from an undefined chat or generation feature to a scoped, tested and supported guardrail layer running in its own infrastructure, with evidence ready for customer security reviews.
Review the feature and its tenant boundaries
DeployOpen walks through the chat or generation feature with product, engineering and security leads. The team maps which tenants, users, documents and system prompts can reach the model, where prompts and outputs are stored, and which customer data types are in scope. The step closes with a written data flow diagram and a list of tenant isolation assumptions that the guardrails must protect.
Define risks and guard requirements
Working with the vendor's security and product owners, DeployOpen turns the risks into concrete requirements: cross-tenant data leakage, jailbreaks that produce off-brand or unsafe content, structured output validation, and the latency each request can absorb. Each requirement is tied to an input rail, an output rail or a validator. The step closes with a signed requirements list that becomes the basis for the scope.
Select the guardrail framework and placement
DeployOpen compares NeMo Guardrails and Guardrails AI against the requirements, considering rail types, configuration model, structured output needs and the team's language and deployment skills. It also decides where enforcement sits, such as at a self-hosted AI gateway, and which classifier models run on the vendor's own GPUs or servers. The step closes with a written architecture decision record that the customer's reviewers can read.
Write the fixed-scope agreement
Before any build work starts, DeployOpen and the vendor agree in writing on scope, deliverables, responsibilities, exclusions and acceptance criteria. The agreement names the guard checks to be built, the test cases to be run and the evidence to be handed over. The step closes when both parties sign. The quote is derived directly from this written scope, so the reader can see which items drive the price.
Build, harden and configure the guard layer
DeployOpen implements the rails, validators and policy files in the vendor's own cloud accounts or data centers, then hardens the hosting: access controls on policy repositories, secrets handling, logging of blocked requests and version control for every policy change. The step closes with a deployed staging environment and a configuration baseline that can be reproduced from source.
Test prompt injection, leakage and output validity
DeployOpen runs application and AI security testing against the guard layer, including jailbreak attempts, cross-tenant leakage probes, indirect injection through customer documents and malformed structured output. Results are recorded with false positive and false negative observations on the vendor's own sample data. The step closes with a test report listing open findings, each with an owner and a fix or accepted risk decision.
Prepare evidence for customer security reviews
DeployOpen assembles the materials that customer security reviewers and any independent auditor will ask for: architecture documents, control descriptions, configuration records, test results, change logs and log samples. DeployOpen prepares this evidence but does not issue audit reports or certifications. The step closes with an evidence index that the vendor's compliance lead can map to its own assessment scope.
Support tuning and continuous testing
After go-live, the vendor can keep the guard layer current through a retainer covering policy tuning as false positive reports come in, upgrades of framework and model components, and recurring security testing as the feature changes. Ongoing scope, response expectations and service terms are agreed in writing. The step is complete when the vendor's team can review guard decisions and reproduce any policy change from version control.
