Question 1

Where do our prompts and responses actually go?

Accepted Answer

It depends entirely on deployment topology. In Managed SaaS, prompts and responses traverse MOAI infrastructure for inspection and are never persisted beyond audit metadata. In Single-tenant, the same path occurs inside your isolated cluster. In Sidecar and Air-gapped on-prem topologies, prompts and responses never leave your VPC; only the upstream call you would have made anyway goes to the chosen LLM provider.

Question 2

How is the prompt-injection classifier trained, and is our traffic used?

Accepted Answer

Classifiers are trained on open-source attack corpora, published research datasets, synthetic adversarial generation, and findings from our internal red-team. Customer traffic is never used for training. This is contractual, not a setting. Air-gapped deployments don't even have a path back to us.

Question 3

How are false positives handled?

Accepted Answer

Every detection emits an explanation envelope with the rule, score, and surrounding context. Operators can mark findings as false-positive in the console; tuned rules can be promoted into your policy via PR review. Shadow mode lets you evaluate new rules against live traffic before enforcing.

Question 4

What is the realistic latency overhead?

Accepted Answer

During pilots, non-streaming chat completions measured approximately 11 ms p50 added latency and less than 17 ms p95. Streaming inspection runs incrementally on chunks. Your numbers are validated during the pilot using your actual traffic patterns.

Question 5

Fail-open or fail-closed?

Accepted Answer

Both, per policy, declared explicitly. There is no implicit default — policies must choose. Regulated workloads typically fail-closed; availability-sensitive consumer-facing workloads may fail-open with degraded inspection (structural checks only) and full audit still emitted. Mode changes require a second approver.

Question 6

What happens when the upstream provider is down?

Accepted Answer

AI.Guard applies policy-controlled retries for transient failures, then can route the request to an approved backup provider or model. If no approved upstream is available, it returns a typed error to the existing SDK and records the failed route and retry attempts in the audit log.

Question 7

Which models and providers are supported?

Accepted Answer

AI.Guard supports OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, Mistral, and OpenAI-compatible self-hosted runtimes including vLLM, Ollama, and TGI. See the Integrations page for the current protocol and SDK matrix.

Question 8

How does the exception process work for legitimate edge cases?

Accepted Answer

A justified bypass can be issued by a designated owner via the console or API. The bypass is scoped (caller, app, request pattern, expiry), signed, and emitted to the audit log immediately. AppSec receives an alert. Long-lived bypasses are reviewed on a configurable cadence.

Question 9

How are updates delivered to air-gapped deployments?

Accepted Answer

We publish signed update bundles (classifier weights, threat intelligence, policy pack additions) on a regular cadence. Customers pull these via their secure artifact channel, verify signatures against our published key, scan with internal tooling, and apply via the standard installer. Nothing reaches out from your network.

Question 10

What about vendor lock-in?

Accepted Answer

The gateway speaks OpenAI- and Anthropic-compatible APIs upstream. If you remove AI.Guard, your application keeps working — point the SDK back at the provider directly and you are back to baseline. Policies, tokenization vault contents, and audit history are exportable in standard formats.

Question 11

What is the exit plan if we stop using AI.Guard?

Accepted Answer

Tokenization vault contents can be exported and decrypted with your KMS keys. Policies are already in your repo (policy-as-code). Audit history is already in your SIEM. Decommissioning the gateway itself is a config change in your service mesh or load balancer.

Question 12

Can you support our internal SIEM / identity / secrets backend?

Accepted Answer

Yes. We support standard protocols (OIDC, SAML, SCIM, OTLP, syslog, CEF, HEC) and have first-class integrations with the named systems on the Integrations page. Proprietary internal systems are well-supported through the REST API and webhook surfaces.

Frequently asked questions